Różne metody obsługi przerwań w stosie TCP/IP ENC28J60 - jak to wygląda?

Mon Feb 24, 2014 8:53 am   

Stosowałem już ten stos w swoich projektach na ENC28J60, ale do tej pory
raczej powierzchownie - zarówno sprzętowo jak i programowo opierając się
na opublikowanych przykładach.

Teraz jednak przyjrzałem się dokładniej i jedna rzecz nie daje mi
spokoju. Nie mogę znaleźć w kodzie procedury odpowiedzialnej za obsługę
przerwania sprzętowego od ENC28J60. Co więcej - różne przykłady
wykorzystują różne przerwania. Np. książka M. Kardasia "Pasja
programowania mikrokontrolerów" zawiera przykład, w którym wykorzystano
INT1. W przykładach tuxgraphics.org jest INT0. Nigdzie w opisie nie ma
mowy o tym, że trzeba dostosować kod.

Czyżby przykładowe płytki miały wykonaną ścieżkę tylko z myślą o
możliwym wykorzystaniu tej funkcji w przyszłości? Projektując własne
urządzenie mogę poprowadzić ścieżkę do dowolnego INT-a MCU (albo nawet
zupełnie z niej zrezygnować)? Czy też coś mi umknęło i faktycznie ten
sygnał jest gdzieś wykorzystywany?

Mon Feb 24, 2014 10:40 am   

On Mon, 24 Feb 2014 08:53:51 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Ostatnio też się nad tym zastanawiałem przy projektowaniu płytki,
nawet driver microchipa do ich stosu nie używa przerwania. Być może
dlatego, ż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. Oczywiście rzadsze jej wywoływanie spowoduje
wolniejszy transfer ale na prawidłowe działanie stosu nie powinno
mieć wpływu.

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

--
Marek

Mon Feb 24, 2014 12:07 pm   

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


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?



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ć?



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...



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ę.

Mon Feb 24, 2014 12:58 pm   

On Mon, 24 Feb 2014 12:07:49 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Zostawiłem niepodłaczony, układ już u mnie działa od roku na plytce
testowej bez int, ze wzgledu na to, że driver do encj w stosie nie
korzysta z przerwań a wszystko działa ok to uznałem, że nie będzie mi
potrzebne podłączanie int.



Jest to w pełni funkcjonalny stos, z socketami, funkcje obsługi
używa się podobnie jak w "dużych systemach", aczkolwiek inaczej się
nazywają ale jest analogia bind, connect, read/write. Można czytać i
pisać na raz do kilku zestawionych połączeń.
Stos jest konfigurowalny, można na etapie kompilacji wybrać co ma być
(udp, tcp, icmp, ntp itp) oraz jakie zasoby (bufory) możemy
przydzielić per gniazdo. Daje to dużą elastyczność przy dostosowaniu
do dostępnych zasobów ram. Co ciekawe można nawet wskazać zewnętrzna
ram po spi jako bufor .



Można, ale pamiętaj, że tcp+udp+icmp+ntp + mininalistyczny httpd na
pic18f zajął mi ok 60kB flash, więc warto wybrać układ z min. 128kB.
Do wbudowanego sterownika eth. i tak potrzebujesz driver, więc
objętościowo kod zajmie tyle samo z encj zewnętrznym.
Ostatecznie, ze względu na ograniczony flash i ram w pic18 i dość
rozbudowany httpd przeniosłem się z tym projektem na pic32.

--
Marek

Mon Feb 24, 2014 1:34 pm   

On Mon, 24 Feb 2014 12:07:49 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

tak w temacie adaptacji tcp/ip:
http://www.anfractuosity.com/projects/ultrasound-networking/

--
Marek

Mon Feb 24, 2014 2:21 pm   

W dniu 2014-02-24 13:34, Marek pisze:


To jeszcze nic.
http://tools.ietf.org/html/rfc1149
http://pl.wikipedia.org/wiki/IP_over_Avian_Carriers

Tak swoją drogą jestem ciekaw, czy przypadkiem agencje wywiadowcze nie
korzystają z nietypowych mediów transmisyjnych, celem zmniejszenia
prawdopodobieństwa przechwycenia informacji.

Sam się kiedyś zastanawiałem, czy nie dałoby się niepostrzeżenie
przekazać krótkiej wiadomości przez magnetyzację jakiegoś metalowego
przedmiotu (np. żeliwnej poręczy schodów) i przejechanie po nim głowicą
w chwilę później.

Mon Feb 24, 2014 2:22 pm   

Polecam komentarz:

Menachem Begin
February 18, 2014 Reply
Congratulations, you

Mon Feb 24, 2014 2:34 pm   

W dniu 2014-02-24 12:58, Marek pisze:


Skłaniałbym się właśnie w kierunku czegoś takiego jak PIC18F67J60, ze
względu na 128kB flasha.
Zresztą tak naprawdę mam trochę inne podejście do komunikacji z MCU
przez TCP/IP. Zamiast stawiać serwer www na maleńkim układzie,
skłaniałbym się raczej ku wysyłaniu danych na zewnątrz w "surowej"
formie. Ich gromadzeniem i wyświetlaniem niech się zajmie oprogramowanie
odpalone na jakimś serwerze, niechby to miałoby nawet Raspberry Pi. :)

Dodatkowy plus takiego rozwiązania jest taki, że możemy sobie pozwolić
na posiadanie całej sieci takich małych płytek, które będą spokojnie
realizowały powierzone sobie funkcje, a kontrolą z użytkownikiem już
zajmie się odpowiednie "centrum".

Z tego powodu jak na razie ten minimalistyczny stos z tuxgraphics w
zupełności mi wystarczał, ale jak już mówiłem - dopiero zaczynam zabawę
z podłączaniem MCU do Sieci.

Mon Feb 24, 2014 4:30 pm   

On Mon, 24 Feb 2014 14:34:33 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


Ja mam trochę inne podejście, staram się eliminować PC gdzie się
tylko da (rasp pi to też dla mnie PC), po stronie hosta (hub danych)
eliminuje wszystko co pobiera więcej niż 3W, zdalne czujniki zasilane
tylko fotowoltaniką itp.

--
Marek

Mon Feb 24, 2014 6:26 pm   

W dniu 2014-02-24 16:30, Marek pisze:


Sęk w tym, że w chwili obecnej chyba już większość urządzeń embedded ma
pod spodem zaszytego jakiegoś Linuksa. Dochodzimy do sytuacji, kiedy
nawet części i akcesoria komputerowe są samodzielnymi komputerami z
własnym systemem operacyjnym. Jakiś czas temu popularny był temat
hackowania kart pamięci SD, z wbudowanym WiFi do synchronizacji z
chmurą. Okazuje się, że taka karta to też mały komputerek linuksowy. ;)

Wychodzę z założenia, że jeśli w domowej sieci i tak mam jeden
"serwerek" (w tej chwili właśnie RPi) pracujący cały czas, to nie
zaszkodzi zaprząc go do generowania WebUI. A zwykłe czujki/układy
wykonawcze na MCU niech wysyłają/przyjmują pakiety z surowymi danymi.