Początki z STM32 - Ethernet i kilka inny

nie wiem czy ty nie z unii, ale jeśli nie to może napisał byś coś o "stosach" IP na AVR?

Nie warto, lepiej sobie kup RPi; bedziesz miał Ethernet. Tak naprawdę AVR i STM to tylko wydajność wyróżnia (no i może jakieś peryferia).

Komputerki klasy RPi to jest dopiero przełom bo są wyposażone w system operacyjny z prawdziwego zdarzenia, w którym możesz w C/C++, Python, Bashu, czy co tam chcesz, programować.

Nie wiem co robisz ale jeśli nie jest to produkcja większej ilości szt. jakiegoś wydajnego urządzenia, to zamiana AVR na STM nie da Ci korzyści, poza kwestią poznawczą oczywiście.

jp

W dniu 2014-05-16 13:49, jacek pozniak pisze:

Nie mogę się do końca zgodzić. Po pierwsze komputerki takie jak RasPi, Beaglebone czy Cubbie Board są tak naprawdę właśnie platformami ewaluacyjnymi. Sam czekam na RPi Compute Module...

Taka płytka z OS-em ma jednak dość istotne wady. Największą jest dość długi cykl resetu. Zresetowany (np. watchdogiem) MCU niemal natychmiast wznowi swoją pracę. W przypadku "komputerka" trzeba odczekać kilkadziesiąt sekund albo nawet kilka minut. Poza tym zobacz z jaką prędkością można "machać" stanem pinu na RasPi, gdzie CPU jest taktowany zegarem 700 MHz. System i rozmaite usługi zajmują mnóstwo cykli. Pisząc wasd bezpośrednio do mikrokontrolera masz do dyspozycji nieporównywalnie więcej zasobów.

Nie wspomnę już o tym, że stosując MCU na płytce własnego projektu można sobie pozwolić na większą elastyczność. Nie potrzebujemy jakiegoś interfejsu? Po prostu nie uwzględniamy go w projekcie. Złącze nie zajmuje nam niepotrzebnie miejsca, a zwolnione w ten sposób piny GPIO możemy wykorzystać do innego celu.

Bardziej chodzi mi tutaj właśnie o moc obliczniową i zintegrowane peryferia. Gdybym na przykład kiedyś chciuał szyfrować komunikację pomiędzy komputerem a urządzeniem zbudowaym na MCU, to dodatkowe zasoby się przydadzą. Obsługa pełniejszego stosu TCP/IP to też wielka zaleta. Co jeszcze? Obsługa kolorowych, graficznych wyświetlaczy - tutaj dodatkowe cykle i kilobajty mają spore znaczenie.

To fakt, ale chyba przyznasz, że celem działania systemu nie jest permanentne resetowanie się.

Zgadzam się ale dodam, że to zależy od zastosowania projektu, w bardziej złożonym, pisanym przez Ciebie też może się okazać, że nie będziesz mógł machać tym pinem tak często jak chcesz.

Tu się nie wypowiem bo nie wiem

No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew dopisujesz własny driver do swojego hardware.

jp

W sumie stosując SCHED_FIFO powinno się dać całkiem szybko. Ale MCU oczywiście wygrają.

Użytkownik "jacek pozniak" snipped-for-privacy@flowservice.pl napisał w wiadomości news:5375fb3f$0$2247$ snipped-for-privacy@news.neostrada.pl...

Nie wiem jak ludzie tego używają. Ktoś chciał aby mu zrobić na tym urządzenie. Nigdzie nie idzie znaleźć normalnej dokumentacji, aby np. zaprojektować mechanikę (znalazłem tylko przez kogoś pomierzone i rozrysowane). Nigdzie nie idzie znaleźć dokumentacji portu przeznaczonego do podłączenia LCD. Jak w takich warunkach można zaprojektować urządzenie. Jeszcze nie spotkałem elementu czy modułu do którego byłoby tak mało dokumentacji. P.G.

W dniu 2014-05-16 14:14, jacek pozniak pisze:

