Mikrokontroléry (MCU) - jak začít a s čím - rady, vaše zkušenosti, názory a tipy

[anonym]

Ja dělal s Arduinem takové malé věci. Vcelku mě tohle odvětví fascinuje, totiž, na co to jako je? Ten HW už je tak levný, že nechápu, proč na nějaký monolit raději nenasadit nějaký rtos a neprogramovat normálně v C++? Proč se štvát s assemblerem, řešit přerušení, dma atd., nedostatek knihoven, neustálé vynalézání kola psaním něčeho, co už existuje 100x.

[Reklama]

[anonym]

chápu, že třeba mirkovlnka nebo řj v autě to potřebuje, nebude se tam přece pokaždé starovat os, ale jak často se dostanete k takové práci v ČR? Mikrovlnku stejně naprogramuje Číňan a v automotive stejně nepíšou kód ručně, ale generují ho ze schémat, co jsem tak slyšel.

[eltech]

Pridal bych se k doporuceni STM32.

STM má fajn čipy, ale ta driver knihovna je děsná. Mnohem víc se mi líbí co poskytují výrobci k Energy Micro EFM32 (mají to dokonce na GitHubu) nebo třeba TI Tiva C.

Souhlasim. I kdyz EFM32 kity jsou o trosku drazsi, tak enablement a dokumentaci maji oproti ST nebo NXP(Kinetis) lepsi. Jen nevim, jak jsou na tom s nejakou komunitou, navody atd. S knihovnami pro TI Tiva C bohuzel nemam zkusenosti.

[mln]

Ten HW už je tak levný, že nechápu, proč na nějaký monolit raději nenasadit nějaký rtos a neprogramovat normálně v C++? Proč se štvát s assemblerem, řešit přerušení, dma atd., nedostatek knihoven, neustálé vynalézání kola psaním něčeho, co už existuje 100x.

Čo má spoločné RTOS s problémami s prerušením, DMA a knižnicami ? RTOS je na MCU vačšinou len plánovač úloh, semafory, mailboxy, sw časovcče atd. Bez kvalitnych knizníc (bud vlastnych alebo cudzich) na ovladanie HW sa aj tak dalej nepohneš, a je jedno či tam bude alebo nebude RTOS.   
Ono existuje nejaký MCU kde nie je problém s knižnicami ?
Použitie prerušení a DMA je elegantny sposob ako sa vyhnut pouzitiu RTOS (ktorý vie vytvorit dalsie problémy navyše).

Dnes je velka moda stavat rozne lacne low power pseudo IOT senzory ktore by mali vydržať 5-10 rokov na jednu bateriu. Aj v ramci lacneho hw možno najsť ešte lacnejši mcu. Pri 1000ks serii aj procak lacnejsi o 0,1€ už spravi 100€ rozdiel. Tam je potrebne vyuzit ten hw na maximum.

Analogoiu može byt operak LM358 - je stary ale pomaly najlacnejsi. Je vela modernejších, low power, rail to rail operakov parametrovo podobnych, ale cenovo drahsích ako LM358, tak pokial to fakt nie je nutne, tak sa stale pouzivaju "klasiky" za minimalnu cenu.

[Pontiaq]

Dokonce jsem našel nějaké tutorialy právě na KL25Z: https://www.youtube.com/watch?v=BAzKg3vcB88&list=PLWy-YwxbAu8FDpD2saP1p6IFHgvbzODyc. Což rozhodně usnadní studium.

[Reklama]

[maco]

