uIP na małych mikrokontrolerach: Jakie zasoby będą potrzebne dla UDP i Telnet?

Wed Aug 06, 2014 8:10 pm   

Wracając do tematu obsługi TCP/IP na małych mikrokontrolerach...

Jak już wspominałem, od jakiegoś czasu bawię się łącznością sieciową na
ośmiobitowych MCU (głównie Atmegi). Zacząłem od ENC28J60 i
minimalistycznego stosu Tuxgraphics. Używałem go głównie do przesyłania
informacji za pośrednictwem pakietów UDP. Nie korzystałem z bardziej
zaawansowanych funkcji, jak np. przydzielanie numeru IP z DHCP albo
zapytania DNS. Nie realizowałem także obsługi WWW - tego zresztą w ogóle
nie mam zamiaru robić na tak małych MCU. Nawet najprostsze strony
zabierają sporo flasha.

Oczywiście przy takim podejściu stos zajmował stosunkowo niewielką ilość
pamięci. Oczywiście jeszcze lepiej wyglądała sytuacja w przypadku
układów Wiznetu, wyposażonych w sprzętową obsługę stosu.

Teraz zastanawiam się jak bardzo zwiększy się zużycie zasobów po
przejściu na bardziej zaawansowany stos (np. uIP albo ten od
Microchipa). Migracja będzie konieczna, bo Tuxgraphics niestety nie
nadaje się do postawienia serwera telnetu.

Załóżmy, że urządzenie ma się komunikować ze światem za pośrednictwem
UDP, udostępniając także konsolę konfiguracyjną przez telnet. W
przyszłości w grę może wchodzić także dodanie innych funkcji (NTP, DNS).
Musi też oczywiście pozostać odpowiednia ilość zasobów na realizację
normalnych zadań (parsowanie poleceń, wykonywanie pomiarów, załączanie
wyjść).

Czy powinienem się spodziewać, że stos zajmie mi momentalne cały MCU?
Powinienem zapobiegawczo zastosowań większy procek (np. Atmega128/1284)
czy nie jest tak źle i coś w stylu Mega32/328/644 spokojnie wystarczy?

A może powinienem już od razu postawić na układy Wiznet i nie przejmować
się zużyciem zasobów przez stos?

Wed Aug 06, 2014 8:40 pm   

Atlantis wrote:


użytkowe rzeczy.
Chodzi zwłaszcza o RAM; minimum 1kbajt RAM i 10 kbajtów ROM zajmie Ci
tcp/ip.
Z doświadczenia wiem, że 2 kbajty zwykle nie starcza aby mieś tcp/ip i do
tego jakieś bufory na UARTy i komfortowo napisać funkcje realizujące
zasadniczą część użytkową; po prostu zbyt szybko dochodzi się do ściany.

jp

Wed Aug 06, 2014 8:51 pm   

On Wed, 06 Aug 2014 22:10:44 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


Stos mchp na 8bit mcu z tcp+udp+dhcp+dns+ntp+httpd+kilka prywatnych
funkcji zajelo ok 60KB flash + ok 100-200 bajtów ram
ten sam stos na 32bit mcu
tcp+udp+dhcp+dns+ntp+httpd+telnetd+usbhost(pendrive dla statycznych
plikow httpd) 130KB flash +20 KB ram, tutaj użyłem wiersze bufory dla
gniazd i bardziej wypasiony serwer http, stąd większe użycie ram niż
w przypadku 8bit.

--
Marek

Wed Aug 06, 2014 9:59 pm   

W dniu 06.08.2014 o 22:10, Atlantis pisze:

Sorry, że się wtrące, ale od kilku wątków przeglądam te Twoje boje z
8-bitowym AVR w połączeniu z ethernetem itp. i no, nie rozumiem.

Nie prościej wziąc skrojonego na miarę STM'a albo nawet mocniejszego
PIC'a zamiast próbować wynajdywać kwadratowe koło?

Przecież uC do takich zastosowań w tej chwili są dime-a-dozen, pewnie
taniej wyjdzie niż ten 8-bit AVR + cała reszta peryferiów typu ENC28x. A
przy okazji czegoś nowego można się nauczyć, skoro to projekt one-off
tylko dla siebie.

--
butek
Safety note: Don't put all your enriched uranium hexafluoride in one
bucket. Use at least two or three buckets and keep them in separate
corners of the room. This will prevent the premature build-up of a
critical mass.

Wed Aug 06, 2014 10:31 pm   

butek wrote:


Osobiście się nie dziwię tym kombinacjom, pewnie STM jest nowocześniejszy
ale kryterium 'lepszości' już nie jest takie oczywiste.

jp
>

Wed Aug 06, 2014 11:33 pm   

