Goto page Previous 1, 2
jacek pozniak
Guest
Thu Aug 07, 2014 12:54 pm
Quote:
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
Marek
Guest
Thu Aug 07, 2014 12:56 pm
On Thu, 07 Aug 2014 11:31:33 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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
Marek
Guest
Thu Aug 07, 2014 1:16 pm
On Thu, 07 Aug 2014 13:25:02 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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
MichaĹ BaszyĹski
Guest
Thu Aug 07, 2014 7:15 pm
W dniu 2014-08-07 08:56, Atlantis pisze:
Quote:
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ł
Atlantis
Guest
Fri Aug 08, 2014 7:27 am
W dniu 2014-08-07 21:15, Michał Baszyński pisze:
Quote:
ś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.
Goto page Previous 1, 2