Tiez sa priklanam ist cestou ARM ak sa tomu chces vazne venovat. Zacinat s aurduino platformou je super pre tych ktory, vedia aspon ako tak programovat, do elektroniky sa nevyznaju, s pajkovacou si nerozumeju a nemaju ani ambiciu ist tymto smerom. Ja ho pouzivam na male hobby projekty pre znamich, "hranie sa", velmi urychluje vyvoj vdaka knizniciam skoro na vsetko. No pocul som aj o firmach ktore v nom robia komercne veci. Viem si to predstavit iba v malej casti projektov.
Pred 10r som zacinal s ASM na AVR, potom C. Na arduine ma velmi irituje nemoznost vidiet obsah registrov, priamo v procesore krokovat program... mozem sa len domnievat ze procesor... robi to co po nom chcem. HW debug je super pomocka aj pri uceni sa, da sa rychlo overit co kod robi s procesorom.
Ako tu uz niekto spominal s AVR studiom (verzia 7) mam aj ja zlu skusenost, "pokazil" sa mi pri nej AVR Dragon (50eur) pri ladeni cez DebugWire, stale to mrzlo, vypadavalo, az po zopar "tvrdych" restartoch ho uz AVR studio nevie najst. Super to fungovalo este na asi 10 rocnej verzii 4, no editor nic moc.

Nastavit periferie pri ARM STM32 v porovnani s AVR je ovela zlozitejsie, treba si zvyknut na iny pristup, avsak ani tie niesu dokonale, na diskusiach sa riesi vela bugov, hlavne STM kniznice... Ale aj napriek tomu by som "vaznejsi projet" robil na nich.
Pre blikanie LEDkou a pochopenie ako to funguje odporucam Cortex M0, ma ovela jednoduchsie periferie ako M3, je najviac "AVR friendly" npr https://www.ebay.com/itm/1PCS-STM32F030F4P6-ARM-CORTEX-M0-Core-Minimum-System-Dev-Board-for-Arduino/182216811895?epid=556113683&hash=item2a6cf7e577:g:aDAAAOSwSv1Xkte~

Ako programator debbuger pouzit toto: https://www.ebay.com/itm/ST-Link-V2-Programming-Unit-mini-STM8-STM32-Emulator-Downloader-M89/262670560884?hash=item3d2862ae74:g:a7YAAOSwmLlX~hMO

Procesory STM32 su uz lacnejsie ako AVR a nahrava im aj nedavne uvolnenie vyvojoveho prostredia Attolic TrueSTUDIO v PRO verzii bez obmedzeni. http://blog.atollic.com/truestudio-for-stm32-9-released
Co ponukaju iny vyrobcovia ARM procesorov, netusim...

[anonym]

Ten HW už je tak levný, že nechápu, proč na nějaký monolit raději nenasadit nějaký rtos a neprogramovat normálně v C++? Proč se štvát s assemblerem, řešit přerušení, dma atd., nedostatek knihoven, neustálé vynalézání kola psaním něčeho, co už existuje 100x.

Čo má spoločné RTOS s problémami s prerušením, DMA a knižnicami ? RTOS je na MCU vačšinou len plánovač úloh, semafory, mailboxy, sw časovcče atd. Bez kvalitnych knizníc (bud vlastnych alebo cudzich) na ovladanie HW sa aj tak dalej nepohneš, a je jedno či tam bude alebo nebude RTOS.   
Ono existuje nejaký MCU kde nie je problém s knižnicami ?
Použitie prerušení a DMA je elegantny sposob ako sa vyhnut pouzitiu RTOS (ktorý vie vytvorit dalsie problémy navyše).

Dnes je velka moda stavat rozne lacne low power pseudo IOT senzory ktore by mali vydržať 5-10 rokov na jednu bateriu. Aj v ramci lacneho hw možno najsť ešte lacnejši mcu. Pri 1000ks serii aj procak lacnejsi o 0,1€ už spravi 100€ rozdiel. Tam je potrebne vyuzit ten hw na maximum.

Analogoiu može byt operak LM358 - je stary ale pomaly najlacnejsi. Je vela modernejších, low power, rail to rail operakov parametrovo podobnych, ale cenovo drahsích ako LM358, tak pokial to fakt nie je nutne, tak sa stale pouzivaju "klasiky" za minimalnu cenu.

