Jak efektywnie wykorzystać Ethernet na STM32: ENC28J60 czy wbudowany kontroler?

Sat May 17, 2014 9:59 am   

W dniu 2014-05-17 00:39, Marek pisze:


Podejrzewam, że za kilka lat pojawią i upowszechnią się układy, które w
jednej obudowie TQFP/LQFP będą mieściły cały linuksowy komputerek. CPU,
kilkaset MB RAM-u i parę GB flasha z zapisanym systemem operacyjnym.
Niech tylko prawo Moore'a popracuje jeszcze trochę. ;)

Nie powiem nie, chętnie bym skorzystał z czegoś takiego. Jenak nie
wydaje mi się, żeby miało to kiedyś zastąpić tradycyjne MCU. W pewnych
sytuacjach prostota zapewniana przez MCU daje przewagę. Lepiej odpalić
program bezpośrednio na rdzeniu procesora, niż stawiać po drodze
pośrednie platformy w rodzaju systemu operacyjnego, maszyny wirtualnej
(jak to ma miejsce w Androidzie) itp.

Sat May 17, 2014 4:37 pm   

W dniu 2014-05-16 12:06, Atlantis pisze:

Jeśli krytyczna jest wydajność to nie ma co się zastanawiać:
mikrokontroler z wbudowanym Ethernetem.
Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
może być wygodniejsze (np. design PCB).


uIP tylko do najprostszych aplikacji typu wysłanie lub odbieranie
pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
się).
Na sensowną wydajność z uIP nie licz przy przesyłaniu danych strumieniem
TCP. Stos ten nie wyśle żadnego kolejnego pakietu dopóki poprzednik nie
odbierze ACK poprzedniego pakietu. A druga strona będzie zwlekać z
wysłaniem pakietu potwierdzenia, ze względu na algorytm Nagle'a.

lwIP -- jakiś czas temu trenowałem go trochę zarówno na STM32 jak i
Luminary Micro.
Wrażenia mieszane: z jednej strony widać że w ten projekt włożono dużo
pracy, wiele parametrów podlega konfiguracji, możliwość wyrzucania
komunikatów diagnostycznych, widać że ma potencjał co do wydajności i
wierzę, że w odpowiednich rękach ten stos może dawać stabilne rozwiązania.
Z drugiej strony skąpa dokumentacja, kod źródłowy ze względu na mnogość
opcji nie jest łatwy w analizie, a miejscami po prostu paskudny i trudny
do debugowania (zwłaszcza realizacja generyczności kodu przez "#define,
#include, #undefine, #define, #include, #undefine, ...").

lwIP to taka machina z wieloma gałkami, pokrętłami i z modułami które
można podmieniać, ale nie w każdej konfiguracji stabilnie działa. Raczej
dla bardzo cierpliwego użytkownika, który nie boi się, a wręcz lubi
pogrzebać w bebechach swojej maszyny.

lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
szybko stanie się koszmarem.


Testowo z lwIP i STM32F107 (64kB RAM, 72 MHz, gdy to testowałem ST nic
lepszego jeszcze nie miało w ofercie) byłem w stanie (ledwo, ledwo ale
jednak) zapchać rurę 100 Mbit/s przy transmisji w sieci lokalnej --
serwer TCP, który po podłączeniu generował pseudolosowy strumień danych,
klient (aplikacja na PC) odbierał dane i weryfikował. Testowałem aż mi
się nie znudziło, dziesiątki GB danych szły bez problemów.

Po ożenieniu lwIP+FreeRTOS wydajność spadła ale wciąż było to
kilkadziesiąt Mbit/s. A w praktycznej aplikacji wąskim gardłem i tak
okazała się magistrala SPI (18 MHz) na której wisiała pamięć Flash z
której czerpałem dane.


Moim zdaniem warto, bo Ethernet to już szybkie przebiegi i łatwo
popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
hardware. Lepiej oprzeć się na czymś sprawdzonym.


Co prawda, dla PIC32, ale dla wyrobienia poglądu wystarczy:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en537998

Jeśli zależy Ci na wyższej wydajności wybierz MCU z hardwarowym
wsparciem AES.

pzdr
mk

Sat May 17, 2014 4:58 pm   

On Sat, 17 May 2014 18:37:05 +0200, mk <reverse_lp.pw@myzskm> wrote:

72Mhz i zapchałeś 100Mbit ethernet? Ten stm był z wbudowanym eth.
użyty był dma?

--
Marek

Sat May 17, 2014 6:51 pm   

W dniu 2014-05-17 18:58, Marek pisze:

STM32F107, czyli miał wbudowany kontroler Ethernet.
DMA był użyty. W ogóle w STM32 DMA od Ethernetu to już całkiem
zaawansowana maszynka, ale jej potencjał nie był dobrze wykorzystywany
przez drivery jakie (wtedy, nie wiem jak dziś) dostarczało ST (np.
stosowanie pooling w oczekiwaniu na zwolnienie przez DMA bufora, gdy
wszystkie bufory wysyłkowe się zapchały, a mamy już gotową porcję
danych; kopiowanie danych między lwIP, a diverem).
Mimo to rura TCP była w stanie przenosić pod 11 MB/s, co (uwzględniając
narzuty) jest bliskie nasycenia Ethernetu 100M.
Też byłem mile zaskoczony. Biblioteki komercyjne (np. od Express Logic)
zaczęły się chwalić możliwością nasycenia Ethernetu dopiero wraz z
nadejściem STM32F207 (120 MHz, 128 kB RAM).

pzdr
mk

Mon May 19, 2014 6:15 am   

W dniu 2014-05-17 00:19, Marek pisze:


Ja mam podobnie. To znaczy zauważyłem, że ciągle korzystam z tego samego
optymalnego połączenia pomiędzy obwodem zasilania, ATMegą i ENC28J60.
Praktycznie to samo ustawienie elementów, tak samo prowadzone ścieżki
itp. Tylko zależnie od projektu dookoła umieszczam różne peryferia.
Teraz projektując płytkę biorę "podstawę" pożyczoną z jakiegoś
wcześniejszego projektu i na jej podstawie kontynuuję projektowanie
tego, co chcę uzyskać.


Mi trochę szkoda byłoby miejsca. Zwykle zmierzam do uzyskania
maksymalnie kompaktowego PCB, przynajmniej jak na moje amatorskie
warunki.

Mon May 19, 2014 6:32 am   

W dniu 2014-05-17 18:37, mk pisze:


Hmm... Istnieje jakiś standard układu wyprowadzeń w MCU z wbudowanym
kontrolerem Ethernetu i zewnętrznym interfejsie PHY? Można w miarę łatwo
poprowadzić magistralę złożoną z równoległych ścieżek, czy raczej trzeba
będzie się bawić w zworki i przelotki?



Do tego spokojnie wystarczy Tuxgraphics, który jest w dodatku banalny w
obsłudze i konfiguracji. Czegoś lepszego potrzebowałbym np. do obsługi
telnetu.



To raczej jeszcze daleko przede mną. Poza tym gdybym potrzebował
wielowątkowości do jakiegoś poważniejszego projektu, pewnie sięgnąłbym
po jakąś linuksową płytkę. Zresztą zanim w moim przypadku zajdzie taka
potrzeba, to na rynku pojawią się tanie MCU SoC, mieszczące kompletny
linuksowy komputerek w obudowie LQFP. ;)