W dniu 07.08.2014 o 00:31, jacek pozniak pisze:

No oczywiście, że hobby, ale hobby już od dawna ma dostępne w ręcznie
lutowalnych obudowach coś więcej niż 8-bitowy AVR praktycznie bez
sprzętowych peryferiów oprócz dwóch/trzech timerów i gównianego ADC z
równie gównianym wbudowanym REF do tegoż Nie jestem zwolennikiem
migania LED od razu za pomocą ARMa, ale sorry, zaprzęganie 8-bitowca do
software'owej obsługi interfejsów typu USB/Ethernet i innych mocno
wymagających jest po prostu rzeźbieniem w gównie, wartość edukacyjna
zero. W podobnej cenie można użyć uC trochę bardziej powyżej lat 90-tych
zeszłego wieku, który ma wymagane interfejsy obsługiwane sprzętowo,
support w sieci świetny, wartość edukacyjna nie do przecenienia, a i
pozostaje więcej czasu na część hobby pod tytułem: moje urządzenie.

--
butek
Safety note: Don't put all your enriched uranium hexafluoride in one
bucket. Use at least two or three buckets and keep them in separate
corners of the room. This will prevent the premature build-up of a
critical mass.

Thu Aug 07, 2014 6:56 am   

W dniu 2014-08-06 23:59, butek pisze:


Jasna, że lepiej. Jednak trzeba wziąć pod uwagę kilka kwestii:
1) Taki STM32 w pełni pokaże swoje możliwości dopiero z większym stosem,
np. lwIP. Z tego co czytałem dokładne zapoznanie się z nim wymaga jednak
trochę czasu. Zabawę z takim tuxgraphics z kolei można było zacząć
praktycznie "z marszu". Podejrzewam, że w przypadku uIP wygląda to podobnie.
2) Procki STM i PIC w wersji 32bit posiadają często zintegrowane moduły
Ethernet, ale tylko MAC. PHY trzeba podpiąć, a to ładnych kilkanaście
linii. Trochę to komplikuje projekt płytki, a przecież chodzi i tak o
przesyłanie niewielkich ilości danych. Można też wykorzystać zewnętrzny
sterownik na SPI, ale to przecież dokładnie takie rozwiązanie, jakie
stosuję teraz.
3) AVR-y znam w miarę dobrze, zarówno od strony programowej, jak i
sprzętowej (zaprojektowałem kilka płytek pod własne urządzenia, w tym te
działające w sieci). Z STM-ami jestem na etapie zrobienia paru
"edukacyjnych" przykładów. Będę musiał się jeszcze trochę podszkolić,
zanim zdecyduję się na jakiś większy projekt.



Z tą różnicą, że kilka sztuk Atmegi 328 i 644 już leży w szufladzie.
Atmega 128 chyba też się znajdzie. Układ ENC28J60 został mi po
poprzednim projekcie, a jakiś czas temu przy okazji innego zamówienia w
kupiłem w TME sztukę albo dwie W5500.
Taniej jednak wykorzystać to co się ma, niż robić nowe zakupy. Pod
warunkiem oczywiście, że posiadane elementy wystarczą. Tutaj jednak nie
ma wielkich wymagań - układ ma sterować kilkoma wyjściami (załączanie
światła przez triaki, może jakiś przekaźnik) oraz mierzyć kilka wartości
(napięcie i częstotliwość sieci, temperatura) oraz komunikować się z
otoczeniem przez UDP (sterowanie) i telnet (konfiguracja).

Thu Aug 07, 2014 7:55 am   

On 2014-08-07 01:33, butek wrote:
[...]

uC spokojnie wystarczy do obsługi jakiegoś lekkiego stosu TCP/IP o ile
będzie miał wystarczającą ilość RAM-u. Problemem jest to, że typowe
8-bitowce nie mają wystarczającej ilości... Z drugiej strony, programowa
realizacja USB/Ethernet może być problemem nawet dla "dużego" uC.

Thu Aug 07, 2014 9:29 am   

W dniu 2014-08-06 22:40, jacek pozniak pisze:


Zdefiniuj "użytkowe rzeczy". W przypadku Tuxgraphics prosty serwerek UDP
można odpalić na Atmedze88, miejsca wystarczy na postawienie jakiegoś
nieskomplikowanego parsera i sterowanie wyjściami albo odczytywanie
jakiejś wartości. Mam wrażenie, że od biedy dałoby się coś takiego
zrobić nawet na Atmedze8.

Oczywiście ja chciałbym teraz pójść trochę dalej, odpalając stos, który
potrafi utrzymać otwartą sesję i przesyłać dane w obydwie strony
(Tugraphics pozwala jedynie na przesyłanie "wiadomości" o objętości
nieprzekraczającej jednego pakietu Ethernet). Na pewno zajmie to aż tyle
flasha? A nawet jeśli, to w przypadku Atmegi644 pozostanie jeszcze sporo
miejsca na resztę kodu.

