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

Fri May 16, 2014 10:06 am   

Przymierzam się powoli do zrobienia kolejnego kroku w nauce
programowania MCU (do tej pory tylko AVR-y) i wypróbowania 32-bitowych
układów STM.

Mam jednak kilka pytań:

1) Ponieważ w wielu swoich projektach wykorzystuję interfejs Ethernet,
chciałbym się dowiedzieć jak to jest realizowane na tej platformie.
Przeważnie korzysta się z ENC28J60, tak samo jak na ATmegach, czy może
warto zainteresować się układami z wbudowanym kontrolerem? Pytam,
ponieważ te które widziałem nie posiadały wbudowanego transceivera i
trzeba było dołączyć do nich zewnętrzny układ PHY. Które rozwiązanie
zapewnia większą wygodę i wydajność?
2) Jaki stos powinienem zastosować? Coś w rodzaju uIP, czy też z uwagi
na większe zasoby sprzętowe warto od razu zainteresować się lwIP?
3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej?
4) Warto zainwestować w jakąś płytkę ewaluacyjną? Gdy zaczynałem naukę
programowania AVR-ów skleciłem sobie prostą płytkę z Megą8 i łącząc z
płytką stykową budowałem proste układy. Potem eksperymentując z
Ethernetem również skleciłem PCB z Megą328 i ENC28J60. Prawie z niej nie
korzystałem... Podobnie zakupione jakiś czas temu Arduino od paru
miesięcy leży w szufladzie. Po prostu gdy chcę zbudować jakiś układ ze
znanych sobie i/lub dobrze opisanych części, po prostu robię projekt
płytki, wytrawiam ją i buduję co mam zbudować. Nie tworzę tego samego
dwa razy, za pierwszym razem na pająku/płytce stykowej. Czy takie
podejście sprawdzi się również w przypadku STM32, czy tutaj jednak
powinienem zainwestować w jakieś płytkę prototypową?
5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
spodziewać zauważalnych przestojów?

Fri May 16, 2014 10:29 am   

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

Fri May 16, 2014 11:49 am   

Atlantis wrote:


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

Fri May 16, 2014 12:00 pm   

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.

Fri May 16, 2014 12:14 pm   

Atlantis wrote:


permanentne resetowanie się.


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.

dopisujesz własny driver do swojego hardware.

jp

Fri May 16, 2014 2:38 pm   

Atlantis <marekw1986NOSPAM@wp.pl> wrote:


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

--
SELECT finger FROM hand WHERE id = 3;
http://www.chmurka.net/

Fri May 16, 2014 2:58 pm   

Użytkownik "jacek pozniak" <jacek.pozniak@flowservice.pl> napisał w
wiadomości news:5375fb3f$0$2247$65785112@news.neostrada.pl...

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.

Fri May 16, 2014 3:34 pm   

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.

Fri May 16, 2014 4:13 pm   

Piotr Gałka wrote:



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

Fri May 16, 2014 4:27 pm   

On 05/16/2014 01:49 PM, jacek pozniak wrote:

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

Fri May 16, 2014 5:56 pm   

On 5/16/2014 12:06 PM, Atlantis wrote:

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.



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.






uruchamianie wlasnych urzadzen.



Ale nie mam w tym temacie doswiadczen.

Pozdrawiam

Marek

Fri May 16, 2014 6:59 pm   

Atlantis wrote:


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.


wiele sprawniej"

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

Fri May 16, 2014 10:14 pm   

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:
http://www.kamami.pl/index.php?productID=178588
To chyba powinno być dobre wprowadzenie do tematyki.



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.

Fri May 16, 2014 10:19 pm   

On Fri, 16 May 2014 12:06:31 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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.

--
Marek

Fri May 16, 2014 10:39 pm   

On Fri, 16 May 2014 20:59:06 +0200, jacek pozniak
<jacek.pozniak@flowservice.pl> wrote:

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

--
Marek