Micropython do produkčního zařízení

[MiMar]

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  .

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?

[Reklama]

[modnar]

Mas pravdu, patris mezi dinosaury, protoze Python se dnes v ruznych formach pouziva prakticky vsude a ocividne s tim nikdo (krome tebe) nema problem.

[balkovic]

Micropython nie je interpretovaný, kompiluje sa do bytecode.

[mhepp]

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.

[balkovic]

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?

[Reklama]

[alex6bbc]

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

[mhepp]

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:

Kód: [Vybrat]

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

[luvar]

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

[MiMar]

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  .

[B.H.L.]

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?

[balkovic]

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:

Kód: [Vybrat]

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

[Zopper]

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

[Wavelet]

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í

[by_cx]

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.

[murf]

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