Projekt o którym mowa co prawda nie jest pisany w Arduino, ale pod zwykłe AVR-y w C++ (próba przesiadki ze zwykłego C).
Na jego potrzeby pożyczyłem jednak trochę plików źródłowych z Arduino - głównie bibliotekę Arduino Ethernet, którą udało mi się pozbawić nawiązań do "jądra" Arduino.

Mam teraz jednak pewien dylemat. Chciałem sobie utworzyć typ strukturalny, w którym byłyby zapisane wszystkie dane konfiguracyjne powstającego systemu. Potem utworzyłbym trzy zmienne tego typu: w pamięci RAM, EEPROM, oraz FLASH (ok, ta ostatnia to raczej stała). Takie podejście umożliwia wygodne zarządzanie ustawieniami - z kopii umieszczonej w RAM-ie korzystamy podczas normalnej pracy, w EEPROM-ie znajduje się bieżąca konfiguracja wczytywana przy starcie, natomiast FLASH przechowuje wartości domyślne, które można w razie czego przywrócić.

W C wszystko było jasne. Tworzyłem sobie typ strukturalny, np.:



A potem inicjowałem kolejne zmienne:



Dla PROGMEM musiałem oczywiście podać wartości.

Teraz próbuję to samo zrobić pod C++, korzystając z arduinowego typu zmiennej IPAddress:



Niestety próba podania wartości w klamrach, jak powyżej skutkuje warningiem:



Ktoś może mi powiedzieć co jest tego powodem i jak prawidłowo umieścić wartości we flashu?

"IPAddress" jest zapewne klasą, której konstruktor wymaga podania kilku parametrów na wzór: http://arduino.cc/en/Reference/EthernetIPAddress

Umieszczenie zawartości obiektu w pamięci FLASH/EEPROM wymaga tzw. procesu serializacji tzn. "rozbiciu" poszczególnych składowych obiektu, aby możliwe było późniejsze ich zapisanie. Najlepiej w tym celu dodać metodę do klasy "IPAddress" dokonującą takowego zapisu/odczytu.

mokrowski nie rozumiem dlaczego doradzasz użycie struktury zamiast klasy. Nie wiem jaki miałby być zysk korzystania w c++ ze struktury zamiast z klasy.

to mniej więcej tak samo jak do byle przykładu w arduino do pętli for ... ludziska dają typ int dla zmiennej iteracyjnej i nie ważne, że zmienia się ona w zakresie np 0-10 ..... No można oczywiście dać int, można nawet long int albo i long long int - tylko po co ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ja też nie przepadam za "czystym" Arduino. Niemniej istnieje sporo peryferiów, które nie mają bibliotek np. pod AVR-y, ale bez problemu można znaleźć dla nich kod pod Arduino. Tak właśnie wyglądała sytuacja w moim przypadku. Jakiś czas temu skleciłem sobie płytkę z Atmegą644 i układem Wiznet W5100 (ten sam, który stosuje się w popularnych Ethernet Shieldach) i powoli zabrałem się za pisanie biblioteki, w oparciu o przykłady z Internetu. Po drodze jednak zajrzałem do kodu biblioteki Arduino Ethernet. Okazało się, że jest tam już praktycznie gotowy cały sterownik (trzeba było tylko pozbyć się nawiązań do wiring i pozmieniać kilka niskopoziomowych funkcji) oraz obsługa socketów. Po przeportowaniu tej części przyjrzałem się najwyższej warstwie (klasy takie jak Ethernet, EthernetServer, EthernetClient i EthernetUDP) stwierdzając, że usunięcie nawiązań do Arduino nie powinno być zbyt trudne, a dzięki nim zyskałem np. możliwość automatycznego przydzielania socketu, nie musiałem też od nowa implementować obsługi DNS albo DHCP.
Postanowiłem nie pozbywać się funkcjonalności tej biblioteki, stąd np. zostawiłem IPAddress i nie przerabiałem kodu pod obsługę zwykłych, czteroelementowych tablic z adresami IP. Na razie wszystko działa, chociaż przerobiona biblioteka znajduje się w fazie testów.

Jednak w porządku - w strukturze w pamięci flash/EEPROM będę trzymał zwykłe tablice, później inicjując nimi obiekty klasy IPAddress.

Chyba jest małe nieporozumienie. Bo raz zalecasz żeby używać struktury zamiast klasy, a potem odnosisz się do implementacji z Arduino Ethernet. Jeżeli autor będzie korzystał z tej biblioteki to nie ma możliwości zmiany. Natomiast jeżeli tworzy swoje rozwiązanie to może napisać swoją klasę, która w najprostszej postaci nie różni się niczym od struktury.
Obiekty nad strukturami mają tą przewagę, że pozwalają wystawić interfejs, który nie pozwala na przypadkowe niepożądane modyfikacje (nie rozumiem dlaczego tak Ci przeszkadzają prywatne atrybuty).
Obiekt też możesz serializować tak jak strukturę (chyba, że nie zrozumiałem problemu), a dodatkowo możesz dorzucić specjalizowane metody - wcale nie wymagające dziedziczenia.
Równie dobrze mógłbym zapytać dlaczego struktura a nie typedef dla czteroelementowej tablicy (w obiekcie da się uzyskać dostęp jak do tablicy, a w strukturze nie).

mirekk36 - tylko, że pomieszałeś teraz dwa problemy. To co przedstawiłeś można rozważać pod kątem zajętości pamięci i wybrać rozwiązanie optymalne. Problem struktura/klasa nie daje się już tak prosto sprowadzić.