Co do RAM-u to zrozumiałe. Każdy stos potrzebuje miejsca na bufor. Tak
BTW jak bardzo zapotrzebowanie na RAM zwiększa się wraz z każdym
otwartym połączeniem na uIP?

Thu Aug 07, 2014 9:31 am   

W dniu 2014-08-06 22:51, Marek pisze:


Sto do dwustu bajtów!? To chyba nie licząc bufora na pakiety?
Czy może w stosie Microchipa jest to w jakiś sprytny sposób rozwiązane?

Thu Aug 07, 2014 9:54 am   

On 8/6/2014 10:10 PM, Atlantis wrote:

Ponizej to jest rzezba w g*. A tak naprawde aby to mialo sens (czyli np.
implentowalo calosc protokolu aplikacyjnego wraz z obsluga bledow
a nie tylko czesc) i bylo bezpieczne to rozwiaznia Pi podobne.

Pozdrawiam

Marek


BTW: Oczywiscie aby wyslac jeden pakiet UDP z informacja o temperaturze
to mozna uzywac czegos malego ale zdaje sie ze chodzi implementacje
serwerow aplikacyjnych.

Thu Aug 07, 2014 10:03 am   

W dniu 07.08.2014 o 11:31, Atlantis pisze:

Po prostu trzyma bufory w MACu, ma to sens skoro np. pic18f67j60 ma
~3,8kB RAMu a wbudowany MAC ma bufor 8kB.

Thu Aug 07, 2014 10:32 am   

Atlantis wrote:


z tym serwerem wykorzystując ogólnie dostępne narzędzia typu przegladarka
www (lub wget czy też curl, choć te to chyba potrafią). Do tego chyba
potrzebne jest TCP więc funkcjonalność polegająca na UDP jest co najmiej
mało użyteczna.
Kolejna rzecz to DHCP; wierz mi lub nie, ale jeśli będziesz chciał z tym
wyjść poza swój stół warsztatowy to nie ma opcji.
A to dopiero warstwa dość niska; na tym jeszcze trzeba zrobić jakiś
interfejs do konfiguracji ustrojstwa, najlepiej aby był czytelny dla
człowieka i nie polegał jedynie na przesyłaniu jednobajtowych instrukcji bo
po miesiącu się zapomina co jaka znaczy.

No i program użytkowy, który pewnie się będzie rozwijał.

bajtach RAM, interfejs na RS232, ot taka ciekawostka.

seq1, seq2 i coś tam jeszcze.)

jp

Thu Aug 07, 2014 11:25 am   

W dniu 2014-08-07 12:03, Zbych pisze:


A co z układami zawierającymi ENC28J60? One w końcu też korzystają z
stosu Microchipa. Wtedy już trzeba buforować kolejne pakiety po stronie
MCU, czy też dane są na bieżąco przesyłane przez SPI?

Czy w podobny sposób można by to zrobić z RTL8019AS? Układ jest
podłączany do magistrali równoległej i jest widoczny w przestrzeni
adresowej MCU.

Thu Aug 07, 2014 11:35 am   

W dniu 2014-08-07 12:32, jacek pozniak pisze:


Żadne z powyższych narzędzi do tego nie służą. Zresztą przesyłanie
danych pakietami UDP nie jest rozwiązaniem dla końcowego użytkownika, za
to w ten sposób można fajnie zrealizować komunikację M2M. Stawianie
serwera WWW na mikrokontrolerze celem generowania jakiegoś prostego GUI
mija się z cele, przynajmniej takie jest moje zdanie. Lepiej wykorzystać
do tego jakiś istniejący serwer, a jeśli go nie ma - postawić (chociażby
na Raspberry Pi) i to jego skomunikować z czujką czy sterownikiem na MCU.



A po co mi DHCP, jeśli chcę, żeby urządzenie było łatwo identyfikowalne
w okolicznej sieci? Ok - można co chwilę prosić wszystko dookoła, żeby
łaskawie się przedstawiło, bo właśnie pozmieniała się konfiguracja
numerów IP. W mojej lokalnej sieci z DHCP korzystają praktycznie tylko
mobilne urządzenia WiFi. Wszystko inne pracuje na swoich własnych, na
stałe przypisanych numerach.



Telnet i konsola w zupełności wystarczą.



Hmm... A tak z ciekawości, to jak buforowana jest sama wiadomość, na
wypadek, gdyby pakiety ją zawierające dotarły w niewłaściwej kolejności?
No chyba, że stos odrzuca "późniejsze" pakiety, zanim nie przetrawi
tego, na który czeka?