Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: MiMar 18. 10. 2023, 09:32:18
-
Ahoj,
takové zamyšlení:
Vím, že existuje možnost kódit firmware do některých MCU ve vyšších programovacích jazycích, ponejvíce a nejznáměji asi v subsetu Pythonu 3 alias Micropythonu, ale i jiných (Lua, JS...).
Jako člověk srostlý s embedded světem jsem to bral jako něco na hraní pro domácí kutily, či maximálně tak na prototypování, přece jenom jazyk s GC si s MISRA atd. do noty určitě nepadne :D.
Nedávno jsem se bavil s jedním juniorním vývojářem od bývalého zaměstnavatele, kdy při hovoru došlo i na téma výše. Bylo mi tvrzeno, že konkrétně Micropython si již našel cestu do produkce, dokonce prý do lékařských přístrojů, čemuž se mi zrovna dvakrát věřit nechtělo (po vygooglování měl pravdu).
Tak teď nevím, asi už patřím mezi dinosaury (C/C++), ale tahat interpretované jazyky do světa mikrokotrolérů mi jako košer nepřijde, ale na druhou stranu šikovnách lidí ubývá a někdo ta zařízení vyvíjet musí, že? Sice si řízení výkonových měničů (tak trochu má parketa) v Pythonu představit nedokáži, a ani nechci, ale u spotřební elektroniky by to asi šlo.
Jaký je váš názor na vyšší jazyky (a jejich runtime...) pro MCUs? Cestička pro DIY nadšence, či trend i pro profi zařízení, hm?
-
Mas pravdu, patris mezi dinosaury, protoze Python se dnes v ruznych formach pouziva prakticky vsude a ocividne s tim nikdo (krome tebe) nema problem.
-
Micropython nie je interpretovaný, kompiluje sa do bytecode.
-
Já jsem kutil, vidím dvě roviny tohoto problému a vykřikovat něco o dinosaurech mi přijde přehnané (¶řišel s tím, autor sám... vím o tom).
První rovina je proc python ano - v některých nasazeních umožňuje velice rychle vytvořit aplikaci/firmware pro daný HW. Umožňuje lépe se soustředit na funkcionalitu samotnou, nemusím řešit deklarace proměnných a tisíce dalších drobností... Třeba aplikace s GUI je micropythonu vytvořená strašně rychle a přímočaře.
Proti tomu C/C++ mi dává lepší kontrolu nad tím, co se děje. Takže pokud chci aplikaci, která nemá přímé UI, tak je výrazně lepší použít C/C++.
Před pár lety jsem si dělal domácí meteostanici. Pro čidla jsem použil micropython, čidlo fungovalo velmi rychle a super. Jen výdrž na baterie byla mizerná. Když mne to neustálé nabíjení přestalo bavit, tak jsem kód přepsal do C. Architekturu jsem víceméně zachoval, kód dělá 1:1 to samé. A najednou mám 6x větší výdrž na baterii.
Do C jsem přepsal pouze kód čidel, ostatní komponenty jsem nechal v micropythonu - kolektor dat z čidel a zobrazovací jednotku. Delší start mi zde nevadí, u kolektoru si cením toho, že je jednoduché ovlivnit chování interního webserveru (nemusím myslet na alokování každého byte paměti pro práci se stringy a podobně, nemusím hlídat návratové hodnoty všeho, prostě nakonec chytím všechny výjimky, které jsou neošetřené a takdále...), u zobrazovací jednotky bych asi hodně nadával při vytváření UI...
Takže, C i micropython můžou žít vedle sebe, oba mají své místo.
-
Před pár lety jsem si dělal domácí meteostanici. Pro čidla jsem použil micropython, čidlo fungovalo velmi rychle a super. Jen výdrž na baterie byla mizerná. Když mne to neustálé nabíjení přestalo bavit, tak jsem kód přepsal do C. Architekturu jsem víceméně zachoval, kód dělá 1:1 to samé. A najednou mám 6x větší výdrž na baterii.
6 krát viac pri načítaní čidiel, to sa mi nepozdáva. Je pre to nejaké vysvetlenie? Robili ste všetko optimálne?
-
na C a assembleru je "specialni" prace s pameti a jeji alokace. kdyz tohle se nemusi resit, tak pak nevidim v pythonu nebo cemkoliv jinem problem :-)
-
Před pár lety jsem si dělal domácí meteostanici. Pro čidla jsem použil micropython, čidlo fungovalo velmi rychle a super. Jen výdrž na baterie byla mizerná. Když mne to neustálé nabíjení přestalo bavit, tak jsem kód přepsal do C. Architekturu jsem víceméně zachoval, kód dělá 1:1 to samé. A najednou mám 6x větší výdrž na baterii.
6 krát viac pri načítaní čidiel, to sa mi nepozdáva. Je pre to nejaké vysvetlenie? Robili ste všetko optimálne?
Vysvětlení mám dvě - používám ESPNow a v době micropy verze kódu byla implementace ESPNow pro micropy velmi nestabilní a pravděpodobně neoptimalizovaná, takže wifi bylo delší dobu aktivní při odesílání (a spotřeba je v tom případě enormní). Ale hlavní důvod bude v tom, že micropy kód běžel velmi dlouho - čidlo je v deepsleep a buzené časovačem - u micropy se musí vzbudit, nabootovat micropy, ten musí spustit kód atakdále... U nativního kódu v C se mi průměrnou dobu vzbuzení povedlo zkrátit asi 5x, což odpovídá výdrži baterie.
Jinak, kód v principu funguje takhle:
- změř veličiny,
- porovnej veličiny s předchozím měřením a pokud je rozdíl příliš veliký
nebo
- - už určitou dobu nebyly odeslána žádná data
nebo
- - není dostupné předchozí měření, tak:
- - - inicializuj wifi,
- - - odešli nová data,
- - - vypni wifi,
- - - ulož nová data
- uspi zařízení.
Ale je fakt, že u micropy verze nebyla řešená efektivita kódu...
-
Ja sa skusim (ako java programator, ktory vie cez registre v RP2040 invertovat par vystupov naraz; v micropythone, ale aj v Cecku) vyjadrit iba k efektivite:
Imho nie je nic, kde by bol problem v efektivite C versus nejaky vyssieurovnovo postaveny jazyk. Zalezi od kniznic a podpory v tom vysukourovnovom jazyku, ci dovoli robit veci lahko a zaroven aj lowlevelovo (v gite z cli si viem zavolat nielen porcelain prikazy, ale aj plumber a furt som v komandlajne).
Rozdiel je v mentalnej zatazi. Ak mam v jave robit high performance veci, tak musim vediet nielen ako pracuje CPU a kompilator, ale aj ako funguje runtime. To pri jazykoch ako rust, C, C++ a podobne odpada.
Osobne by som sa teda v produkcii asi nebal vyssieurovnovych jazykov, ale skor toho, aki juniori to budu pisat. Subjektivny nazor nadseneho amatera z inej oblasti...
-
Mas pravdu, patris mezi dinosaury, protoze Python se dnes v ruznych formach pouziva prakticky vsude a ocividne s tim nikdo (krome tebe) nema problem.
Jj, jsem holt stará škola, což ale v tak rigidní oblasti, jakou představuje energetika, není asi zas tak na škodu. Python používám na zpracovávání naměřených dat, ale cpát ho, byť v jeho odlehčené verzi, do řízení něčeho "náročnějšího", než je nějaký IoT senzor, mi přivádí svědění hlavy :).
-
tahat interpretované jazyky do světa mikrokotrolérů mi jako košer nepřijde,
Světu mikrokontrolérů vůbec nerozumím, tak mi prosím promiňte snad hloupé otázky:
1. Proč Vám nepřijde košér používat interpretované jazyky pro miukrokontrolery?
2. Souvisí to s tím, že (třeba zrovna ten Python) je vysokoúrovňový jazyk? (Kdežto C/C++ spíš nízko úrovňový?)
3. Technicky vzato, není v mnoha situacích samotné použití mikrokontroleru samo o sobě trochu kanón na vrabce?
-
Před pár lety jsem si dělal domácí meteostanici. Pro čidla jsem použil micropython, čidlo fungovalo velmi rychle a super. Jen výdrž na baterie byla mizerná. Když mne to neustálé nabíjení přestalo bavit, tak jsem kód přepsal do C. Architekturu jsem víceméně zachoval, kód dělá 1:1 to samé. A najednou mám 6x větší výdrž na baterii.
6 krát viac pri načítaní čidiel, to sa mi nepozdáva. Je pre to nejaké vysvetlenie? Robili ste všetko optimálne?
Vysvětlení mám dvě - používám ESPNow a v době micropy verze kódu byla implementace ESPNow pro micropy velmi nestabilní a pravděpodobně neoptimalizovaná, takže wifi bylo delší dobu aktivní při odesílání (a spotřeba je v tom případě enormní). Ale hlavní důvod bude v tom, že micropy kód běžel velmi dlouho - čidlo je v deepsleep a buzené časovačem - u micropy se musí vzbudit, nabootovat micropy, ten musí spustit kód atakdále... U nativního kódu v C se mi průměrnou dobu vzbuzení povedlo zkrátit asi 5x, což odpovídá výdrži baterie.
Jinak, kód v principu funguje takhle:
- změř veličiny,
- porovnej veličiny s předchozím měřením a pokud je rozdíl příliš veliký
nebo
- - už určitou dobu nebyly odeslána žádná data
nebo
- - není dostupné předchozí měření, tak:
- - - inicializuj wifi,
- - - odešli nová data,
- - - vypni wifi,
- - - ulož nová data
- uspi zařízení.
Ale je fakt, že u micropy verze nebyla řešená efektivita kódu...
Ďakujem za vysvetlenie.
-
tahat interpretované jazyky do světa mikrokotrolérů mi jako košer nepřijde,
Světu mikrokontrolérů vůbec nerozumím, tak mi prosím promiňte snad hloupé otázky:
1. Proč Vám nepřijde košér používat interpretované jazyky pro miukrokontrolery?
2. Souvisí to s tím, že (třeba zrovna ten Python) je vysokoúrovňový jazyk? (Kdežto C/C++ spíš nízko úrovňový?)
3. Technicky vzato, není v mnoha situacích samotné použití mikrokontroleru samo o sobě trochu kanón na vrabce?
Nejsem MiMar, ale za mě, spousta věcí, co by se daly udělat celkem malým analogovým obvodem se řeší něčím programovatelným, a když už se to teda řeší něčím programovatelným, tak místo pár příkazů v asembleru (nebo v jazyce, z jakého se z toho pár příkazů v ASM stane) se tam nacpe celé interpretované prostředí a místo pár set bajtů tam jsou najednou megabajty kódu.
Na druhou stranu, ten analogový obvod, co si spájím z diskrétních součástek, bude dost možná žrát víc, než mikrokontroler i s uPythonem, potrvá mi to mnohem déle, vyžaduje to, abych znal věci, co pro mě jinak nejsou vůbec podstatné a trvají déle se naučit. A nakonec se dostanu k tomu, že to má nějak začít komunikovat a v tu chvíli už sebelepší domácí pájení nepomůže. A stejně tak v případě člověka, co umí trochu Python nebo podobný jazyk a C viděl jen z rychlíku, a tohle má jako domácí projektík, nedává smysl učit se to C, když tam může nasadit uPython. Na Cčko se takový domácí projektík dá přepsat vždycky (když to bude potřeba).
-
Otázka zní o jakém embedded zařízení se bavíme. Když se podíváš co je pohání, je jasné, že se tam dnes Python prostě nedá nevyužít. Dříve možná ne, dnes je laťka výkonu několik řádů výše. Stejně tak velký potenciál má Lua i JS. Je úplně jedno co si kdo myslí, hlavní je, jestli to funguje. A to je případ od případu. Čemu jako vývojář "věříš" a co jsou fakta se s časem rozevírá jak nůžky. Říká se tomu slušně stárnutí :D
-
na druhou stranu šikovnách lidí ubývá a někdo ta zařízení vyvíjet musí
Šikovných lidí je pořád stejné procento jako dřív, jen píší Micropython a mnoho dalších věcí a dinosauři jen koukají, jak jim ujíždí vlak.
Teď vážně. Nikdy jsem neměl v IoT nějakou bohatou logiku. Vždycky to bylo něco změřit a poslat to dál, případně něco změřit, poslat to dál a uspat se. To je pak jedno jestli to je napsané v assembleru, Pythonu nebo JavaScriptu. Existují věci, na které se musí jít níž, třeba levné počítání pulzů ULP koprocesorem na ESP32, ale kolik projektů to potřebuje a navíc to je takovej ojeb, že si myslím, že i kdyby to mělo využití, tak si vývojáři radši probudí ta velká jádra a nějaké optimalizaci s ULP se budou věnovat až z toho bude problém.
-
Tady https://cz.pycon.org/2023/program/talks/85/ vyprávěl jeden z autorů firmwaru pro Trezor, že sice MicroPython se dal využít, nějakou dobu to na tom jelo, ale nakonec postupně přešli do Rustu. Na závěr dal doporučení, že MicroPython je sice fajn, ale je vhodný spíš na domácí bastlení.
-
Tady https://cz.pycon.org/2023/program/talks/85/ vyprávěl jeden z autorů firmwaru ...
Zajímavé, není prosím někde záznam té přednášky? Na jejich webu ani na youtube jsem to nějak nenašel... Díky.
-
Záznam by měl někdy být, ale popravdě nevím kdy. Každopádně tady jsou slidy od autora http://jdem.cz/fjymd9.
-
Díky moc, slidy super.
-
Na závěr dal doporučení, že MicroPython je sice fajn, ale je vhodný spíš na domácí bastlení.
Ja som zial videl iba slajdy, ale tam takyto zaver nebol. Osobne som to vnimal, ze ak clovek pouziva iba micropython, tak je to "bezpecne". Ak to mixuje (a hlavne volanie python-u z inych miest, ci pouzivanie mutable/imutable veci v roznych jazykoch), tak to nebezpecne je. Rovnako, ich hlavna motivacia bola, ze mali malo ramky. A micropython je "nenazrany" by-design. Toto bola imho hlavna motivcia. O samotnej nebezpecnosti python-u som tam nezachytil nic.
Bolo tam nieco konkretnejsie povedane, co nieje v slidoch?
PS: Nechcem obhajovat svoj nazor, ze by som sa micropythonu v produkcii nebal, len by som chcel dalsie podklady smerom, ze to nie je dobry napad. Ono predsa ten prvy trezor produkt inzeruju ako bezpecny a pouziva to micropython...
-
Popravdě si přednášku do všech detailů nepamatuju, protože v tomhle oboru moc nedělám. Nicméně, samozřejmě ve slidech není všechno. Ten závěr té přednášky se nesl v tom smyslu, že MicroPython dostačoval, ale že postupem vývoje přestal stačit - třeba právě z důvodu paměti. No a potom rostl náklad na přechod do Rustu, takže kdyby to dělali od začátku v Rustu, tak by se to nestalo. Víceméně se předpokládá, že v embedded aplikaci se dojde do takového stádia, kdy nenažranost MicroPythonu začne dělat problémy a tak se musí přejít jinam. S Rustem by to mělo jít dělat optimalizovaně už od začátku a MicroPython nechat na bastl.
-
S Rustem by to mělo jít dělat optimalizovaně už od začátku a MicroPython nechat na bastl.
Tak desítky článků jak jsme přešli z X na Y mám už za sebou. Zdá se mi, že většinou se zapomíná na to, že bez toho Pythonu by ani přechod nebyl možný. Dát dohromady rozumně napsané MVP v Pythonu a případně pak přecházet na něco jiného, kde to má smysl, je lehčí než sehnat někoho na Go "nedejbože" Rust. Ale třeba pro secure/safe projekt jako Trezor to asi mělo smysl od začátku. Dík za slajdy.
-
Ahoj,
takové zamyšlení:
Vím, že existuje možnost kódit firmware do některých MCU ve vyšších programovacích jazycích, ponejvíce a nejznáměji asi v subsetu Pythonu 3 alias Micropythonu, ale i jiných (Lua, JS...).
Jako člověk srostlý s embedded světem jsem to bral jako něco na hraní pro domácí kutily, či maximálně tak na prototypování, přece jenom jazyk s GC si s MISRA atd. do noty určitě nepadne :D.
Nedávno jsem se bavil s jedním juniorním vývojářem od bývalého zaměstnavatele, kdy při hovoru došlo i na téma výše. Bylo mi tvrzeno, že konkrétně Micropython si již našel cestu do produkce, dokonce prý do lékařských přístrojů, čemuž se mi zrovna dvakrát věřit nechtělo (po vygooglování měl pravdu).
Tak teď nevím, asi už patřím mezi dinosaury (C/C++), ale tahat interpretované jazyky do světa mikrokotrolérů mi jako košer nepřijde, ale na druhou stranu šikovnách lidí ubývá a někdo ta zařízení vyvíjet musí, že? Sice si řízení výkonových měničů (tak trochu má parketa) v Pythonu představit nedokáži, a ani nechci, ale u spotřební elektroniky by to asi šlo.
Jaký je váš názor na vyšší jazyky (a jejich runtime...) pro MCUs? Cestička pro DIY nadšence, či trend i pro profi zařízení, hm?
Ak ide o IoT zariadenie typu RPi, co ma vykon ako desktop tak je to asi OK.
Pre normalne mikroprocesory python je len taka hracka prave kvoli determinizmu a sprave pamete, hlavne ked dany vyvojar o tychto veciach nic netusi, lebo Cecko neriesili.
-
Tak jsem si udělal krapánek času, vzal destičku s Rpi Pico a Micropython vyzkoušel - ano, na rychlé prototypování naprosto super, během hodinky jsem už fetchoval data z OpenWeathermaps a zobrazoval je na malém OLED displeji. Pokud bych na to šel přes C/C++, LWIP atd, tak s tím laboruji daleko déle, a hlavně s, pro uživatele, stejným výsledkem.
Performance, "svébytnost" GC atd. u takových aplikací nikdo nikdy řešit extra nebude, tak proč nekódit jejich FW v MPY, že?
Na druhou stranu si stojím za tím, že v náročnějších aplikacích s požadavky na real-time, bezpečnost, determiničnost má MPY dveře zavřené a natřikrát uzamčené :)
-
Ono hlavne pri pouziti normalneho jazyka (C/C++,...) je mozne zariadenie vybavit podsttane lacnejsim cipom (alebo spolahlivejsim), co pri miolonoch vyrobenych kusov prinasa nemale znieznie nakladov na vyrobu.
-
Šikovných lidí je pořád stejné procento jako dřív, jen píší Micropython a mnoho dalších věcí a dinosauři jen koukají, jak jim ujíždí vlak.
Jsem asi dinosaurus ale zkusil jsem to. Občané z okolí Buštěhradu na mají pěkné slovo „pumprdentlich“. Celé to dělá dojem takového toho moderního nesmyslu, který někdo ze srandy vytvořil a teď lidi pracně hledají, kde by se to mohlo využít. Tenhle vlak si asi nechám ujet.