Mówimy o Fast Ethernet czy o Ethernecie w ogólności. Bo zaprojektowałem
już kilka płytek z ENC28J60 i nie miałem jak dotąd żadnych problemów.
Pingi dochodzą bez gubienia pakietów. Nie pamiętam, żebym kiedyś nie
otrzymał odpowiedzi na wysłany pakiet UDP.



Gdybym jednak chciał zaprojektować własną płytkę, to o czym przede
wszystkim powinienem pamiętać?

Mon May 19, 2014 9:26 am   

Am 16.05.2014 12:06, schrieb Atlantis:

W mojej nowej robocie panuje od około roku STM, do tego czasu był
używany AVR. Szef "rozkazał" przejście z różnych powodów, ale główną
przyczyną była cena. Używamy gotowych modułów, które kosztują
praktycznie śmieszną cenę. Jako, że robimy małe serie (10-100 sztuk)
robienie płytki pod gołe procesory i ich wlutowywanie po prostu się nie
opłaca. Taki STM32F3xx kosztuje jako moduł ok. 8EUR, solo może połowę,
ale trzeba zrobić layout i to ścierwo wlutować z całą menażerią dookoła.
Przy cenie godziny pracy ok. 50EUR to ne je ono.
W tej chwili mamy w użyciu dwa systemy, jeden oparty na F3, drugi na F4.
Na F3 są robione urządzenia, które są łączone z hostem przez USB/RS232,
na F4 z ethernetem. Choć nasze urządzenia są same w sobie proste, to
systemy mogą być dość skomplikowane. Np. taki jeden F4, który robi
kolega, steruje 32 RS232, 32 GPIO. Całość to ok. 100 urządzeń
połączonych ethernetem.
Moje urządzonko hula sobie na F3, ale będę je w tym tygodniu portował na
F4, bo potrzebuję sterować ethernetem, a do F3 nie wejdzie mi tcp/ip.

Jak już pisałem używamy gotowych płytek prototypowych. Jest na nich
wszystko, co potrzeba. Na mojej płytce robię co muszę, a STMa wstawiam
jak starego dobrego DILa do gniazdka i już wsio lata.

Waldek



--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.

Mon May 19, 2014 4:56 pm   

W dniu piątek, 16 maja 2014 12:06:31 UTC+2 użytkownik Atlantis napisał:



