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?

do góry

Atlantis wrote:

> 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?
Atmega128 to absolutne minimum, jeśli coś chcesz aby to robiło jakieś
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

do góry

On Wed, 06 Aug 2014 22:10:44 +0200, Atlantis <m...@w...pl>
wrote:
> Czy powinienem się spodziewać, że stos zajmie mi momentalne cały
MCU?

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

do góry

W dniu 06.08.2014 o 22:10, Atlantis pisze:
> /ciach/
>

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.

do góry

butek wrote:

> W dniu 06.08.2014 o 22:10, Atlantis pisze:
>> /ciach/
>>
>
> 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.
Co tu rozumieć, hobby.
>
> Nie prościej wziąc skrojonego na miarę STM'a albo nawet mocniejszego
> PIC'a zamiast próbować wynajdywać kwadratowe koło?
Pewnie wątkotwórca kombinuje na tym co się zna.
>
> 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.
Taniej to wyjdzie to co jest proste i tanie.
Osobiście się nie dziwię tym kombinacjom, pewnie STM jest nowocześniejszy
ale kryterium 'lepszości' już nie jest takie oczywiste.

jp
>

do góry

W dniu 07.08.2014 o 00:31, jacek pozniak pisze:
> Co tu rozumieć, hobby.

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.

do góry

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

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

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.


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

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

do góry

On 2014-08-07 01:33, butek wrote:
[...]
> 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.
Tu nie o szerokość słowa chodzi tylko o ilość RAM. Współczesny 8-bitowy
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. :-D

do góry

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

> Atmega128 to absolutne minimum, jeśli coś chcesz aby to robiło jakieś
> użytkowe rzeczy.
> Chodzi zwłaszcza o RAM; minimum 1kbajt RAM i 10 kbajtów ROM zajmie Ci
> tcp/ip.

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?

do góry

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

> 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

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?

do góry