No tak vzdyt o ty knihovny jde. Resi se tady, jaky procesor low level programovat. Vzdyt nejvetsi mnozstvi knihoven bude stejne napsanych v C, Ty si treba budes hrat s njakym ARM procesorem, ale co udelas, az budes potrebovat zpracovavat treba obraz z kamery, nebo posilat nejake data po LAN nebo pres WiFi? Na Arduinu to udelas, protoze je tam velka komunita a knihovny jsou, ale co treba ty dalsi monolity, ktere tu uvadite? Co kdyz budes potrebovat zalozit na tom monolitu i nějaký malý server, který bude moct reagovat na okolí. Fakt by me zajimalo, co se tady u nas v CR v prumyslu realne na tech mikroporcesorech dela, kdes najdes uplatneni, kdyz umims programovat ARM.

[Ramirez]

No tak vzdyt o ty knihovny jde. Resi se tady, jaky procesor low level programovat. Vzdyt nejvetsi mnozstvi knihoven bude stejne napsanych v C, Ty si treba budes hrat s njakym ARM procesorem, ale co udelas, az budes potrebovat zpracovavat treba obraz z kamery, nebo posilat nejake data po LAN nebo pres WiFi? Na Arduinu to udelas, protoze je tam velka komunita a knihovny jsou, ale co treba ty dalsi monolity, ktere tu uvadite? Co kdyz budes potrebovat zalozit na tom monolitu i nějaký malý server, který bude moct reagovat na okolí. Fakt by me zajimalo, co se tady u nas v CR v prumyslu realne na tech mikroporcesorech dela, kdes najdes uplatneni, kdyz umims programovat ARM.
[/quote
Presne tohle je prede mnou. Zpravovat obraz z kamery, zvuk z mikrofonu, zkomprimovat je, poslat streamem pryc a na druhe strane ho dekomprimovat, zobrazit na LCD a poslat do repraku.

A jak to udelam? Vezmu si datasheety k procesorum, ke kamere, k LCD a dalsim periferiim, ktere k tomu budu potrebovat, nastuduju si je a napisu si to kompletne sam. A proc? Protoze ty knihovny, co jsou ke kamere, LCD atd. dostupne pro arduino jsou sice fajn, ale nikdy nemas jistotu, ze budou delat to, co potrebujes, ve vsech situacich. A to si proste v produkcni verzi nemuzes dovolit.

[Ramirez]

No tak vzdyt o ty knihovny jde. Resi se tady, jaky procesor low level programovat. Vzdyt nejvetsi mnozstvi knihoven bude stejne napsanych v C, Ty si treba budes hrat s njakym ARM procesorem, ale co udelas, az budes potrebovat zpracovavat treba obraz z kamery, nebo posilat nejake data po LAN nebo pres WiFi? Na Arduinu to udelas, protoze je tam velka komunita a knihovny jsou, ale co treba ty dalsi monolity, ktere tu uvadite? Co kdyz budes potrebovat zalozit na tom monolitu i nějaký malý server, který bude moct reagovat na okolí. Fakt by me zajimalo, co se tady u nas v CR v prumyslu realne na tech mikroporcesorech dela, kdes najdes uplatneni, kdyz umims programovat ARM.

Presne tohle je prede mnou. Zpravovat obraz z kamery, zvuk z mikrofonu, zkomprimovat je, poslat streamem pryc a na druhe strane ho dekomprimovat, zobrazit na LCD a poslat do repraku.

A jak to udelam? Vezmu si datasheety k procesorum, ke kamere, k LCD a dalsim periferiim, ktere k tomu budu potrebovat, nastuduju si je a napisu si to kompletne sam. A proc? Protoze ty knihovny, co jsou ke kamere, LCD atd. dostupne pro arduino jsou sice fajn, ale nikdy nemas jistotu, ze budou delat to, co potrebujes, ve vsech situacich. A to si proste v produkcni verzi nemuzes dovolit.

[mhi_]

Prijde mi, ze spousta diskuteru typu "vybodni se na XXX a delej YYY" zije v zaujeti sve technicke bubliny. Jinymi slovy, nikdy jsem nedelal aplikaci vylozene vhodnou pro YYY, zato jsem delal jen pro XXX, tak vidim jen XXX. A ono je treba jeste ZZZ.

Existuje spousta typu problemu a jejich reseni.

- Ultra low cost a casto i low power MCU: ruzne blbosti typu dalkove ovladace, ovladani mikrovlnky, atd. Do tohoto segmentu se casto profiluji ruzna FPGA typu Lattice iCE40 a neni k nim potreba MCU. Priklad: vetsinou jen development kity.

- Slozitejsi MCU/SoC typu vetsi AVRka/PICy nebo male ARMy/MIPSy/TriCore/PPC/apod: na slozitejsi a vypocetne narocnejsi aplikace, kde je stale ale nutny primy pristup na hardware v realtimove urovni (rizeni motoru, ruzne senzory).  Priklad: Arduino

- "Velke procesory" s MMU a milionem periferii, na kterych bezi nejaky plnohodnotny OS, ktery zase prinasi vyhodu snadne konektivity, hromady hotovych veci, jednoduche debugovani, apod. Priklad: RPi,vsechny ty xxxPi.

Pokud bych teprve sel do oboru (od "nuly"), zabyval bych se uplne vsim a zacal bych zrejme prostredni kategorii. Ta ma dostatecne nizkourovnovy pristup, ale clovek neni pohlcen slozitosti tech velkych systemu. Na druhou stranu neni omezeni tech uplne malych, kde clovek zapasi s kde cim (malo pameti, malo periferii, dlouhy takt,atd.)

[atarist]

je to jak pise mhi_, jen trosku doplnim, ze v mezere mezi AVR/PICy na jedne strane a 32bitovymi masinami  ARM/MIPS/TriCore na strane druhe je cely ekosystem 16bitovych MCU, napriklad velmi elegantni MSP 430. Je to tusim prvni MCU teto kategorie, na ktery portovali Rust, takze to otvira dalsi zajimave moznosti do budoucna.

I ten assembler na MSP 430 se da naucit, oproti 8051 je to sranda.

[eltech]

Zde bych si dovolil nesouhlasit. Autor tohoto vlákna se ptal, jak a s čím začít v oblasti MCU. Nevidím tedy důvod mu motat hlavu výčtem možných řešení (včetně těch bez MCU) a různými existujícími architekturami specifickými pro jednoho výrobce nebo takovými, se kterými se pravděpodobně už v praxi ani nesetká.. a pokud setká, tak mi nepříjde vhodné s nimi začínat..

Mainstream je dnes z pohledu jader (v general purpose oblasti) !podle mě! ARM Cortex-M nebo Cortex-A (pro ty větší SoCs). Navíc existuje spousta "oficiálních" vývojových kitů za pár stovek i s debugerem na desce, takže stačí jen zapojit do USB a už lze zkoušet blikat ledkou.

FRDM-KL25z určitě není špatná volba.

Ještě bych doporučil tuhle sérii: https://youtu.be/3V9eqvkMzHA. I když je pro jinou desku a čip, většina věcí se dá zobecnit.

[mhi_]

Zopakoval bych svuj post o 3 vyse, vidite dle meho nazoru jen to svoje pole pusobnosti. Udelejte s Cortex-M neco na baterku ... neni to moc prakticke. Stejne tak vzit ARMa a chtit po nem nejake presne casove synchronizovane ovladani (takovy bit-bang, napr. proti nejakemu FPGA/CPLD). Vetsina ARMu co znam maji GPIO hodinove oddelene od jadra, navic nemate definovanou latenci. Treba s dsPIC24 nebrani nic clockovat data ven na 40MHz x 16bit. Nebo pouziti v zarusenem prostredi (potrebujete "humpolacky" MCU). Prikladu by slo napsat desitky. Podle me je tech oblasti kde se vyplati jine veci nez ARM hromada.

Je samozrejme mozne, ze za par let bude cena a proudovy odber ARM MCU bezicich na stovkach MHz tak nizka/nizky, ze zaniknou vsechny ty AVR/PIC18/dsPIC/MSP430 apod., ale zatim to tak neni. A ja osobne o tom dost pochybuju.

[Ondrej Nemecek]

Zde bych si dovolil nesouhlasit. Autor tohoto vlákna se ptal, jak a s čím začít v oblasti MCU. Nevidím tedy důvod mu motat hlavu výčtem možných řešení (včetně těch bez MCU) a různými existujícími architekturami specifickými pro jednoho výrobce nebo takovými, se kterými se pravděpodobně už v praxi ani nesetká.. a pokud setká, tak mi nepříjde vhodné s nimi začínat..

Bez orientace v oboru bude tazatel v praxi stejně nepoužitelný, takže to lze chápat i tak, že chce získat celkový přehled a sám se rozhodnout, na co se zaměřit. Podle mě je ten trh dost jasně segmentovaný podle požadavků na složitost, výkon a spotřebu zařízení. Do IOT nicméně odhaduju spadají asi všechny stupně (jednoduchá čidla na periférii vs. složitější řídící jednotka v centru), takže bych tipoval, že bude toho muset umět vícero.

[eltech]

Zopakoval bych svuj post o 3 vyse, vidite dle meho nazoru jen to svoje pole pusobnosti. Udelejte s Cortex-M neco na baterku ... neni to moc prakticke. Stejne tak vzit ARMa a chtit po nem nejake presne casove synchronizovane ovladani (takovy bit-bang, napr. proti nejakemu FPGA/CPLD). Vetsina ARMu co znam maji GPIO hodinove oddelene od jadra, navic nemate definovanou latenci. Treba s dsPIC24 nebrani nic clockovat data ven na 40MHz x 16bit. Nebo pouziti v zarusenem prostredi (potrebujete "humpolacky" MCU). Prikladu by slo napsat desitky. Podle me je tech oblasti kde se vyplati jine veci nez ARM hromada.

Je samozrejme mozne, ze za par let bude cena a proudovy odber ARM MCU bezicich na stovkach MHz tak nizka/nizky, ze zaniknou vsechny ty AVR/PIC18/dsPIC/MSP430 apod., ale zatim to tak neni. A ja osobne o tom dost pochybuju.

Já jsem spíše nechtěl rozebírat tohle téma v tomto vláknu, protože to tazateli podle mě nijak nepomůže.

Jen rychle zareaguji. Výrobky na baterku s Cortex-M je spousta a je to dnes už běžná praxe. Například výše zmíněné chipy od SiliconLabs (ale nejen ty) jsou velmi úsporné, Cortex-M0+ tuplem. Zmiňujete stovky MHz, ale přeci frekvenci jádra můžete snadno snížit a dostanete se na úroveň desítek MHz s velmi nízkou spotřebou. Navíc pokud to bude možné, tak v reálné aplikaci bude jádro většinu času uspané. Zbytek, a to včetně přesné časové synchronizace a dalšího odběru, už zavisí na konkrétním MCU a jeho periferiích, jako je RTC, DMA atd.
Zmiňujete cenu, ale ta je díky cenové politice některých firem velmi nízká, mnohdy nižší než vámi zmiňované ostatní architektury.

Samozřejmě situací/aplikací/oblastí existuje spousta a souhlasím s vámi, že někde lépe pasuje ultra low-power MSP430 a někde zase DSP dsPIC. Proto jsem zmiňoval tu "general-purpose" oblast, kde si myslím, že portfolio ARM jader (od low cost M0+ po M7 s SIMD instrukcemi, případně i řada Cortex-R) jich pokreje většinu (proto ideální pro začátek).. ale souhlasím, že určitě ne všechny.
To jestli je ARM vytlačí ostatní architektury je otázka (já doufám že ne)..  Jen pro zajímavost : http://www.embedded-computing.com/embedded-computing-design/the-msp430-mcu-just-gained-an-arm-based-cousin-the-m4-based-msp432.

Ondrej Nemecek, ale pokud bude mít zkušenosti s programováním MCU (nejen z univerzity), bude něco vědět o architektuře atd., tak si myslím, že jako fresh-out pohovorem většinou projde:)

Omlouvám se autorovi za off-topic.