On 8/6/2014 10:10 PM, Atlantis wrote:
> Wracając do tematu obsługi TCP/IP na małych mikrokontrolerach...
>
Jak dla mnie TCP/IP sie zaczyna od ARMa i 128kB+ pamieci RAM.
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.

do góry

W dniu 07.08.2014 o 11:31, Atlantis pisze:
> 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?

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

do góry

Atlantis wrote:

> 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.
Ot choćby te UDP; ja na przykład nie wiedziałbym jak przez UDP połączyć się
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ł.
>
> 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.
Przed laty ktoś napisał jakiś serwer na 512 słowach(!) flasha i kilkunastu
bajtach RAM, interfejs na RS232, ot taka ciekawostka.
>
> 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?
chyba coś koło 20 bajtów (piszę z głowy RemoteIP remote_port, local_port,
seq1, seq2 i coś tam jeszcze.)

jp

do góry

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

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

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.

do góry

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

> Ot choćby te UDP; ja na przykład nie wiedziałbym jak przez UDP połączyć się
> 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.

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


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


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

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


> chyba coś koło 20 bajtów (piszę z głowy RemoteIP remote_port, local_port,
> seq1, seq2 i coś tam jeszcze.)

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?

do góry

>
>
>> chyba coś koło 20 bajtów (piszę z głowy RemoteIP remote_port, local_port,
>> seq1, seq2 i coś tam jeszcze.)
>
> 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?
uIP nie implementuje wszystkich mechanizmów bo był projektowany na małe
urządzenia.
Poczytaj sobie pdf; tam jest opisany sposób realizacji i ograniczenia.

jp

do góry

On Thu, 07 Aug 2014 11:31:33 +0200, Atlantis <m...@w...pl>
wrote:
> 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?

Licząc. Bufory rx/tx gniazd (każde gniazdo ma bufor rx i bufor tx) są
statyczne i definiowane na etapie kompilacji. Liczba buforów gniazd
tcp określa liczbę jednocześnie możliwych otwartych połączeń, a
jeden pojedynczy bufor może być nawet wielkości 1 bajta, jeśli
chcemy. Ale oczywiście maleńki bufor będzie mocno ograniczał
transfer. Rozsądna wielkość bufora to 20-100 bajtów. Jeśli chcemy
mieć dwa gniazda przy buforze 20 bajtów mamy (20rx+20tx)*2 gniazda
daje to 80 bajtów. Sam stos (w zależności jakie moduły wkompilujemy)
potrzebuje nie więcej niż 100 bajtów. Jeśli chcemy szybsze osiągi z
większymi buforami gniazd to można je umieścic w ramie encj (8KB)
zwalniając tym ram mcu. Jeśli wiemy, że nasze urządzenie więcej
wysyła niż odbiera, możemy dla danego gniazda zwiększyć bufor tx
kosztem rozmiaru rx. Stos mhcp jest nieźle zoptymalizowany pod kątem
potrzebnego mu ram.
Zdefiniowane bufory są pogrupowane (co determinuje ich
przeznaczenie), każda grupa ma swój identyfikator, który jest
wykorzystywany w wywołaniu funkcji inicjujacej połączenie, to
determinuje jaki bufor zostanie przypisany temu połączeniu i jakie
osiągi ono będzie miało.

To tak w skrócie, bo o stosie mchp to książkę można napisać....

--
Marek

do góry

On Thu, 07 Aug 2014 13:25:02 +0200, Atlantis <m...@w...pl>
wrote:
> 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?

To jest bardziej skomplikowane, w stosie mchp buforowany jest payload
a nie cały pakiet. O ile mi wiadomo (z luźnej analizy źródeł, proszę
mnie poprawić, jeśli się mylę) pakiet jest odbierany za pośrednictwem
enc28j60, ale payload jest "wyciągany" w mcu i (jeśli wybierzemy ram
encj jako bufor payloadu) jest zapisywany z powrotem do ram encj, z
którego znowu (kolejny transfer spi) jest kopiowany do "warstwy
aplikacji" przez funkcje api TCPGet* (gdy chcemy pobrać odebrane
bajty payloadu).

--
Marek

do góry

W dniu 2014-08-07 08:56, Atlantis pisze:

> 2) Procki STM i PIC w wersji 32bit posiadają często zintegrowane moduły
> Ethernet, ale tylko MAC. PHY trzeba podpiąć

świat się nie kończy na STM i PIC

--
Pozdr.
Michał

do góry

W dniu 2014-08-07 21:15, Michał Baszyński pisze:

> świat się nie kończy na STM i PIC

Co nie zmienia faktu, że są one (razem z AVR-ami) jednymi z
najpopularniejszych rodzin. Oczywiście można kombinować z jakimiś
alternatywami, szukając układu, który będzie miał wszystkie potrzebne
peryferia. Jednak podejrzewam, że ostatecznie na naukę nowej platformy
poświęcę więcej czasu, niż na zaprojektowanie płytki zawierającej
zewnętrzny kontroler.

do góry