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?

do góry

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

do góry

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


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

do góry

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

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


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

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.

do góry

Atlantis wrote:

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

> 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.
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.
>
> 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.
Tu się nie wypowiem bo nie wiem
>
>
>> 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.
>
> 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.
No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
dopisujesz własny driver do swojego hardware.

jp

do góry

Atlantis <m...@w...pl> wrote:

> Poza tym zobacz z jaką prędkością można "machać" stanem pinu na RasPi,

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/

do góry

Użytkownik "jacek pozniak" <j...@f...pl> napisał w
wiadomości news:5375fb3f$0$2247$65785112@news.neostrada.pl...
>
> 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 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.

do góry

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.


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

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.


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

do góry

Piotr Gałka wrote:


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

do góry

On 05/16/2014 01:49 PM, jacek pozniak wrote:
> Nie warto, lepiej sobie kup RPi; bedziesz miał Ethernet.

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

do góry