Skleciłem sobie jakiś czas temu prostą "platformę uruchomieniową" - na jednej płytce znajduje się ATmega644, Wiznet W5100 oraz FT232. Większość wolnych pinów GPIO została wyprowadzona na goldpiny. Jakiś czas temu zacząłem pisać prostą bibliotekę do obsługi W5100, posługując się przykładami z Internetu udało mi się uzyskać prostą komunikację via telnet. Ostatnio jednak pomyślałem, że przecież:

1) Obsługa tego układu została dość dokładnie rozpracowana przez środowisko użytkowników Arduino, które używa go w popularnym Ethernet Shieldzie.
2) Arduino jest oparte na AVR-GCC.
3) Biblioteki Arduino są co prawda pisane w C++, ale Atmel Studio pozwala na tworzenie projektów w tym języku

Osobiście średnio przepadam za Arduino. To znaczy nie odczuwam jakiejś awersji względem niego, niektóre rzeczy są tam rozwiązane całkiem fajnie (np. duży nacisk położony na obiektowość) ale jednak nie wyobrażam sobie pisania kodu jakiegoś większego projektu w języki wiring, cały czas sprawdzając jaki numer linii odpowiada konkretnemu pinowi procesora. Nie lubię też tego dziwnego podziału na void setup() {} oraz void loop() {}.
Czy dałoby się połączyć najlepsze cechy obydwu "światów"?

Zajrzałem do kodu źródłowego biblioteki Arduino Ethernet i widzę, że jest ona podzielona na kilka warstw. Najniższe z nich (SPI.h, W5100.h) można by w miarę łatwo oczyścić z nawiązań do Arduino - właściwie są to tylko komendy wiringa ustawiające odpowiednie stany na liniach sterujących (np. pin CS układu W5100). Wyżej znajdują się funkcje zarządzające socketami, a na samej górze mamy już biblioteki odpowiedzialne za samą komunikację tak, jak jest ona zwykle realizowana przez użytkownika (np. klasy client i server). Tutaj już jest sporo nawiązań do bibliotek typowych do arduino (nie tylko wiring.h, ale także np. print.h, printable.h, definicje IPaddesss.h itp).

I teraz zastanawiam się co można by z tym zrobić:

1) Jak trudne byłoby "oczyszczenie" tego z zależności typowych dla Arduino i pozostawienie kodu, który skompiluje się w zwykłym projekcie Atmel Studio. Google nie zwróciły niczego konkretnego, ale może ktoś już coś takiego zrobił? W końcu cena Ethernet Shielda aż się o to prosi, to ja poszedłem trochę "na około" budując własną płytkę.
2) Może dałoby się dodać te wszystkie standardowe biblioteki Arduino do Atmel Studio? Na ile możliwe jest zachowanie kompatybilności pomiedzy obydwiema platformami? Z tego co widzę prosty kod AVR-GCC kompiluje się w Arduino IDE, choćby np.:



Co ciekawe jednak nie znana jest mu definicja PB2 w odniesieniu do linii procesora - trzeba podać samą dwójkę.

Witam.
Tu http://www.ermicro.com/blog/?p=1773 masz świetny tutorial AVR C WIZNET 5100. Mam rwnież w planach ogarnęcie tych fajnych scalaczków.

------------------------ [ Dodano po: 2 minutach ]

A tu kolejny tutek na arduino http://startingelectronics.com/tutorials/arduino/ethernet-shield-web-server-tutorial/

Oj, ten kod to jest naprawdę BARDZO podstawowa wersja. To, co masz na tej stronie nawet się nie umywa do możliwości oferowanych przez bibliotekę dla Arduino. Nie masz tutaj nawet jeszcze zaimplementowanej obsługi UDP!
Właśnie na podanym przez Ciebie tekście wzorował się autor poniższego opisu:
http://www.seanet.com/~karllunt/w5100_library.html
Moja biblioteka jest oparta właśnie na jego kodzie, przerobionym z myślą o obsłudze telnetu.

Hmm... Zacząłem powoli przerabiać kod tej biblioteki tak, żeby kompilował się pod AVR C++. Zrezygnowałem z pomysłu sprowadzania go do poziomu "czystego" C - akurat obiektowość to bardzo fajna cecha tej biblioteki.
Zacząłem od usunięcia wszystkich nawiązań do wiring.h i arduino.h w niskopoziomowych procedurach, odpowiedzialnych za komunikację z układem po SPI. Część odpowiedzialna za obsługę socketów nie wymagała praktycznie żadnych zmian.
Obecnie siedzę nad wysokopoziomowymi procedurami (Ethernet.h, EthernetServer.h, EthernetClient.h itp.). Przede wszystkim usunąłem nawiązania do wiring.h, m.in. podmieniając delay() na _delay_ms(). Pozbyłem się także metod print() i println(), które odwoływały się do "rdzennych" bibliotek Arduino.

Zaskoczyła mnie jedna rzecz - niektóre pliki nagłówkowe są w dziwny sposób zdublowane. Na przykład EthernetUDP.h występuje drugi raz w "rdzeniu" jako UDP.h. Tak samo wygląda sytuacja z EthernetServer.h i Server.h.

Jeszcze dziwniejsze są "łańcuszki wywołań". Dla przykładu w klasie IPAddress mamy tablicę uint8_t _address[4], w której przechowywany jest adres IP. Do jego wydobywania służy metoda .address_raw(), która zwraca wskaźnik do pierwszego elementu wspomnianej wyżej tablicy. Zarówno tablica, jak i metoda znajdują się w sekcji private. Co dziwne, w "rdzeniu" znajdowała się jeszcze jedna funkcja: uint8_t* GetAddressRaw(IPAddress), której podawało się cały obiekt klasy IPAddress, a ona wykonywała metodę .address_raw(), zwracając jej wynik. Ktoś wie czemu to miało służyć? Pozbyłem się tych zbędnych odwołań do plików "rdzenia" Arduino, zaprzyjaźniając klasę IPAddress z odpowiednimi klasami biblioteki Arduino Ethernet.

W tej chwili jestem na etapie portowania części obsługującej DNS oraz DHCP.