Vlákno názorů k článku Operační systém NuttX: programování s RTOS na embedded zařízeních od MiMar - NuttX již nějakou dobu sleduji, pro hafo aplikací...
-
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.
ČLÁNKY DO MAILU