NuttX international wokshop (diskuse)

[Pavel Píša]

Jinak ke stavu a odkupu značky firmou Qualcomm zde často preferované alternativy ve formě Arduino jsem se vyjádřil v odpovědi v diskuzi na serveru Root.cz Qualcomm kupuje italskou firmu Arduino, vydávají společně desku UNO Q - diskuze

[trekker.dk]

Je spíše neuvěřitelné, kolik různých architektur a platforem se mu podařilo jednotně podporovat po mnoho let, viz přehled podporovaných architektur, rodin mikrokontrolérů a desek v dokumentaci

Ten přehled podporovaných architektur je podle mě trochu zavádějící... zkusil jsem to rozchodit (nic jednoduchého, dokumentace je poměrně roztříštěná) a nějak se mi nakonec povedlo vyrobit funkční program, co šel nahrát do AVR čipu, který jsem měl po ruce. Fungovalo to, to ano, ale pro nějaké reálné nasazení tomu chybí podpora prakticky veškerého hardware, který ten čip má. Nemluvě o tom, že samotný kernel zabírá nějakých 40kB - třetinu - flash. Tipnul bych si, že s ostatními podporovanými architekturami by to mohlo být podobné - teoreticky podporováno, prakticky ARM. (A možná Risc-V.)

[Pavel Píša]

Děkuji za otestování a potvrzení i na oblíbené platformě, kterou sám opravdu zkoušet nebudu. Považuji jí za kouli na noze jak kompilátoru C (GCC chce pro eliminaci se narovnáváků na ohýbáky AVR podpory zbavit) tak každého systému.

Míra podpory HW se podle platforem liší.

Když se podíváte třeba na Espressif ESP32-C6, kde se zapojují i lidi od výrobce, tak tam je podpora periferií celkem široká.

Na imxRT a SAMv7, které nás zajímají, tak se muselo mnoho věcí dopsat, ale nyní je to pro všechny.

Přitom veliká výhoda na rozdíl od FreeRTOSu a jiných řešení je, že všechny architektury mohou své low-level drivery jednotlivých periferií implementovat a využít high level sjednocujících API pro CANbud, ADC, DAC, PWM, timery atd. Ano, to sjednocení často vede k tomu, že je podporovaný jen common subset schopností periferií. Ale kde je to potřeba, tak lze navrhnout i IOCTL jen pro konkrétní typ a nebo i přitupovat k HW přímo, pokud je NuttX kompilovaný v režimu bez MMU a ochrany paměti.

Ano, POSIX API mají overhead. Ano, při psaní přímo na dané HW a s RT částí přímo v přerušeních lze z daného HW získat mnohem více. Ale vše ze přepisuje znova a znova, takto máme v pysimCoder napsaný bloky pro ADC, PWM, DAC, posílání přes CAN, TCP, UDP jednou a chodí na širokém rozsahu platforem. Tam kde potřebujeme přesné synchronizace ADC s PWM, tak jsme přidali možnosti do konfigurace NuttXu, které to pro dané periferie nastaví. Takže opět, pysimCoder beze změny. Ty jeho komunikační bloky jsou často beze změny i pro GNU/Linux.

Při sklouznutí do ekosystému výrobců, typu CUBE, EmbeddedBeans, CodeComposerStudion jste navedení na psaní kódu tak, že je nepřenositelný na jiné výrobce a ani na GNU/Linux si ten HW nezávislý základ neotestujete.

Jinak podpora se různí, pokud nemáte od někoho znalého prvotní nastaven pro danou platformu a sadu periferií, tak to může být na začátek frustrující. Něco nenastavíte v high level driverech a low level se vám vůbec v seznamu neobjeví nebo nastavíte i kombinaci která nakonec nelze zkompilovat nebo neběží.

