On 5/16/2014 12:06 PM, Atlantis wrote:
> 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ść?
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.


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


> 3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
> niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)
wget mi pokazuje 2.6 MB/s.


> 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ą?
Zalezy co chcesz. Mi plytki ewaulacyjne zdecydowanie ulatwiaja
uruchamianie wlasnych urzadzen.


> 5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
> spodziewać zauważalnych przestojów?
>
Materialy marketingowe twierdza ze daje spokojne radze.
Ale nie mam w tym temacie doswiadczen.

Pozdrawiam

Marek

do góry

Atlantis wrote:

> W dniu 2014-05-16 14:14, jacek pozniak pisze:
>
>> To fakt, ale chyba przyznasz, że celem działania systemu nie jest
>> permanentne resetowanie się.
>
> 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.
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.

>
>
>> 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.
>
> 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.
Tak to prawda pod warunkiem dookreślenia sformułowania "będzie działał o
wiele sprawniej"
>
> 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.
Zgadzam się.
>
>
>> No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
>> dopisujesz własny driver do swojego hardware.
>
> Mówisz o szyfrowaniu czy kolorowych wyświetlaczach? Wydaje mi się, że
> pod STM32 też są do tego narzędzia i biblioteki.
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

do góry

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

> RMII/MI nie jest naprostszym sposobem podlaczeniem wymaga sporo lini,

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


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

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


> Stosuje LwIP, ma multum opcji konfiguracyjnych, bardzo rozbudowane logi.
> Od razu sie nastaw ze zapoznanie sie z tym stosem to nie bedzie 5 minut.

Przymierzam się do zakupu tej książki:
http://www.kamami.pl/index.php?productID=178588
To chyba powinno być dobre wprowadzenie do tematyki.


> Na 128kB udalo mi sie postawic webserver, mailserver i pare dedykowanych
> "demonow". Ale powiedzmy sobie szczerze do sieci to jest min. 8MB i linux.

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.


> wget mi pokazuje 2.6 MB/s.

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

do góry

On Fri, 16 May 2014 12:06:31 +0200, Atlantis <m...@w...pl>
wrote:
>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.

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

do góry

On Fri, 16 May 2014 20:59:06 +0200, jacek pozniak
<j...@f...pl> wrote:
> 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.

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

do góry

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

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

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.

do góry

W dniu 2014-05-16 12:06, Atlantis pisze:
> 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ść?

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

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

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.

> 3) Jakich transferów mogę się spodziewać? Podejrzewam, że będzie lepiej
> niż na duecie Mega328 + ENC28J60. Jak bardzo lepiej? ;)

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.

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

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.

> 5) Jak taki MCU radzi sobie z szyfrowaniem AES? Powinienem się
> spodziewać zauważalnych przestojów?

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

do góry

On Sat, 17 May 2014 18:37:05 +0200, mk <reverse_lp.pw@myzskm> wrote:
> 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 --

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

--
Marek

do góry

W dniu 2014-05-17 18:58, Marek pisze:
> On Sat, 17 May 2014 18:37:05 +0200, mk <reverse_lp.pw@myzskm> wrote:
>> 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 --
>
> 72Mhz i zapchałeś 100Mbit ethernet? Ten stm był z wbudowanym eth. użyty
> był dma?
>

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

do góry

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

> 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

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

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

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

do góry