Oczywiście. Co nie znaczy, że taką sytuację też powinno się przewidzieć. Lepszy reset, niż zawieszenie systemu wywołane np. jakimś silnym zakłóceniem elektromagnetycznym. W przypadku MCU użytkownik pewnie nawet nie zauważy, że urządzenie na moment przestało działać. Nie można już mieć takiej pewności, jeśli zastosujemy OS, który będzie potrzebował paru minut na ponowne uruchomienie siebie samego i wszystkich usług. Kolejna sprawa to odzyskanie sprawności po utracie zasilania. W niektórych przypadkach lepiej, żeby system wstał natychmiast. Weźmy na przykład jakąś stację monitorującą jakiś proces lub zjawisko. Każda minuta przestoju to przeoczone dane.

Przewaga i tak ciągle pozostaje po stronie MCU. Pisząc wsad sami decydujemy jakie działania zostaną podjęte. Tymczasem nawet mały system operacyjny ma cały zestaw swoich usług, które nie zawsze można tak łatwo wyłączyć, nawet jeśli z nich nie korzystamy. Dobrze napisany program na MCU (zdarzenia, brak pętli opóźniających) będzie działał o wiele sprawniej niż to samo odpalone na jakimś systemie.

Oczywiście nie mówię, że komputerki na kawałku małego PCB są złe. Wszystko zależy od zastosowania. Prostej stacji pogodowej, zegara nixie albo zamka elektronicznego nie budowałbym na RasPi, tylko posłużyłbym się zwykłym MCU. Tutaj nawet zwykła ATmega się sprawdzi. Natomiast robiąc radio internetowe albo odtwarzacz sieciowych multimediów nie bawiłbym się w pisanie wszystkiego od podstaw, tylko wziąłbym RasPi, odpaliłbym na nim MPD i dopisał prosty program do obsługi sprzętowego interfejsu.

Mówisz o szyfrowaniu czy kolorowych wyświetlaczach? Wydaje mi się, że pod STM32 też są do tego narzędzia i biblioteki.

Ja też nie wiem jak tego używają ale zauważ, że mówimy raczej o zastosowaniach czysto amatorskich, pewnie jakaś stacja pogodowa czy inny sterownik węża ogrodowego. Oczywiście do zastosowań komercyjnych nigdy bym nikomu nie zalecał stosowania RPi ani jego zabudowywania.

A w zastosowaniach amatorskich, jeśli chciałbyś mieć webserwer, webkamerkę, Ethernet jakieś I/O (być może wymaga expandera jakiegoś) i do tego prosto programowane, to wybór jest jak najbardziej zasadny. Oczywiście nie będzie tym zainteresowany ktoś kto chce programować do gołego metalu.

A wątkotwórca chce przejść z AVR na STM i w związku z tym podważałem zasadność ponieważ za chwilę zderzy się z jakimiś bibliotekami, nie do końca działającymi i innymi takimi samymi kreatorami aplikacji.

jp

rpi nie polecam, zeby to sie uruchomilo musi byc binarny sterownik graficzny, nawet jak sie grafiki na uzywa np. na serwerach, czyli zaden system w pelni open source na tym nie pojdzie

debian armhf na tym nie pojdzie (trzeba instalowac jakies dziwactwa pokroju raspbian) zeby zamiast broadcam bylo cortex-a7 + mali to juz byloby cos

RMII/MI nie jest naprostszym sposobem podlaczeniem wymaga sporo lini, niektore uklady PHY konfiguruja sie na podstawie stanu mulipleksowanych po resecie lini, trzeba pamietac o tym ze PHY tez ma wlasny adress. Sam kontroler ethernetu w STM32 ma dedykowane DMA i dziala bez zarzutu.

Stosuje LwIP, ma multum opcji konfiguracyjnych, bardzo rozbudowane logi. Od razu sie nastaw ze zapoznanie sie z tym stosem to nie bedzie 5 minut. Na 128kB udalo mi sie postawic webserver, mailserver i pare dedykowanych "demonow". Ale powiedzmy sobie szczerze do sieci to jest min. 8MB i linux.

wget mi pokazuje 2.6 MB/s.

Zalezy co chcesz. Mi plytki ewaulacyjne zdecydowanie ulatwiaja uruchamianie wlasnych urzadzen.

Materialy marketingowe twierdza ze daje spokojne radze. Ale nie mam w tym temacie doswiadczen.

