Názory k článku Operační systém NuttX: programování s RTOS na embedded zařízeních
-
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
Otazka je, ci je kompatibilita s POSIXom v embedded priestore niekomu na nieco vobec dobra. Dovolim si tvrdit, ze ani nie. Niektore casti POSIXu su uzitocne, vela ich je `meh` a niektore su ciste peklo.
Schopnost spustit embedded kod na Linuxovej masine sa da pohodlne dosiahnut aj bez tohto traitu.
-
Mať možnosť použiť hotový POSIX kód a priohnúť ho na embeded zariadenie je veľký benefit.
Reálne použitie je také, že môžeš mať rovnaký algoritmus a bežať ho v serverovej verzii a aj v embedded verzii pre malé zariadenie. Nie si potom obmedzený nástrojmi, ktoré ti ponúka development kit toho embedded zariadenia/operačného systému. Hovorím to z autopsie.
E: Aby som to zhrnul - je to dobré kvôli škálovatelnosti.
11. 6. 2026, 11:53 editováno autorem komentáře
-
Lenze use caseov, ktore toto vyzaduju je pramalo. A use caseov, ktore toto dokazu prezit pri spusteni na znacne memory-constrained MMU-less HW je este menej.
A za nejakou hranicou to ohybanie uz zacne dost vadit. Napr. cely koncept shell-centrickeho pristupu na embedded zariadeni je tak nejako mimo misu, lebo embedded je hlavne o tom, ze pri normalnej prevadzke sa nikto v tom pocitacovom systeme nehrabe a ten system sa tvari, ze tam nie je.
Iste, NuttX ide nabehnut aj na regulernej x86tke. Tam to ale podla mna uplne straca zmysel, lebo na prakticky akejkolvek x86tke nabehnem aj Linux alebo NetBSD, ktore poskytuju ovela standardnejsie prostredie.
Algoritmus, ktory bude bezat v serverovej aplikacii aj v embedded prostredi mozem mat aj bez POSIXu, ak ten algoritmus je decouplovany od prostredia v ktorom bezi. To zas nie je tak velka raketova veda.
-
Treba muj OS neni vyslovene shell centric, ale po vice nez stovce aplikaci/projektu existuje jen par vyjimek, kde by shell nebyl soucasti, a jen velice malo produkcnich releasu melo shell vypnuty.
Mozna nedelam spravny embedded, nebo jsem vadnej s tim pristupem - ale pro me mit shell (dokonce s napovedou na TABu) byla vzdy vyhodou meho reseni, oproti nejake jednorazovce, kterou musit porad updatovat jako ovce.
S cim prijdete priste? Ze pouzivat #define pro konstanty je zle, a mame to upravovat na peti mistech, protoze to neni dost embedded?
-
Ne, naopak, pridavam se: UNIXovy "stavebnicovy" pristup mnoha modularnich drobotin, ktere poslepovany dohromady tvori mocny a hlavne flexibilni system, se velmi hodi.
Samozrejme tam vzdy bude nejaka rezie, suboptimalita proti hypotetickemu monolitickemu reseni, ale je to vyvazeno nesmirnou usporou mozku a casu vyvoje a nasledne schopnosti improvizovat, at uz na strane autora nebo uzivatele.
Ocenili jsme to i v druzici, bylo to naprosto zasadni.
Je to podobne i v HW ci mechanice. Clovek muze delat vetsi, jednoucelove celky, nebo to udelat vetsi a tezsi, ale vice modularni.
-
Kdyz jsem psal svuj IP stack pro AVR, tak jsem se rozhodl ze tam bude BSD sockets API, na rodil od tehdy konkurencnich ip stacku ktere meli nejaky frikulinsky callback system.
Priorita byla moznost portovat nebo testovat kod primo i na beznem OS. Jiste.. dalo by se to udelat mozna nejakou zbytecnou mezivrstvou, ale proc investovat sve prostredky do slepe ulicky.
-
To je v pohode, pretoze BSD socket API, bez ohladu na tom kde pobezi, stale bude robit konceptualne tu istu robotu.
Problem s plnohodnotnym POSIXom v rydzo embedded pouziti je, ze na niektore veci je POSIX overkill, pretoze pocita s konceptom ovela komplikovanejsim, nez je nutne. V pripade NuttX-u je to napriklad existencia "suborov".
Subory su v embedded do znacnej miery mimo misu. Vela embedded systemov realne ani suborovym systemom nedisponuje, lebo je to pre nich malo muziky za vela penazi. Vystacia si s jednoduchym key-value storage, ktory v pripade NuttX je nutne pretahovat cez VFS vrstvu, ak to nema byt riesenie robene na kolene.
Pekne pre tie styri aplikacie, co potrebuju hierarchicku, dynamicky generovanu konfiguracnu strukturu s moznostou introspekcie. Pre zvysok sveta overkill.
Podobne tazkopadne su v embedded svete POSIXove synchronizacne primitivy.
-
NuttX již nějakou dobu sleduji, pro hafo aplikací nemusí představovat špatnou volbu, ale tvrdě real-time systémů bych ho určitě necpal, notabene už i kvůli jeho velikosti, overheadu ovladačů, chybějící certifikaci apod. Pohybuji se v řídicích systémech pro výkonovku a k naší spokojenosti používáme ThreadX, či RTOS-less přístup.
Na druhou stranu se mi tu válí Rpi Pico 2W, tak si ho během dovolené vyzkouším pro tahání dat o počasí ze serveru a zobrazování na LCD... -
No zrovna to odsuzování z pohledu certifikace je trochu kopnutí se do vlastní nohy.
Xiaomi Vela OS V5.0 (https://github.com/open-vela) je firmou Xiaomi na NuttXu postavený operační systém, který je kromě VxWorks 7 a ZTE Automotive OS V3.0 https://posix.opengroup.org/register.html, jediný další, který oficiálně splnil podmínky specifikace PSE52 Realtime Controller 1003.13-2003 System konsorcia The Open Group.
Neříkám, že je vše jen růžové, ale Xiomi investuje i do pomoci mainline NuttXu jít dopředu a spolupráce běží a tedy i mainline NuttX se požadavkům PSE52 přibližuje.
Souhlasím, že pro velmi na zdroje/paměť omezená zařízení představuje POSIX přístup příliš velkou zátěž a také na míru sestavená obsluha periferií z přerušení přímo realizující řídicí aplikaci většinou i bez plánovače může jít tam, kde přístup přes ovladače požadované vzorkování vylučuje.
Co se týče SHELLu, tak je na NuttX je volitelný, ale velmi příjemný pro vývoj a testování. Jinak lze v konfiguraci za vstupní bod po initu nastavit přímo nějakou funkci aplikace, její main. Přitom při volbě kompilace s MMU bude taková aplikace stejně jako SHELL puštěný v uživatelském režimu s ochranou paměti pro systém a další aplikace. Na druhou stranu je MMU režim opravdu zatím spíše jen experimentální, i když plánovaný hned od začátku. Zatím má NuttX využití především tam, kde MMU není a zdroje jsou zcela mimo možnost pustit GNU/Linux a podobné systémy. Ale je možné, že jak GNU/Linux roste a dnes pro rozumný běh bude požadavkem tak 64 MB RAM a levná MCU dostávají MMU (třeba ESP32S31) a omezené množtví PSRAM (třeba 16 MB) tak najde NuttX využití i zde a dojde k doladění jeho běhu v MMU módu.
Stejně tak zatím podpora SMP stále spíše na testování než seriózní aplikace, ale i to se může celkem rychle podle potřeb změnit.
Důležitá je rozumná struktura zdrojového kódu a jednotný model a styl psaní ovladačů a to až na jednu výjimku bez vrstev HAL, které často po snadném rozjedu koncepční přístupy komplikují.
-
Tak on Linux "bezi" i na 1MB nebo 2MB kdyz se moc chce, viz nedavna prezentace:
https://www.youtube.com/watch?v=YC8GFfuQ1IU
Vim ze je to tezka podivana kvuli jazyku a prezentacnim schopnostem, ale na konci je link na github takze si to lze zkusit.
Pak uz je to jenom otazka, ze kolik stoji context switch.. aby padlo rozhodnuti jit do Linuxu, nebo nejake embedded knihovny/frameworku.
Ale je to zajimava konvergence a vymena roli - muj puvodne AVR OS jsem nedavno naportoval na ty velke arm-y a RISC-V, ktere jsou schopny poustet Linux... a Linux se naopak vecpal do "mikrokontroleru" jako stm32 :D
-
Před asi 25 lety jsme měli Linux jako experiment naportovaný na naší vlastní desku s M68376 (MO_CPU), 2 MB of FLASH , 2 MB of fast SRAM, CPU nemám MMU, takže userspace byl uCLinux a běhalo to i s rozšiřující deskou s Ethernetem, TCP/IP, telnetem, atd... Experimentálně jsem měl puštěný U-boot a jádro Linuxu i na naší LX_CPU s NXP LPC4088, ARM Cortex-M4 a externími 32 MB DDR DRAM. Ale opět buď je to uCLinux nebo šílené přemaovávání po subregionech na MPU a stack nesmí jít nikdy mimo mapovaný a pro ten účel rezervovaný region, protože architektura Cortex-M není na uložení stavu na alternativní stack při výpadku stránky na tom uživatelském rozumně připravená. Doublefault bez možnosti návratu.
Takže ano, předvést jako lodičku v láhvi a pochlubení se toho lze hodně. Ale prakticky to smysl nemá. Před pár lety šlo ještě Linux kernel provozovat v routerech s 8 MB RAM, ale jak systém sílí v namespacech, rychlých vyhledávacích strukturách, lockless a SMP, kde původní UP s alternativními mechanizmy je v podstatě již zrušené, tak těch 64 nebo možná ještě 32 MB je minimum. A přitom dnes je dost MCU, kde již je naintargrovaná RAM okolo 1 až 2 MB a nebo nějaká PSRAM okolo 4 až 16 MB. Ale s jádrem Linux se to již neschází.
-
Navzdory fuzatemu Linusovemu varovaniu, ze Linux by na MMU-less masine spustal iba uplny magor, Linux dnes podporuje MMU-less build, takze ho ide spustit aj trebars na STM32H7, mozno aj bez externej PSRAM.
Problem je v tom, ze je to dost kockate, rozchodit to je dost trapenie a kompatibilita je otazna.
Ak by som fakt bol v situacii, ze potrebujem na mikrokontrolleri kompatibilitu s POSIXom a neviem z toho nijako vykluckovat, tak pojdem cestou FrostedOS. Lenze aj napriek tomu, ze na FrostedOS ide na H7cke spustit nemodifikovaneho Dooma, tak vam jeho autor povie, ze ste magor ak chcete POSIX behat na MMU-less masine.
-
Použití plného POSIX včetně požadavků na fork, procesy, shellové příkazy s e všemi povinnými volbami atd. je opravdu v MMU less embedded nerozumné, ale PSE52 Realtime Controller 1003.13-2003 System subset je rozumný a je to to, na čem VxWorks, Zephyr a další získávají body. Sám z hlediska otevřenosti a vývoje a i ne úplně tvrdě daty přeložitelných referencí preferuji v tonto segmentu NuttX a RTEMS.org. Ale těch use cases podložitelných referencí a třeba i analýzou latencí, certifikacemi aplikací, atd. třeba pro RTEMS najdete hodně a třeba letošní podklady od ESA TECHNOLOGY HARMONISATION ADVISORY GROUP, EUROPEAN SPACE TECHNOLOGY HARMONISATION
TECHNOLOGY HARMONISATION pro ON-BOARD SOFTWARE, pro space jasně říkají, že v Evropě je jediný smysluplný směr pro kritické onboard počítače RTEMS jinak RTEMS a GNU/Linux.Ale na domácí hraní a běžné věci je s RTEMSem potíž, že je to sice kvalitní SMP jádro (multitherad in sigle POSIX proces) pro mnoho architektur, ale chybí pokrytí periferií a běžných neletových MCU. Na kritické mise to nevadí, v ceně vývoje návrh všech ovladačů nad pecertifikovaným jádrem pro speciální HW je v zásadě malá částka. Pro běžné uživatele je to blocker. I když teď byla do RTEMS mainline zaintegroaná podpora ESP32C3 a čeká na začlenění ESP32C6. Raspberry Pi je také pro podporované a třeba pomohlo pro otestování NASA cFS protože cílový InnoFlight’s CFC400X (AMD/Xilinx UltraScale MPSoC) pro kameru a řízení dockování na Artemis s RTEMSem byl k dispozici se zpožděním. Více od slide 57 v mé prezentaci RISC-V Processors, Own IP Cores, Code and Porting for Education, RTOSes and Real Missions pro Katedru digitálního návrhu FIT. Odkaz na demo video na slide 63. Jinak v prezentaci je i více o ARM, RISC-V a našem zapojení do RTEMSu, NuttXu a dalším kde připsíváme.
-
A spíš to tam bude asi lepší. I když Xiaomi v projektu https://www.liauto.com/ plánuje Vela/Halo OS na bázi NuttXu nahradit jak Autosar v RT řízení automobilů viz Li Auto's Halo OS: A New Era in Automotive Software tak i Android na palubních deskách a již třeba do Vela/Halo OS portovali Binder. Ale v současném stavu to považuji za přepálené, ale pokud se podaří vývoj udržet a prostředky na to mají, tak to za několik let může být pro základní věci a funkční auto dostatečné.
-
HaloOS Autosar nenahradzuje. Halo OS je in-house implementacia specky Autosar Classic (aspon to som bol schopny desifrovat zo zdrojakov, po cinsky neviem) postavena nad NuttX. Nutne dodat, ze principialne o 20 rokov modernejsia nez cokolvek, co dokazu peniaze kupit v nemecku.
V Nemecku z toho mali minuly rok vsetci vlhke nohavicky ked cinania oznamili, ze HaloOS open-sourcuju. To nadsenie dost rychlo opadlo, ked sa zistilo ze je to vlastne len Autosar done right.
edit: Teda, Autosar Classic je len jeden z payloadov, co na HaloOS moze bezat. Podstatne je, ze ta moznost existuje.
12. 6. 2026, 09:54 editováno autorem komentáře
