W dniu 2014-02-24 10:40, Marek pisze:

> Ostatnio też się nad tym zastanawiałem przy projektowaniu płytki, nawet

Mogę zapytać do jakich wniosków ostatecznie doszedłeś? Zostawiłeś
ścieżkę jak jest, tak dla świętego spokoju, czy może dałeś sobie z tym
spokój i zaprojektowałeś tak, jak było najwygodniej?


> driver microchipa do ich stosu nie używa przerwania. Być może dlatego,

Swoją drogą jak wygląda korzystanie z tego darmowego stosu od
Microchipa? Można go porównać do minimalistycznych wersji w stylu
tuxgraphics albo uIP? Występuje ograniczenie wielkości odpowiedzi TCP do
jednego pakietu, a obsługa polega na wpisaniu wartości do bufora i
wywołaniu odpowiedniej funkcji? A może dysponujemy socketami i
przypomina to raczej pisanie aplikacji sieciowych pod system operacyjny
albo sprzętowy stos W5100?

Muszę przyznać, że całkiem fajnie wyglądają procki z serii PIC18F* z
wbudowanym sterownikiem Ethernetu. Może warto się im bliżej przyjrzeć?


> że wg dokumentacji do stosu, obsluga encj (w tym wywoływanie funkcji
> obsługijących stos) nie jest time critical. Obsługa stosu działa w
> modelu cooperative multitasking jako maszyna stanów. Wystarczy funkcje
> tcp_task() wywoływać w main() periodycznie ci kilka-kilkadziesiąt ms.

Obsługi samego przerwania tam nie widzę. Zastanawiałem się jednak, czy
przypadkiem któraś z cyklicznie wywoływanych funkcji nie sprawdza zmiany
stanu samego pinu. W definicjach nie widzę takiego wejścia, jednak być
może autor odwołał się do niego bezpośrednio w którymś momencie? Nie
mogę się doszukać takiego fragmentu kodu, co nie znaczy jednak, że go
tam nie ma...


> Przy okazji można docenić genialność wynalazku jakim jest tcp/ip, jego
> adaptacyjność i możliwość działania przy skromnych zasobach....

Jakby nie patrzeć, to sam stos TCP/IP został opracowany w latach
siedemdziesiątych. Idea transmisji pakietowej o ile mnie pamięć nie myli
powstała jeszcze w latach pięćdziesiątych. Pracownicy wywiadów
największych mocarstw daliby się wtedy zabić za najprostszą ATmegę. ;)