Sám mám pak zkušenost i s RTEMSem (https://www.rtems.org/) ten má mnohem lepší scheduler, RT vlastnosti a tak od 8 MB RAM nabízí i integraci BSD TCP/IP stacku. Ale tam se opravdu počítá s tím, že na ty projekty za milióny EUR se podpora periferií napíše na míru/komunita je tak malá a nesoustředí se na to, že existují jen drivery sériových portů a pak třeba v rámci GSoC nějaké další pro platformy na hraní, BeagleBone, Raspberry Pi. Ale model driverů je na rozdíl od FreeRTOS a jiných k dispozici, takže když jme nad RTEMSem navrhovali Technic-Iinfůzní pumpu (safety-critical), tak jsem psal drivery pro klávesnici, LCD, SD kartu, IrDA a vše ostatní od nuly. Ale FAT a bloková vrstva, micro-input driver i s podporou na druhé straně v https://www.microwindows.org/ atd byly. Ale RTEMS je o řád na vstup z pohledu podpory platforem těžší. Takže sám vidím NuttX jako pohodu. Ale chápu, že to může být z pohledu jiného různé a i hrůzné.

[trekker.dk]

GCC chce pro eliminaci se narovnáváků na ohýbáky AVR podpory zbavit

... což se projevuje tak, že je podpora AVR aktivně vyvíjena v upstreamu?

Míra podpory HW se podle platforem liší. ...

Což nás vrací k tomu, že z toho dlouhého seznamu podporovaných architektur pro praktické použití - dle mého odhadu - platí dvě

[Pavel Píša]

GCC chce pro eliminaci se narovnáváků na ohýbáky AVR podpory zbavit

... což se projevuje tak, že je podpora AVR aktivně vyvíjena v upstreamu?

Tak pokud se postupně nemá podpora rozpadat, tak je potřeba minimálně udržovat build systém a věci specifické pro běh na různých hostitelských systémech v nějakém alespoň trochu aktuálním stavu. Typicky vycházet při tom z mainline je nejméně časově náročné. AVR podpora tedy vychází z GCC mainline i když třeba ty novější verze standardu C a C++ by nebylo potřeba stejně jako lepší optimalizace pro plánování instrukcí na superskalárních architekturách. Tam by šlo ustrnout na staré verzi.

https://gcc.gnu.org/git/?p=gcc.git;a=history;f=gcc/config/avr;hb=HEAD

Ale zdá se, že se tomu zase nyní někdo věnuje, takže backend od popravy zachrání.

Míra podpory HW se podle platforem liší. ...

Což nás vrací k tomu, že z toho dlouhého seznamu podporovaných architektur pro praktické použití - dle mého odhadu - platí dvě

Myslím, že kromě ARM a RISC-V byla celkem dobrá podpora Z-80, ale ta je také za zenitem. NuttX například v mnoha na Z-80 postavených VoIP telefonech. Ale také to bude souboj a staré Z-80 C nutí držet jádro NuttXu na C89.

Z mého pohledu je i zázrak jen to množství ARM a RISC-V platforem. Ten základ, plánovač a tak, to si umím představit, ale hlavičky od starých 32-bit ARMů, přes platformy s Cortex-A/M od STM, NXP, Microchip, GD a mnoha dalších, Ti TMS570 (sice nedotažená) ale extrémně těžká.

[Pavel Píša]

Online stream NuttX Workshop DAY1

https://www.youtube.com/live/tqWwKLCD0dU

[...]

Dost nabubrela poznamka o zdrzovani se nekym, kdyz je cela Vase existence placena z verejnych penez a v komercni praxi byste davno shorel, jak ten papir. Kdyz se nikam nepospicha a delate si cele dlouhe roky jen na tom, co Vas bavi a na cem si chcete delat (ctete: hrat), to se to pak machruje na ostatni... navstevniky stanku, mlade studenty, atd. To Vase ego je k smichu.

Co jste dokazal? Rozchodit field oriented control algoritmy po tom, co jsou davno velmi dobre publikovane? A co jako? A jak dlouho jste na to mel - a kolik lidi k ruce, ze ano

Pane kolego, myslite si skutecne, ze timto svym pusobenim pomahate nekomu nebo necemu jinemu, nez vlastnimu egu?

[...]

NuttX je hracka hodna studentu strednich skol, presne tak na urovni toho Arduina, na ktere tak rad plivete. Zajimava vec, to ano, ale stale rozbita hracka bez nejakeho serioznejsiho pristupu za ni. Od vysokoskolskeho pedagoga by se cekala nejaka prace, ktera posouva hranici dal. Kdyz ona ale ta akademie utekla Vasim schopnostem a v CR se mezi temi mladymi jen tak nenajde nekdo, kdo by Vasi praci patricne zkritizoval, ze :D Tady to proste staci, a takhle my si tu zijem :D

Vsechno by bylo v pohode, kdyby to bylo bez te nafoukanosti a arogance.

[Pavel Píša]

Tak něco málo zajímavějšího by se našlo, třeba 33 po dobu let pár dodávek přístrojů HPLC do https://www.uochb.cz do skupiny polypeptidů. Ale je pravda že vlastně nevím, jestli to mohlo přispět k vývoji léků pro pozastavení rakoviny nebo AIDS. Elektroniku a firmware k první generaci jsem navrhoval, když jsem začínal studovat na ČVUT FEL. K tomu jsem navrhl komunikaci, kterou použili (protože je open source) i v dalších firmách. Díky otevřenosti našich protokolů a komunikačních knihoven mohli pro přístorje (v naší licenci vyráběné, vývoje kompletně financovaný z rodinných zdrojů, žádná dotace) začít jak komerční firmy stavět SW, tak i jeden profesor se zájmem z Univerzity Karlovi ze zájmu implementovat další SW. Za práci jsme mu platili a i jsem hodně připěl a udržuji software a portuji ho na GNU/Linux i přes to, že původní výrobce našich přístorů nyní vyrábí jiné/"vlastní", vývoj zaplacený z grantů, ale nějakou náhodou je většina kritických dílů podobná těm našim nebo připravovaným inovacím. Za vývoj otevřeného analytického SW CHROMuLAN jsme i dost kolegovi zaplatili. A přesto, že je to takové osiřelé, chudé dítko, tak se celkem používá, viz třeba seznam. Z tohoto již stařičkého software jsou i nadšení v https://www.omicronbio.com/. Pokud změníte styl od klasického anonyma v hrdou osobu se jménem, e-mailem a dalším, rád Vám přepošlu akorát nedávný e-mail, kdy při přechodu na Windows 11 (ano, naše drivery jsou na to připravené, i když prvotně jsou vyvíjené na GNU/Linux) něli problém s tím, že nerozzipovali instalaci a update nenašel inf a podpisy. Zatím, zaklepat, bez poruchy, tam 7 ULAD32 a starších ULAD31 běží po 14 let bez poruchy.

Pro naše přístroje jsme plně digitální řízení motorů s procesory používali od roku 1990. Nejdříve DC, později PMSM, dávno před O-drive, VESC atd., vývoj plně financovaný naší firmou jsme předal na ČVUT FEL pro robotické týmy. Vše co CTU dragons a Flamingos jesdilo, bylo na základě mé práce, přesto, že sliby připravit stránky a další nedodrželi, tak jsem to byl já, když špatnými rozhodnutími poškodili zkopírovaný návrh a zničili na motorech co mohli, kdo zůstal ve škole přes noc, aby ráno vyjeli. Přesto, že jsem v seznamu členů nebyl.

A takto mohu pokračovat dále. Díky našemu přispění do vývoje elektroniky infúzních pump (také nám bylo pár miliónů z podílu na prodejích na zpětné placení vývoje upřeno) existovala konkurence k BBraun a dalším. Sice v lobingu v nemocnicích byly ti cizí úspěšnější, ale i těch pump (injekčních i volumetrických) s naším HW a firmware se nějaké dva tisíce prodaly a minimálně po 10 let i ty lépe mezi doktory "propagované" pumpy ze zahraničí se v ČR prodávaly za polovinu. Pokud bych tedy dostal jen 10% z jejich rozdílu ceny v důsleku konkurence od nás, tak bych určitě měl na menší hrádek a zajištění do penze. Podobně s odparkami od Buchi atd...

Takže Vaše vyjádření, že bych se bez toho platu na FEL, vždy jen poloviční úvazek a mnoho let okolo 20 kkč měsíčně neuživil není moc fér. Ale co čekat od anonyma.

Teď jdu pomoc s vysíláním na NuttX workshop a pak něco napíšu třeb dále.

[...]

marketing vlastnich schopnosti byste mel zvladnuty, ale celym tim obsahem jste akorat presne potvrdil to, o cem mluvim nabubrela nafoukanost bez podkladu, trivialni veci od A po Z, to ma fakt smysl, pro takove vzdelani si jit na CVUT a jasne ze Kapuca vedle z toho ma taky opruzeniny, protoze je od tyhle nabubrelosti taky nakazenej, proto si muze myslet, ze vynalezl disklessove sendvice, evidentne je to na CVUT proste normalka

myslete si klidne, ze jste se obhajil, za mne v pohode ja se jen smeju dal

[...]

kdybych u toho nafukovani vasich schopnosti nestal nekolikrat s nemym uzasem, netvrdil bych to s takovou jistotou zazite na vlastni kuzi, mnohem vickrat, nez bych chtel

[Aleš Kapica]

Není nad to anonymně plivat, viď? Šulin jako ty, se zmůže leda tak na anonymní štěkot v poušti.

[Pavel Píša]

NuttX je hracka hodna studentu strednich skol,

Přesto, že s tímto tvrzením souhlasím, a bylo by to opravdu mnohem lepší než nesystémovým Arduino přítupe mrzačit a zneschopnit další generace, které bez toho pokaženého IDE a preprocesoru INO a špatných knihoven nic nenaprogramují. A souhlasím i s tím, že v mnoha případech NuttX nedosahuje kvalit, kterých bych si přál, tak zde pro "milého" anonyma odkládám informaci od Xiomi, kde potvrzuje jen v oblasti terminálů 100 miliónů nasazení v článku o letošní OpenVela (downstream od NuttXu) konferenci, která v Kostarice navazovala na NuttX workshop.

openvela's Inaugural Global Developer Conference Concludes Successfully, NuttX Founder Gregory Nutt Joins to Shape AIoT Ecosystem

[Aleš Kapica]

Pane kolego, myslite si skutecne, ze timto svym pusobenim pomahate nekomu nebo necemu jinemu, nez vlastnimu egu?

Tomu pomáháš svými anonymní kecy leda tak ty, moulo.

[Pavel Píša]

Na nepodložená nařčení nemá smysl odpovídat a něco vyvracet, sám víc, co jsem udělal a že napsat 138365 (blanck 15771 a comment 7524) linek v assembleru byla docela dřina a některé ty projekty založené na MHB 8051, Philips 87552, 80552 a Siemens 80C517A slouží i po 30 let. Pro pořádek, základní sčítaní, násobení a dělení jsem přebral z nějakého článku, ale vše ostatní, i logaritmy a převody na IEEE-754 na uLAN jsem psal jen sám. Již když jsem frimware psal, tak mě bylo hodně líto, kolik umu musím vynakládat na psaní v assembleru a bez operačního systému. Jenže na to, založit elektroniku přístrojů na něčem silnějším, napčíklad 60332 jsme nemohli, protože samotný čip stál okolo 1000 kč a to bylo moc. Přitom jak vypadá vývoj na takové procesory a především na Unix jsem si na přes embargo pro Vývojové dílny akademie věd získaném vývojovém systému Philips PMDS-85 vyzkoušel již v letech 1987 a 1988. Ale musel jsem žít v assebleru, C jsme na 8051 zkusily, ale pro požadovaná funkce, někdy až řízení šesti os na 1 kHz s komunikací RS-232 na povelování, I2C na remote klávesnici stejně jako pro čerpadla s komunikací uLAN, časovým, na lokálním panelu a vzdáleně programovatelným časovým programem a další šance psát v C nebyla. Ale někdy okolo roku 1995 jsem si udělal radost a koupil si od Amiga klubu asi za 20 kkč kit M68332 EVK. Bylo to se slevou a informací, že jeden GPIO/chip-select pin je spálený.

Na své Intel 486 jsem zkompiloval pod GNU/Linuxem GCC a pustil se do vývoje, zapojil jsem se do vývoje ladícího rozhraní BDM (background debug mode, předcůdce JTAG) a řešení pak používali na mnoha univerzitách a firmách po světě. Radil jsem někomu z Roche Diagnostics, který používal BDM na zavedení firmware z jedné 68332 do druhé, tak aby nemusel mít dvakrát Flash, pak se mi o radu ozvali i z Kanadské robotické firmy, myslím že to byla firma spojená i s něčím kolem ruky na raketoplánu. Jeden čas byla moje stránka nejnavštěvovanější na serveru centra, protože čipy na bázi 683xx se používaly hodně v řídících jednotkách automobilů a bylo mnoho firem, které nabízely i méně oficiální update.

Ale ve firmě jsme musel stále pro udržení ceny psát v assembleru na 8051. Na infůzní pumpy to se firmware v obou procesorech musel po mnoho let vejít do 8kB OTP ROM a 256 B RAM na dvou 87552, které se vzájemně přes I2C hlídaly, každá spínala jiné tranzistory v motorovém můstku a jeden měřil polohu z IRC a druhý absolutní. K tomu komunikace, výpočty rychlostí z limitů a když se přidávala funkce, tak jsem ke konci hledal, kde kód o pár byte stáhnout, aby se vešel do 8 kB. Na HPLC a analyzátorech aminokyselin jsme měli vždy 32 kB EPROM a 32 kB SRAM a měli jsem zapojení 80552 upravené tak, aby se externí paměti mapovali von Neumannovksy do jednoho prostoru, takže přes uLAN šlo i kód pro testování nahrát, sledovat stav program z komunikace pod přerušením bez jeho brždění a i bylo možné ho zatavit a krokovat. Opět k anonymovi, myslím, že to na tehdejší dobu nebyla běžná řešení a těší mě, že například analýzy u novorozenců určitě pár z nich zachránily od demence a dalších potíží. U infúzních pump jsem si přál, abychom je já ani nikdo jiný nepotřebovali, ale když jsem je programoval a vymýšleli jak zajistit precizní vzájemnou kontrolu, tak jsme to brali hodně poctivě. Cizí renomované značky tam mívaly MCU jej jeden a jeden diskrétní watchodg obvod. My to měli dvakrát a i výpočty dvakrát jednou na rychlost, jednou z ujeté vzdálenosti na čas. Nakonec jsem šest těch našich viděl na svém tatínkovi. Personál s nimi byl velmi spokojený.

Pro ČVUT FEL, jinou katedru a čistě na objednávku a spíš pod cenou jsme okolo roku 2000 navrhli pro jimi vyvíjené roboty BlueBot řídicí jednotky s M68376, takže jsem si konečně mohl i na naší procesové desce hrát s něčím pěknějším v C. Již při těch prvních pokusech s 68332 o pět let dříve jsem si vyzkoušel RTEMS i něčím přispěl. Ale nakonec se ukázalo, že na řízení 8 os s koordinací (až po spline funkce) a mnoho dalšího na 1 kHz nezbude na procesoru běžícím na 21 MHz (s tím, že přes 16 bit sběrnici se i nejkratší instrukce natahují a vykonávají dva cykly) nezbylo, než i tady jít kombinací C a specializované volací konvence přes registry v assembleru. Na RTEMS pak již čas nezbyl, takže jsem použil řešení bez OS. Na komunikaci po sériové lince s buffery pod přerušením to stačilo. Vykonávané příkazy PXMC jsou také v hlavní smyčce jen plánované a řazení bez čekání a vykonávané ve stavových mašinách pod přerušením. Tent styl programování je celkem náročný na disciplínu, uvažování konkurencí atd. Většina byla vyřešené i bez zakazování přerušení.

Pro složitější komunikační protokoly je tento styl programování přes neblokující stavové mašinky a přerušení opravdu velký problém a vždy jsem byl přesvědčený, že RTOS je ta správná cesta. Takže i moje psaní pro tagety bez operačního systému (sysless, opět použitý i věkolika jiných firmách) bylo navržené tak, aby věyšinu šlo testovat i na GNU/Linuxu a jednou portovat i na RTOS. Na 68376, jsme si nakonec i RTEMS a jádro Linux naportovali a tak šlo zkusit i Ethernet a další. Ale představy o možnosti spolupráce s některými lidmi nevyšly a mezitím jsme již řešili druhou (kvůli přeprodávání zadavatele nedotaženou) a pak tředtí generaci infúzních pump, kde již byl naplno model vývoje testování GNU/Linux a na target RTEMS použitý a byl to krok dopředu. Ale to třeba někdy příště.

Nyní se mi období s 68376 připomělo tím, že na opravu přišla jedna elektronika MARS8. Po 10 letech v provozu ztratil kapacitu jeden kondenzátor ve zdroji. Ten kolega vyměnil a nyní mi na stole zase sestava běží na stole běží.

# MARS8 v0.7 build Pi Nov  5 2013 18:27:34
# test mode disabled
# kl41_lcd_init :   -1
# date : 2025-10-21 18:03:13

Velmi mě překvapilo, že i po asi 10, možní i více, letech byl čas na RTC mimo jen o pár minut. Jednotka zase půjde do procesu. Jednotka ve firmě Preciosa spolupracue s kamerami a zábleskovým osvětlením, kdy detekuje průchod kamínku na velkém otočném stole, ve správném okamžiku zajistí jeh osvětlení a spuštění kamery a předá polohu počítači, ten odebere obraz, provede vyhodnocení velikosti a třídy kvality a naplánuji, po jakém úhlu se kamínek sfoukne do příslušného zásobníku. Tím, že je ta akce odfouknutí podle úhlů na otočení různě odložená tak ta fronta poloh hlášených z počítače se pěkně překrývá a je nutné ji zatřiďovat. Celem hezká úložka na řešení se zamykáním IRQ jen po O(1) dobu, přesto, že zatřiďování je přes AVL (uLUt GAVL) O(log(n)). O návrhu té optické části a zpracování obrazu pak napsal svojí dizertační práci (Light Propagation in Transparent Polyhedra) doktor Vladimír Smutný.

Obecně závěrem, opravdu si myslím, že mám velmi dobrou představu, jak je složité komplikovanější aplikace psát bez operačního systému přímo na HW a získat maximum. Určitě z hlediska náročnosti na vývoj, pozdější možnosti úprav, portování atd. se to kromě nějakých extrémně vělkých sérií dnes určitě nevyplatí. Výkon narostl, používají se 32-bit procesory s 32-bit a širšími směrnicemi k cache a interní Flash a třeba NuttX je podle mě použitelný kompromis. Ano, souhlasím, že na RTEMS, VxWorks, QNX a další zdaleka v robustnosti návrhu a kvalitě plánovače nemá. S těch dalších tří, se kterými mám také zkušenosti, si já pro ty kritické projekty vybírám RTEMS. Vyhovuje mi díky otevřenosti, předpřipravených certifikačních podkladech pro ESA a sice malé, ale přátelksé komunitě.

Pro ty méně kritické a kde chci alespoň snadno získat alespoň základní drivery pro ADC, DAC, PWM, IRC, atd. tak NuttX. A opět, nazývat ho nějakou školskou hrátkou placenou z grantů je velmi nefér. Autor, Gregory Nutt vyvíjel RTOSy pro laserové tiskárny, čipy a další ve firmách jako je Hewlett-Packard. V současné době je hybnou silou Xiaomi, vybral si ho i Samsung, ale lincenčě zcela zbytečně strašně uškodil a roztříštil síly, jeho Tizen RT na bázi NuttX je podle mě mrtvola. Ale na fitness náramcích od více firem, dronech a audio zařízeních (třeba i Sony) se NuttX ujal a firmy přistupují ke spolupráci konstruktivně. Probíhá i iniciativa Li Auto, kde je zájem NuttX nasadit jak v méně kritických částech, kam jinak z té kritické oblasti zasahuje AutoSar, tak i na displejem vybavené jednotky, kde by mohl nahradit Android. Sám souhlasím s kritickou, že zatím jsou tyto oblasti k současnému stavu hodně ambiciózní a možná za hranou. Ale na druhou stranu na PX4 se NuttX osvědčil a představa o spolehlivosti a dalším nějaká již bude.

[trekker.dk]

Jenom pro ověření, že to dobře chápu - PX4 je aplikace, ta běží nad NuttX kernelem (neřešme terminologii typu kernel build apod.) a to celé ovládá drony a podobné, tj. řídí motory, udržuje tu věc v pohybu a ve vzduchu apod.? Hledám odpověď na otázku, jestli je NuttX dost spolehlivý na to, aby se s tím daly ovládat věci, kde by mohl být přesah do bezpečnosti (např. nevypnutá topná spirála) - použití v dronech apod. by byla dobrá odpověď.

[Pavel Píša]

Ano, https://px4.io/ se stará o řízení dronů, většinou nerealizuje přímo elektroniku, která komutuje PMSM motory, má mnoho výstupů na pulzní nebo digitální ovládání serv, atd. komunikuje se základnou atd. Spíš není na přenos videa, to bývá mimo, případně na letovým kontrolérem PX4 je ještě nadřazený systém s GNU/Linuxem. Tak se to provozuje u nás. NuttX obsahuje i drivery a implementaci pro PMSM FOC a je tak užívaný, ale samotný PX4, pokud vím, tak se přímo na HW s integrovanou výkonovou částí nepouští. Ale na druhou stranu, sám se zatím dronům nevěnuji. Když bude zakázka, tak ale HW klidně navrhneme.

Co se týče spolehlivosti, tak PX4 je klíčová komponenta a pokud její řízení motorů a snímání IMU a další selže, tak dron havaruje. Takže ano, NuttX je komponenta, která je v běžných nasazeních jeden ze single point of failure. Nám také na PMSM řízení chodí celkem spolehlivě. Na druhou stranu, v Elektroline se s ním nikdy na SIL3 (např puštění dvou tramvají proti sobě na jednu kolej) nepočítá, je tam lock-step CPU mimo a NuttX řeší komunikaci a další, kde maximálně dojde k zablokování křižovatky nebo poslání tramvaje na špatnou kolej, bez vykolejení, přítomnost nad výhybkou řeší ta SIL3 část zapojená do kupovaného safety PLC s certifikací.

Takže záleží na tom, jak zlé konsekvence případná chyba bude mít. Hodně lze pokrýt i integrovaným Watchdogem v MCU, opět NuttX drivery často obsahuje. Ale v okamžiku, kdy bude důsledek chyby závažný (požár domu, ublížení pacientovi, třeba předávkování atd.) tak bych určitě samotný NuttX na jednom MCU za bezpečný nepovažoval. Stejně tak jako běžné MCU. My na infúzních pumpách měli vždy dva procesory a u těch novějších naschvál různých typů a jeden s RTOS (RTEMS) a druhý bez OS. Ale to bylo jen s požadavkem na přechod do bezpečného stavu, každý z procesorů mohl čerpání zastavit a zaručeně zajistit červený pruh rozsvícených LED a pípání.

Pokud má být zaručená i funkce v případě jedné poruchy, tak to chce tři systémy a majoritu ze tří na certifikovaném HW. I jen technology preview helikoptérky Ingenuity, čili z pohledu NASA nekritická aplikace, mělo dva čipy TMS570LC4357, tedy dva safety MCU, každý se dvěma jádry v lock-stepu, výstupy spojené přes MicroSemi ProASIC3L FPGA (certifikované) , které při vyhodnocení chyby MCU (error pin) hlavního letového kontroléru na TMS570 přeplo na trvale připravený a datasledující záložní TMS570, který se postaral o řízené nouzové přistání. Nad tím vším byl GNU/Linux na celkem běžném ARMu (v telefonech tak před 10 lety), který se staral o kamery a další. Ale pokud selhal nebo začal dávat povely ohrožující stabilitu, tak přebíraly řízení a nouzové přistání ty TMS570.

Takže myslím si, že NuttX pro běžné aplikace, kde hrozí finanční škody v přijatelných mezích, tak použitelný je. Za mě lépe než ty různé firemní hrůzy nad FreeRTOS. Ale zase je potřeba ověřit, jak je na tom na konkrétním HW. Na druhou stranu co jsem viděl v TI CSS s jimi dodávanou integrací LwIP (záseky, funkční až po kompletní naší předělávce a trápení se s FreeRTOS) a další, tak proti tomu je NuttX podle mě lepší. Ale nějakou SIL, i jen 1, záruku ani na vlastní HW jen s jedním MCU a NuttXem bych nedal, na tož na cizí HW. Pokdu pak běží něco složitého, kde je riziko selhání i třeba nějakých složitějších dynamických alokací, chyb práce s pamětí, tak tam by bylo dobré tu rizikovější část vlastního kódu oddělit do vlastního procesu a používat ochranu paměti. NuttX na to ně některých HW podporu má, ale používá se málo a bude tam asi dost věcí nedotažených a potíží. Další možnost je kombinovat NuttX s aplikací v Rustu. Informace o integraci Rustu a NuttXu jsou i na oficiálních stránkách s balíčky pro Rust. Hodně zajímavých článků o svých příspěvcích do NuttXu včetně Rustu lze nalézt v sekci Articles na stránce vývojáře Lup Yuen LEE.

[PokoPi]

Zajímal by mě váš názor na Micropython(https://micropython.org/). Nemáte s ním zkušenosti? Myslíte, že kromě prototypování, může mít tenhle přístup budoucnost ( interpretr splyne s „operačním systémem“ )?

[Pavel Píša]

Zkušenosti Micropyhtonem sám nemám. Espressif a další ho mají integrovaný. Na NuttX Micropython a i plnohodnotný Python lidé portují. Ale v jakém je to aktuálně stavu nevím. Velká výhoda je, že se portuje normálně Unix/POSIX port/integrace, takže těch věcí ke změnám by mělo být celkem málo. Plnohodnotný CPyton předpokládám, že v zásadě portovat půjde, ale paměťové požadavky a asi i požadavky na místo v RAM disku nebo na jiném souborovém úložišti budou velké. Micropython by se vcházet měl na trošku silnější MCU dobře. Pull request Micropythonu do NuttXu je k dispozici viz pull request nuttx-apps interpreters/micropython: Add Micropython support to NuttX (WIP) #840 . Čtyři body k portu jsou vyřešené, tři pro float a další zbývají.

Obecně sám mám jako skriptovací jazyk Python rád. Ale na náročnější práci s daty musí sloužit jen jako lepidlo, které ochestruje kvalitně napsaný kód v jazyce C nebo jiném kompilovaném, ať programu, nebo modulu. NumPy je na velké výpočty díky Atlasu a dalším technologiím vespod předkvapivě konkurenceschopné i proti běžnému řešení úloh jako je násobení matic s OpenMP a MPI studenty v C.

Na řízení by podle mě python neměl být v RT kritických částech ani na MCU ani na velkých GNU/Linux systémech. Max na nějaké desítky Hz, možná i nekriticky, kde nějaký skluz nevadí na 100 Hz. Ale sám bych na něj v takových aplikacích nespoléhal vůbec. Ale na nějakou logiku řízení domácnosti a tak si myslím, že to minimálně na prototypování může být dobrá cesta. Ale využitelný výkon to na měnších CPU určitě sníží násobně. Zcela od boku odhad tak 10x proti kvalitně napsanému C kódu. Ono možná má na výkon větši smysl webassembly, kde jsem byl celkem výsledky třeba na našem Qt simulátoru v prohlížeči překvapený. Ale na NuttXu jsem ho nezkoušel a zase tak optimistický bych také nebyl.

Nějaká dokumentace k interpreterům dostupným z konfigurace NuttXu zde https://nuttx.apache.org/docs/latest/applications/interpreters/index.html.

Celkem budu rád, když někdo popíše zkušenosti s Micro/pythonem na MCU a to klidně i mimo NuttX.