Stos TCP/IP z tuxgraphics.org

Loading thread data ...

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

Reply to
Marek

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

Reply to
Atlantis

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.

operacyjny

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.

Reply to
Marek

tak w temacie adaptacji tcp/ip:

formatting link

Reply to
Marek

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

To jeszcze nic.

formatting link
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. :)

Reply to
Atlantis

Się napracował. Polecam komentarz:

Menachem Begin February 18, 2014 Reply Congratulations, you’ve invented ‘the modem’.

Kidding, mostly. admin February 18, 2014 Reply Hehe, yeah you’re completely right though. It was fun learning how to do it using Gnuradio though.

Reply to
Sylwester Łazar

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.

Reply to
Atlantis

oprogramowanie

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.

Reply to
Marek

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.

Reply to
Atlantis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.