Pozdrawiam

Marek

Powiem wprost; nie wiem co jest lepsze, to są akademickie dyskusje ponieważ nikt nie powinien do krytycznych zastosowań wybierać rozwiązania opartego na RPi ani na jakimś niesprawdzonym STM, AVR, PICu. Do takich zastosowań to przede wszystkim rozwiązania SPRAWDZONE.

Tak to prawda pod warunkiem dookreślenia sformułowania "będzie działał o wiele sprawniej"

Zgadzam się.

Może są, ale np. taki xWindows (jęśli robiłbym coś a'la kiosk albo coś innego graficznego) lub ssh (jeśli robiłbym szyfrowane połaczenia) lub webserwer (co mi obsłuży wiele połaczeń na raz) lub baza danych lub cokolwiek bardziej zaawansowanego niż "machanie pinem" to wolałbym wziąć raczej z Linuksa niż z jakichś bibliotek do STM32. Ja nie mówię, że STM jest zły. Po prostu świat idzie do przodu i opieranie się na "gołym metalu", jakikolwiek szlachetny on by nie był, nie wnosi nic nowego. To tak jak z Indianami i przysłowiowymi koralikami i lusterkami, które im z Europy przywożono; ładnie błyszczały, kolorowe były, ale i tak nic nowego nie wnosiły, bo naprawdę wartościowe było złoto.

jp

W dniu 2014-05-16 19:56, Marek Borowski pisze:

Chyba jednak nie jest aż tak źle, jak w przypadku np. RTL8019? ;)

Jak mniemam istnieją jakieś biblioteki, które ułatwiają skonfigurowanie układu i nawiązanie komunikacji?

Przymierzam się do zakupu tej książki:

Tutaj nie chodzi o rozwiązania "do sieci" ale raczej o urządzenia pełniące określoną funkcję, które mogą się kontaktować z użytkownikiem i światem przez sieć. Czyli jak już wspominałem - nie budowałbym w ten sposób internetowego radia, routera albo jakiejś pamięci NAS. Jednak zegar z synchronizacją czasu i konfiguracją przez WWW/telnet, zamek raportujący zdarzenia do zewnętrznego serwera, jakiś zestaw czujników - to już inna sprawa.

Więc faktycznie jest zauważalna różnica w porównaniu z AVR-ami i ENC28J60. ;)

Robilem bardzo podobnie, tzn. najpierw pająk na stykowej. Jak taki układ pochodził trochę (aż koty zaczynanały z nudów wyciągać kabelki z tego pająka) to robilem płytkę docelową. Po kilku układach zorientowałem się, że buduje układy z powtarzających się elementów, więc może zaprojektować taką uniwersalną płytkę (i zrobić ją w kilku egz.) która będzie miała miejsce na wszystkie najczęściej używane podzespoły, wlutowywane na miarę potrzeb. I tak powstała prywatna płytka "ewaluacyjna" z pic32, encj, can, usb host, rfm12b, 5 przekaźników, 2 we 230V przez optoizolacje, złącze z 8 uniwersalnych I/O, złącze do tel. gsm, złącze do zasilania (i ładowania) z aku 12V (płytka w 1 wersji robi za centralkę alarmową) itd. Teraz właściwie każdy pomysł realizuje na tej plytce wlutowując tylko to, co potrzeba. Nawet teraz na pająku nic nie testuję tylko od razu tą uniwersalną płytkę składam.

Linuxa używam od 20 lat (wyłącznie), jednak np. taki mikroserwerek tcp postawiony na mcu i realizujący konkretne zadania niczym Linuxowi nie ustępuje a osobiście uważam, że ma zalety: szybki "boot" (sekunda), niski pobór prądu, mniejsza komplikacja softu do debugowania (jeśli coś działa niezgodnie z oczekiwaniami), prosta konstrukcja sprzętowa do ew. napraw. itp. Nie twierdzę, że Raspi jest źle, ale nie mogę się do niego.przekonać, dla mnie to PC , tyle że "sfilcowany". Rozmiary są chyba jego jedyną zaletą, a wady odziedziczył po PC, bo w środku to nadal PC z cała jego komplikacją.

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.

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:

pzdr mk

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

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