wersji procesora.
, np.:
- ChibiOS/RT http://www.chibios.org/dokuwiki/doku.php
- eCos http://ecos.sourceware.org/
- mBed https://mbed.org/
- NuttX http://nuttx.org/
i nie bawic sie w wynajdowanie kola.




a czasem wręcz rozdaje;)
STM32F4DISCOVERY (moduł z kontrolerem):
http://pl.mouser.com/ProductDetail/STMicroelectronics/STM32F4DISCOVERY/?qs=J2qbEwLrpCGdWLY96ibNeQ=STM32F4DIS-BB (płyta bazowa z PHY):
http://pl.mouser.com/Search/ProductDetail.aspx?qs=tp9Gh8MiPay9fbHGaE7oZQ%3d%3d

Z powodzeniem nisko-seryjna produkcje można oprzeć o moduły ewaluacyjne.

Mon May 19, 2014 6:37 pm   

W dniu 2014-05-19 08:32, Atlantis pisze:

Jeśli istnieje to nie zauważyłem
Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
rady.


uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
lobbował za uIP.


W jakiś RTOS warto zainwestować. Warto stosować nawet mało-średnich
projektach. Jak przedstawiłeś jesteś na etapie przesiadki 8 do 32-bitów.
Jeśli jeszcze nie masz w arsenale swoich kompetencji budowania aplikacji
mikrokontrolerowych opartych o RTOS, to ja na Twoim miejscu bym się tym
zajął niż jakimiś Ethernetami. A przy aplikacjach Ethernetowych wiedza
ta będzie tylko procentować.

Jeśli chodzi o pingwina stawianego na małych platformach, to się już z
nim przepraszam od jakiegoś czasu. Zgadzam się, że Ethernet na
mikrokontrolerze to zawsze mniejsza lub większa rzeźba. Nawet jak się
wyrzeźbi to apetyt rośnie w miarę jedzenia: a to przydała by możliwość
równoległej obsługi większej liczby połączeń, a to jeszcze jeden serwis,
a to jeszcze wypaśniejsze i ładniejsze www (czyli trzeba je komuś
zlecić, kto się tym profesjonalnie zajmuje; a jak ktoś zrobi, to zrobi
np. na Ruby on Rails ), a w urządzeniu które na początku miało być
prostym rejestratorem danych w końcu dochodzi się do konkluzji: a
dlaczego by zmagazynowanych danych nie udostępniać w postaci bazy
danych... Ale z drugiej strony jakieś proste, ale bardzo szybkie I/O,
czy jakieś inne ustrojstwa mające pracować w rygorze czasu rzeczywistego
(STM32 np. wspiera IEEE1588).


Piszę o Fast Ethernecie i raczej o połączeniach na drodze PHY-wtyk.
A "u mnie działa" nie równa się "u klienta działa" :)


Poprawny dobór elementów (czasami nie tylko co do wartości znamionowych
głównego parametru), właściwe zasilanie, właściwy design płytki (patrz
pdfy z zaleceniami), sprawdzenie częstotliwości pracy generatora, trochę
szczęścia.
Inna jeszcze sprawa czy robisz dla siebie, czy robisz produkt który musi
przejść testy EMC.

pzdr
mk

Tue May 20, 2014 4:12 pm   

a może Ktoś napisać czym programuje się te procki, jaki toolchain? może
jakieś wprowadzenie w dziedzinę, byłbym zobowiązany...

Tue May 20, 2014 5:49 pm   

W dniu 2014-05-20 18:12, tusk, donald tusk pisze:

2. Attolic True Studio
Obie aplikacje darmowe dla 32kB kodu. Niestety sama biblioteka panela
dotykowego to ponad 40kB.
3. CooCox (darmowy)
4. Literatura po polsku - książki z wydawnictwa BTC (drogie)
5. Płytka - mnóstwo w Kamami, AVT, Propox itd. Godne polecenia (IMHO)
-Maple mini - moduł w formie DIL
-seria Disco(very)
Ciekawy jest również moduł HY-miniSTM32V (zawiera kolorowy wyświetlacz z
panelem dotykowym cena ok 50$).

Tue May 20, 2014 6:06 pm   

W dniu 2014-05-20 19:49, Andrzej pisze:

dziękuję, ale potrzebuję małych wyjaśnień, jeśli chodzi o Keila to
mówisz o tym: KEIL MDK ARM? jeśli nie to jak brzmi pełna nazwa programu?

Tue May 20, 2014 6:25 pm   

W dniu 2014-05-20 20:06, tusk, donald tusk pisze:

Tue May 20, 2014 6:45 pm   

W dniu 2014-05-20 20:25, Andrzej pisze:

dzięki, a patrzyłem tak sobie na USB, piszą że kod dostępny tylko w
MDK-Professional, a może da się skądś zassać?

Tue May 20, 2014 6:48 pm   

a jeśli chodzi o rozeznanie w samym TCP/IP to jaką książką warto by się
zainteresować?