Jaký RTOS na MCU, žádný, máme, vyžadujeme Arduino

26.2. 09:25 | Přečteno: 1359× | procesory a roboti | poslední úprava: 28.2. 08:44

V zásadě takto by se dala v krátkosti shrnout investice mého času (Jaký systém, RTOS, HAL, atd... volit pro menší MCU) do diskuze a i návrhu komunitě k rozvoji využití procesorů v zájmových i poloprofesionálních aktivitách, kde jsem nabízel své znalosti a naše příspěvky.

Uběhly dva roky, my stále pracujeme a přispíváme do NuttiXu, firmy jako NXP, Nordic, Espressif a další pochopily past a nekoncepčnost FreeRTOS a jejich často také obludná IDE převádí na Zephyr.

Je tedy na čase i té zdá se zde komunitní většině vyžadující Arduino a i od schopných HW a SW návrhářů jeho podporu znovu nabídnou zrcadlo, jaká je reálná situace.

Před nedávnem na ABClinuxu vyšla zprávička s odkazem na Arduino Open Source Report 2024 od správců Arduiono ekosystému a tak jsem k ní přřidal pár poznámek s vysvětlením reality (proč volí Zephir, proč to již není AVR ATmega).

Jinak nyní řeším jaký RTOS pro STM32H723VGT, kde je potřeba i solidní TCP/IP stack a situace ideální v malých RTOS stále není, velké firmy sice většinou nabízely fork LwIP, ale většinou v nějaké hrozné verzi zaintegrovaný do ještě děsivějších IDE s FreeRTOS. Postupně to snad bude ten Zephir. Sám určitě porovnám i na této platformě stav NuttXu, TCP/IP stack má z uIP původně od stejného autora jako LwIP, ale vyvíjí si ho vlastním směrem a posun vpřed je veliký, ale stále je tam co zlepšovat. Ale vzhledem k tomu, že společnost, která s která mě obrátila uvažuji časem i o využití platformy ve letových, tedy Space, aplikacích, tak by jim vyhovoval RTEMS. Jenže ten na větších systémech přešel od minimalizovaného a zastaralého forku BSD stacku na integraci aktuálního BSD stacku, kde je můj odhad, že rozumně bude chodit tak od 8 MB.

Na 1 GB RTEMS + libBSD na našich MZ_APO kitech na Zynqu chodí nádherně a latence i dalších služeb jako je náš CAN FD subsystém jsou o třídy lepší než na RT_PREEMPT GNU/Linuxu. I když i ten se pěkně posunul do mainline. Předpokládám, že podobně to bude vypadat i na PolarFire, který je i letový za 100 k EUR, zatím si s ním pod Linuxem a RTEMSem hraji na BeagleV-Fire za 150 EUR. Zde jak na něm vyvíjet RTEMS tak, že si jeho build aplikací natahuje deska přes TFTP.

Jenže libBSD je no go na tom STM32 s 564 kB RAM. Již před lety jsme pro RTEMS navrhl použít na malé MCU LwIP, viz třeba diplomová práce Přemysa Houdka a související GSoC. Podpora čipu TMS570LE3137 BSP byla integrovaná a nyní se nad ní objevují commity Embedded Brains a Airbus Space and Defense USA. Náš proof of concept pokus s LwIP také RTEMS core vývojáři zahrnuli do jimi udržovaných balíčků. Ale i podle mého původního plánu tam zbývá mnoho práce a když se portují spodní části driverů pro LwIP od nabídky těch FreeRTOS zrůdiček od výrobců čipů, tak se ukazuje, že je to také jen kód pro PR.

Je tedy otázka, jestli zkusit na STM Zephyr, TheradX, nebo ještě něco jiného. Sám nějaké porovnání, kde bude určitě zahrnutý NuttX a pak i něco dalšího provedu a možná mi zbyde čas a motivace i o výsledcích něco napsat. Rád spojím síly s dalšími a budu rád za nějaké reálné zkušenosti. V diplomové práci Olivera Šitaje jsem našel porovnání LwIP a Zephyr stacku, vzhladem k tomu, že předpokládám, že je členem brněnského NXP teamu nebo si to někdo z něj zadal, tak by to mohla být práce vedená seriózně (porovnání je pro imxRT 1170).

Závěrem, pokud máte zájem se něco přiučit, tak nyní sjednáváme Google Summer of Code projekty jak v rámci NuttX tak RTEMS komunity. Tak pokud máte zájem, tak se ozvěte.

Na blogy zde jsem nějak poslední roky měl méně času, ale když tak pár aktualit naleznete na https://social.kernel.org/ppisa přes který se spojuji i s komunitou po světě. Například přes hvězdičku na reportu o mé přednášce, jsem se dostal k člověku z Microchipu, který psal podporu U-bootu a v kernelu pro PolarFire a jeho rada přispěla k tomu, že jsem našel cestu pro ten TFTP boot RTEMSu.

       

Komentáře

[rad]

V tom minulém, dva roky starém příspěvku se vám někteří diskutující včetně mě snažili vysvětlit co to Arduino vlastně je. Přestože jste v této věci odborník (nebo možná právě proto) prokázal jste vůči této snaze obdivuhodnou odolnost.

Současně jsem se Vás tázal, existuje-li k Arduinu alternativa (která by splňovala všechna Vaše vysoká očekávání) s obdobně nízkou vstupní bariérou. Tenkrát jste nic nenabídl, změnilo se něco za ty dva roky?

Na závěr jsem Vám položil rétorickou otázku: "Raketoplán byste tím řídit nechtěl?" Tak už je to tady.

Můžete se třeba pokusit sepsat ucelený návod jak ve Vámi preferovaném prostředí vypadá vývoj nějakého elementárního projektu (aka rozblikání diody apod.). Od instalace všech nástrojů přes samotný vývoj až po flashování a běh. Myslím, že by to bylo užitečnější, než Vaše nářky nad tím, že někdo používá nástroj který Vám nevyhovuje.

Mimochodem sám jsem několikrát uvažoval, že bych Arduino ekosystém opustil, ale kdykoli si otevřu příslušné dokumentace Vámi zmíněných alternativ řeknu si "Ne, to mi za to nestojí."

[Pavel Píša]

Také jsem nepopíral, že to není úplně jednoduché a souhlasím s tím, že úplní začátečníci s tím moc neudělají. Ale právě ti trochu schopnější by jim mohli pomoci hledat cesty.

Návody pro Zephir, NuttX a další existují.

Když se do mě opíráte a ptáte se, co jsem udělal, tak si zkuste pustit náš příspěvek z loňských LinuxDays Levné řízení motorů a robůtků s RISC-V procesory Espressif a systémem NuttX. Jsou v něm i informace o těch zajímavějších věcech, FPGA s open source YosysHW na levném ICE-V atd... Ale zároveň dokumentuje jak jsme připravili prostředí s NuttXem na kterém jsme odučili kurz Microcomputer engineering with space applications, kde většina studentů byla bez jakékoliv předchozí znalosti práce s mikroprocesory a mnoho z nich i z mého pohledu němělo zájem a ani moc nadaní nebyli, naopak několi opravdu do programu SpaceMaster.eu patřilo a těm se kurz velmi líbil. Přesto všechny skupiny robůtka rozjeli, navrhli aplikace od sledování čáry přes další hrátky s vyhýbáním se překážek atd. Měli jsme pro ně připravenou konfiguraci NuttXu na ESP32C6, bohužel tamní IT nebylo schopné nástroje za tři měsíce od požadavku na počítače v laboratoři nainstalovat, tak si to všechno museli instalovat na své počítače, atd... Přesto to šlo.

Na druhou strany své aplikace napsali metodou copy paste a úprav příkladů v C a přesto, že v nám zadaném sylabu, který jsme se pokoušeli naplnit, bylo, že i absolventi budou umět číst v datasheetech a navrhovat vlastní fligh computers, tak nikdo nějaký driver nebo něco, co by třeba šlo vrátit i do NuttXu nenaprogramoval. Vystačili si s tím, co bylo.

Jeden náš kolega si ale pro rekreaci kit také půjčil a esp32c6: PCNT Quadrature Encoder drive. nastavení v registrech by napřímo, bez integrace s Espressif HALem bylo na tak dvacet řádek, takže jsem to původně chtěl pro studenty... Ale měli rezistenci, jako Vy. nevadí, teď je možné číst polohu přes device a právě při výběru motorků jsem volil takové, aby s nimi šlo předvést i něco zajímavějšího. Ale je možné, že budete preferovat nějaký hrozný bastl na GPIO pro Arduino, kde budete vždy chvíli měřit rychlost v blokující smyčce, protože to je na Arduino.

Jinak pro úplné začátečníky se mi nakonec uznávám i grafické programování, a líbí semi třeba i https://microblocks.fun/. Té odkazované diskuzi pod Arduinem jsem přidal i odkazy na jejich preznetace z FOSDEMu, ale to jste asi nečetl, když mi zde vyčítáte, že nic nenabízím. Jinak ano, jsou zatím nad Arduinem, ale to stejně bude Zephyr a sám jsme otestoval, že základ, https://bitbucket.org/john_maloney/smallvm/ přeložím i na NuttX, takže bych měl zájem touto cestou nabídnout takové prostředí i pro desítky nebo možná i přes stovku desek podporovaných NuttXem. Sám jsem na tom s časem všelijak, ale ty koncepční věci zkouším nějak dát dohromady. Na druhou stranu na dopsání dokumentace a mapování driverů, ADC, timerů, PWM třeba do toho smallvm je obrovské množství práce, které by zvládli i začátečníci, když se jim ta cesta ukáže. Jenže jak ukazujete, tak to asi nepůjde.

Jinak pokud si přinesete třeba na InstallFest některou z NuttXem podporovaných destiček a hostitelský počítač s GNU/Linuxem nebo WSL, tak můžeme NuttX na tu desku "nainstalovat". Nebo si můžete půjčit jednu z těch sad s kolečky a ESP32C6, vybírali jsme to tak, aby HW z LáskaKitu bylo levné. Přitom motory s opravdovými enkodéry na ose motorku nám sehnali a začali nabízet na naše doporučení.

Na InstalLfestu jsem již takto NuttX a další nabízel mockrát, ale ono většina dnes již přichází jen jako konzumenti za zábavou a nebo jsou již zapojení do projektů a InstallFest je pro ně spíš akce jak se potkat s dalšími... Ale pokud bude zájem, tak dva worskhopy jsem navrhl a v rámci jednoho jsem i na takovéto seznamování myslel.

[rad]

Já se Vás neptal na to co děláte, popravdě mě to ani nezajímá. Já se pouze dotazoval – když už ten projekt opakovaně haníte – jestli existuje k Arduinu nějaká alternativa s podobně nízkou vstupní bariérou. Taková, kde můžu psát v C/C++, mám k dispozici nějaké vývojové prostředí včetně všech potřebných nástrojů, knihovny pro práci se standardními periferiemi apod. MicroBlocks za takovou alternativu nepovažuji, to snad chápete. Není třeba psát sáhodlouhé elaboráty mimo téma.

[Pavel Píša]

A já vám odpověděl, že jsme to s NuttXem zvládli s nepoučenými studenty, ale souhlasím, že to bylo s vedením a že tedy chybí ty návody atd. To co jsme přirpavili, Vám klidně pošlu, když řeknete kam, nebo to někam přidám, ale ano, není to pro samostatné použití bez vedení v tak přímočaré podobě jako Arduino. Můžete si vzít Espressif IDF nebo jejich prostředí na NuttX, nějak to integrované mají, ale mě zase ty jejich forky nezajímají. Jinak ano, mimo svých projektů i trochu ze spíše záporného času, který mi zbývá věnuji tomu, abych co lze zpřístupnil.Mnoha lidem kolem mě, kteří mají zájem to stačí a chytnou se.

https://github.com/robertobucher/pysimCoder s NuttXem začal sám používat strojař ve svých dodávkách na americké univerzity (videa).

Vzít si NuttX a doprogramovat si do jeho APP další příkaz je snadné...

Zde je kanál s NuttX videi a půjde na něm nalézt i úplné začátky.

Ale ano, potřebovalo by to někoho, kdo třeba v češtině připraví nějaký pěkný úvod a zpopularizuje to.

[rad]

Stačilo napsat, že není. I tak děkuji.

[trekker.dk]

Návody pro Zephir, NuttX a další existují.

A stojí za nemnoho.

Zkuste na webu hledat nuttx tutorial. Najde vám to nějaká osm let stará videa (naprosto nevhodný formát pro tento druh obsahu) a odkazy na quickstart v dokumentaci NuttX. V dokumentaci najdete, jak to stáhnout, jak nainstalovat závislosti a... nic. Návod pro cmake nefunguje (vyžaduje instalaci dodatečného balíku, po nainstalování toho balíku stejná chyba.) Dobrá, zkusíme make, to prošlo. Dál to chce docela dost procházení toho webu, kde najdete nenápadný odkaz Guides, kde po dlouhém scrollování najdete "Custom Apps How-to". Tím se prokoušete, uděláte program, přeložíte, spustíte, dostanete NSH. Jak spustit přímo ten program bez shellu, těžko říct. Každopádně po absolvování quickstart nejste ani o kousek blíž k tomu to prakticky použít.

Se Zephyrem to bylo lepší, tam jsem svedl čtyřhodinový boj ve snaze vyhnout se jejich SDK (obsahuje asi tak všechen software v celém vesmíru, přičemž to, co potřebuju, už mám stažené z archivů své distribuce), ale nakonec se nějak povedlo dopracovat k tomu, že jsem spustil program a ten něco dělal.

Hledání zephyr tutorial pak najde docela pěkný úvod do problematiky - nic rozsáhlého, ale aspoň to obsahuje základní koncepty. Upřímně řečeno se mi filozoficky NuttX líbí víc - nenutí mě stahovat hromadu software kdovíodkud. Což mi naznačuje, že to není žádná rychlokvaška slepená z čehokoliv, jen aby to fungovalo. Ale v tuhle chvíli ten projekt považuju za software pro vyvolené, kteří už ví, jak se s tím pracuje. A nebo je to někdo naučí.

(Možná námět pro seminární práci? Žádný převratný výsledek, ale schopnost učit je taky přijatelná dovednost, kterou si student může odnést.)

[Pavel Píša]

Tak děkuji za otestování a gratuluji k prvnímu kroku. Sám ho hodnotím jako úspěšný.

Ano souhlasím, že právě v té začátečnické oblasti jsou v dokumentaci mezery a především evangelisté, které těší začátečníkům pomáhat, jsou tou historií a společností zatlačení k Arduinu.

Ale pokus se Vám podařilo dostat na NSH prompt, tak jste připravený začít vyvíjet.

V "make qconfig" nebo "make menuconfig" si najdete symbol "EXAMPLES_HELLO", ho v "Application Configuration", "Examples", "Hello World".

Z command line NSH pak mohu pustit "hello" jako příkaz.

Jeho zdroj mám v apps/examples/hello a mohu si ho modifikovat. Přitom se nepotřebuji učit nový model threadů, networkingu atd. Mohu si věci otestovat na GNU/Linuxu a většina mi půjde. V apps/examples najdu utilitky pro otestování většiny funkcí rozličného HW (ADC, sítě, ledky atd.) bez nutnosti se učit rozdíly mezi platformami. Když má platforma nakonfigurované ETC_ROMFS a ETC_ROMFSMOUNTPT atd, tak si přidám do /etc/init.d/rcS co chci nastartovat po spuštění, když to bude s appersandem, tak nepřicházím o shell promt a z něj mohu sledovat, co moje aplikace dělá, kontrolovat stav procesů atd... To etc lze povolit u všech platforem...

Pokud chci opravdu jen tu jednu aplikaci bez možnosti shellu, tak změním INIT_ENTRYPOINT="nsh_main" na třeba ten "hello_main". Když se mi aplikace trošku rzroste, tak si ten hello zkopíruji do jiného adresáře, hello v gitu zresetuji a svůj fork nutt-apps si někam uložím...

když budu mít větší projekt, jako je třeba PX4 autopilot https://px4.io/ tak při buildu NuttXu udělám make export a mám základ ve stylu systémové knihovny a linkkitu, proti kterému builduji aplikace v podstatě stejně jako na GNU/Linuxu. Takto to dělám s rozsáhlými projekty, kde mám build systém, kde builduji pro vlastní, ale na rozdíl od Arduina přenosielnější abrakci system-less (ale v jedné osobě je seznam cílů omezený a návody nula), na GNU/Linux, RTEMS, NuttX a něco i na Windows.

Třeba motion control knihovna PXMC https://www.pxmc.org/ je takto využívaná všude. Viz můj příspevěk i k diskuzi o přidání podpory pro motion control do jádra Linuxu zde.

Jinak ano, na NuttXu je těžké pro desku a její nasazení připravit tu správnou konfiguraci a to především právě proto, že je maximálně konfigurovatelný, aby ho šlo pustit i na systémech s 32 kB RAM i tam, kde se využije plný networking atd...

Ale lze to připravit tak, aby se vše uživateli nastavilo naráz a měl kompletní firmware.

Zkuste třeba

git clone https://gitlab.com/pikron/projects/imxrt-devel.git cd imxrt-devel git submodule update --init cd nuttx make

je to nad již starší verzí NuttXu, ale asi stačí jen update submodulu. A máte firmware pro náš https://gitlab.com/pikron/projects/imxrt-devel/-/wikis/teensy_bb. Podobně to nyní připravuji pro SaMoCon.

Úplně stejně a velkým reuse i našich zdrojových modulů a aplikací zkompilujete risc-v-esp32/ice-v-pmsm. Zde je ale v prerekvizitách instalace YosysHQ pro build designu PMSM periferií do FPGA. Ten Yosys s GHDL pluginen je zatím trochu magie. Ale třeba to bude za nedlouho celé v distribucích. Když v tom projektu dáte jen "make sw" tak stačí mít jen ESP tooly a příslušný GCC RISC-V kompilátor.

Export NuttX buildu pak lze požít i pro grafický návrh řídících aplikací v pysimCoder.

Ale jinak gratuluji k té nejtěžší části, která se liší podle HW. Na druhou stranu hodně platforem má celkem dobrou startovací NuttX dokumentaci.

A trochu s rozmyslem napsaná aplikace Vám již poběží všude, kde se potřebné periferie podaří nakonfigurovat. Pokdu něco málo nebo speciálního chybí, tak si drivery dopíšeme, je je možné mít i ve vlastním projektu a registrovat, ale v zásadě na všem se dokážeme dohodnout, že to jde do mainline. Ale NuttX ne jen že umí registraci driverů zalinkovaných do image s aplikací, ale při povolení i jejich runtime dynamické nahrávání třeba přes síť.

Připadá Vám to již takto zajímavější a je tam opravdu ten vstup tak těžký?

Když Vám pro danou desku přirpavím ten to level make, tak začnete okamžitě, na každé to Arduino kompatible to také někdo musel připravit. takže když si komunita vybere nějaké vstupní platformy, za mě třeba ESP32C6 nebo nějaký STM či SAM či to Teensy 4.1 kde mohou snadno přejít přes Arduino na NuttX, tak to vidím jako snadné...

Jinak těší mě, že se od toho zarytého tvrzení některých,že nemám obtěžovat, dostáváme k tomu, že se zkouší, kde pro začátečníka jsou s mojí nabídkou problémy.

Na které platformě jste NuttX zkusil Vy?

[trekker.dk]

Díky za informace, i když se musím přiznat, že s dalším vyvíjením jsem zatím žádné plány neměl - jenom jsem se chtěl přesvědčit, že se situace od posledně nezměnila, abych NuttX nekritizoval za něco, co (už) není pravda.

Jinak upřesním, že ke kroku s překladem vlastní aplikace jsem se dostal taky, to bylo v předchozím příspěvku zmíněno tím, že se najde nenápadný odkaz "Guides", kde už bylo k nalezení, jak toho docílit (nechtělo se mi už hledat, jak nějakou takovou aplikaci napsat, tak jsem jako svoji aplikaci použil zdrojové kódy právě toho hello.)

Oním textem jsem chtěl spíš naznačit to, že jak zajistit spuštění aplikace bez NSH je další informace, která je před potenciálním vývojářem skryta tak dobře, že Google na dotaz "jak v nuttx spustit aplikaci bez NSH" nachází článek o tom, jak používat NSH. To Vámi zmíněné INIT_ENTRYPOINT (děkuji, znamenám si, odhadoval jsem, že bude stačit hledat "init" v menuconfig, ale už jsem tomu nechtěl věnovat víc času) je - když víte, že máte do Google zadat INIT_ENTRYPOINT - k nalezení v článku "Customizing NSH Initialization"

Připadá Vám to již takto zajímavější a je tam opravdu ten vstup tak těžký?

Zajímavé to je, ale co se obtížnosti vstupu týče... popsal jste spoustu zajímavého software člověku, který zatím z dokumentace nevyčetl, co napsat za #include, aby aplikace to jádro vůbec mohla použít. Vstupní bariéra je prostě někde jinde, než na jaké úrovni se v této debatě pohybujeme

Na které platformě jste NuttX zkusil Vy?

Risc-V Qemu. Pro NuttX ani nemám podporovaný hardware.

[zemingr]

V první části Vašeho příspěvku jste přesně trefil to, co si myslím že spoustu zájemců po prvním vyzkoušení NuttX odradí. Dokumentace je poměrně roztříštěná a nekonzistentní a samotná učící se křivka je oproti Arduinu velmi pozvolná. Na Youtube je sice NuttX kanál (dají se dohledat i příspěvky pana Lence) ale spíše by to chtělo vydat článek třeba tady na ABClinuxu a v něm se podělit o zkušenosti s Nuttx a přenést tak případné zájemce přes tu první bariéru která je mnohdy odradí.

Jinak Vaše příspěvky k NuttX sleduji a fandím Vám.

[vlastikroot]

Provozuju FreeRTOS/Lwip/C++ na SAME70 s vlastnim forkem Atmel Software Package. Ono to je opravdu dobra a funkcni kombinace, jen je potreba udrzovat cistotu kodu a nepouzivat zadny code generatory/IDE atd. Proste to delat klasicky jako se udrzujou normalni software projekty, aby to nebyla jen kupa polofunkcnich abstrakci nejak generatorem slepenych dohromady. Ono totiz s poradanym kvalitnim kodem se potreba generovani kodu ztraci. Setkal jsem se treba s tim, ze implementace ethernet driveru nebyla psana s tim, ze bude provozovana uvnitr threadu v FreeRTOS, takze to bylo nejak dopraseny jen aby prosel zakladni example, ale jinak absolutne nepouzitelny.

[Pavel Píša]

Děkujiz a informaci, celkem by mě zajímal ten low level driver pro LwIP pro SAMv7. Sice v Elektroline to vidím dlouhodobě na NuttX, ale Embedded Brains nainvestovali do SAMv7 pro RTEMS, pak sice museli odejít kvůli nesnášelivosti USB a SDRAM, ale podpora v mainline je a zkusit na tom LwIP by mohlo mít smysl. Máte někde SW v GITu a teď ještě jestli je veškerý kód pod licencí s RTEMSesm kompatibilní, tedy čistá BSD. Jinak sám bych teď potřebovalý dobře fungující LwIP pro STM, ne sysless ale nad tasky, které by šlo otestovat na RTEMSu .

Jinak věřím, že se FreeRTOS jako plánovač použít dá, ale předpokládám, že drivery si píšete na HW sám, ADC, PWM atd... a tam je potíž, že pokud byste chtěl stejným SW pokrýt více rozdílných rodin a architektur, tak budete muset vše směrem k HW psát znova téměř z nuly. NuttX má výhodu, že nabízí API pro IRC, ADC, DAC, PWM atd... na druhou stranu je pravda, že to společné API je jen subset a opravdu vytáhnout za HW maximum přes něj nelze. Ale třeba pysimCoder stejnými bloky pokrývá bez řádky změny tyto periferie na SAMv7, STM i Expressifu. Pokud je potřeba jít k HW v nějaké specialitě blíže, tak v klasickém režimu bez MMU je možné na HW jít přímo z aplikace. Na druhou stranu nám se daří domluvit mnoho věcí tak že přidáme nebo rozšíříme API a postupně se přes komunitu rozšíří i na další architektury a tak máme cestu i na přechod jinam otevřenou.

Další problém je, pokud na FreeRTOSu potřebujete FAT nebo dokonce nějaké pokročilejší filesystémy. Znamená si to vlastně VFS postavit vlastní. Opět výhoda RTEMS, NuttXu atd. je, že nějaké VFS má a má ho přes všechny architektury stejné... Ale ano, dokonalé není a obecně u každého SW lze narazit na chyby. Ale výhoda open-source je, že se celkem rychle dají řešit takže v zásadě větší nebo dlouhodobější forky u NuttXu vůbec nemáme... Ale ano "/dev" rozhrabaní má proti přímému přístupu k HW overhead jak v rychlosti tak ve velikosti firmware...

[vlastikroot]

Bohuzel kod neni verejny, ale neni to vlastne nic specialniho. Drivery si pisu sam, snazim se v nich co nejvic vyuzivat API poskytovany z RTOS - problem tich OS-less driveru je ze maji svoje systemy na callbacky, interrupt handlery, timery ... Takze udelam thread safe driver pomoci front na I/O, interrupty nejakym zpusobem premenim na notify v RTOS (neco jako xSemaphoreGiveFromISR), callbacky do user kodu to samy.

[RealJ]

Mas muj obdiv! Mas nejake plany delat svuj vyvoj komercne (mit firmu a resit konkretni projekty)?

[vlastikroot]

Jedna se o komercni zarizeni. Zesilovac a GUI je rizeny AVR Xmega s FreeRTOS/C++ a diagnostika/ethernet je SAME70 s FreeRTOS/LWIP/C++. K tomu je multiplatformni Qt aplikace.

[RealJ]

zajimave, diky!

[X]

Trochu jsem to nepochopil. Zamerujes se na RTOS systemy. Dobre, ale to Arduino s tim souvisi jak?

[Pavel Píša]

Základní zájem je programovat aplikace pro embedded HW, mikrokontroléry. A to jak za sebe pro ty střední a větší aplikace, kde nějakou předtsavu za těch 35 let mám, tak mě zajímá jak se postupně od jednoduchých aplikací dostanou zájemci k těm složitějším.

U opravdu jednoduchých aplikací jde vystačit s main/busy smyčkou, s tímto konceptem a přidáním stavových automatů a přerušení se lze dostat i velmi daleko. Máme takto implementované rozsáhlé aplikace s GUI, TCP/IP atd... Ale na druhou stranu vím jak je to náročné a na čas dnes již neefektivní. Stav uložený ve vláknech, preemptivně plánovaných úlohách na to vyjde stanději. Ale před těmi 30 lety s 8051 to spíš s vlákny takto nešlo. Zároveň vím, jak špatně se programuje na procesoru, který má ještě více než harwardská architektura roztříštěné adresní prostory, CODE DATA, IDATA, XDATA...

Přitom sleduji, jak jsou i různými populárními texty a tlakem komunity začátečníkům doporučovaná Arduina. Jak jsem popsal, používat AVR byl to anachronizmus již před 15, 20 lety, vidím ty problémy v kompilátorech a obcházení špatného návrhu. Sám nemá nic pro 16 MCU, jako je MSP430, ale AVR byl pokus zlepšit 8051, ale obecně tam těch chyb zbylo mnoho, přitom to vychvalované IDE nemělo ani ladění a snaží se lidi uvázat k systému tak aby něvěděli, že mohou rovnou psát v C nebo C++. Na druhou stranu se sadou rozumných abstrakcí a příkladů do začátku souhlasím. Ale jak i jiní potvrzují, často se jedná o hodně zprazený kód. Včera jsem pomáhal lidem s Teensy 4.1 kde trvají an Arduinu a chtějí řešit složitější řízení několika motorů přes CAN FD. To do čeho jsem zabředával, se mi opravdu nelíbilo a stejně se neposunou dále než k té busysmyčce na HW, který zvládá RTOS a na NuttXy se přihlásím na terminál, zapnu logování do syslogu z CAN nebo jiného subsystému atd. V Arduinu, kde je ještě speciálně, aby si nebylo možné Teensy okopírovat a mělo loader přes USB do toho špatného IDE, tak je na desce navíc další MCU, které blokuje SWD, tak jsme se vraceli k ladění z doby koně.

Nevím, jestli to dokážete pochopit, ale sám vidím jak jsou ti studneti a lidi zkažení tím, že berou Arduno jako grál a nikdy nezkusili něco sami a nebo v trochu logičtějším prostředí. Takto se nikdy nenaučí myslet a navrhovat něco systematicky.

Přitom pak chtějí IoT, embedded Web a pro tu kouli na noze se do řeší dalšími kuriozitami, v příadě AVR těmi 100x výkonnějšími shieldy s pořádným CPU, které jsou ale komerční a nedovolí jim to lepší MCU programovat. Přitom to silnější MCU by jim umožnilo vše co chtějí a neřešili by ty hrůzy s tím, že jim chybí místo na dva řetězce, které se ještě pro archaické AVR musí vykopírovat do té maličké RAM aby byly ve správném adresním prostoru pro funkci, která je má vyslat dále.

Je to prostě k pláči a já bych rád, aby ti lidé rostli a třeba se časem zapojili i do vývoje něčeho trvalejšího na čem lze stavět a ti, kteří to mysl vážněji i staví. Ale ta sebestřednost Arduinistů vytváří často bublinu, ze které mnoho nevystoupí a pak řeší Arduinem krkolomně věci kam nepatří a pak ještě chtějí, abych jim radil atd...

Přitom i ti originální autoři Arduina vědí, že to nemá s AVR budoucnost, tak přejdou na ARM ale Arduinem ho zvážou asi tak jako když na Intel 80486 s 16 MB RAM provozujete DOS s DPMI a každý serioznější hráč (Borland, Watcom, ...) platí a nechával v 90 letech všechny své uživatele platit Microsoftu a musí si napsat vlastní, zavřený DPMI extender a utratí na to strašného času. Kdyby se nedrželi toho hrozného standardu (DOS), tak za ten čas mohli napsat několik pěkných Unixů stejně jako Linus a nebo dohromady být o 10 let napřed třeba s IO-uring roce 1000. Dívat se na ten stav a klec Arduina, je jako sledovat tyto chudáky a mít na té 80486 rozumně funkční Linux (což jsem již okolo roku 1994 měl) ale na druhou stranu vím, že bez té komunity to dále nepůjde.

Myslím, že trochu dopředu vidím, v té době když jsem si s CANem a Linuxem hrál, tak se mi z Unicotrols a od jinud smáli, že jsme banda na hlavu padlých hakříků. Projekt na GNU/Linux se školou šéfové firmy vzali spíš hlavně jako cestu jak se dostat k lidem a zlpeit si z evropských pěněz cash-flow. Ale zavřený OS-9 jim najednou přestal PEP podporovat a během těch tří let projektu i se střední a vyšší vrstvou řízení Trasgasu, RegioJet motoráků atd. přešli na GNU/Linux.

Jak ukazuji na té situaci Arduina a snaze nějak přecházet na ARM a prasit to nad mbedOS, který jsem již před lety považoval za horší volbu, a nyní útěku k Zehyru, tak přesně dávají za pravdu mému pohledu na AVR Arduino před minimálně 15 lety. Kdy již byl zastaralý nesmysl.

Přitom pokud se prohlašují za IoT, tak tam potřebují složitější protokoly, MTTQ, sítě, CAN a psaní bez RTOS je mnohem mnohem náročnější a často také nevede k pěkným konstrukcím, znám ze svého. Takže stějně RTOS budou mít, Ale snaží se to lidem neukázat, aby se nenaučili ho používat přímo a nezjistili, že jejich bastl nepotřebují...

Ale je dost možné, že to, co vidím jako potřebu sdělit a ušetřit lidem investice do slepých cest a třeba i některé z nich získat vychovat pro spolupráci a rychlejší cesty i k praktickým cílům, není pro mnoho lidí předatelné.

A vlastně si mohu říct, že mi na nich nezáleží, protože komunitu jak těch několika schopných studentů, kteří se ke mě přidají, tak tu velkou, RTEMS, Linux, NuttX mám.

Nic, půjdu řešit zadání pro GSoC na NuttX a nebo třeba lechce ovlivním směřováí motion control v mainline Linuxu, které tam někdo poslal. Poslal jmes mu nabídku, co by šlo využít z našeho.

Třeba až za 10 let budete používat nějaký systém, o kterém také zase nebudete chtít vědět více, tak Vám ty mé vize budou sloužit. Jako třeba slouží každému, kdo se připojuje přes SocketCAN do automotive nebo jiné sítě, v jejím nastavení, nebo příspěvky, které jsem podnítil pro RTEMS třeba i ve space misích atd...

[X]

Myslim, ze se na tom aktualne neda moc zmenit. ALE, neni ani duvod. Aduino je vyukova platforma "na hrani". Vubec nemam prehled kolik realnych projektu stavi na Arduino, ale ta pointa je uplne jinde. Arduinu, se jako prvnimu podarilo prilakat do oboru obrovske mnozstvi nadsenych lidi a je uplne jedno, ze se od nej nekdo nedokaze odpoutat. Jestli jen 5% prejde na skutecny RTOS je porad dobre, nebo ne? Mozna bojujete proti necemu co Vam vlastne pomaha..

[X]

Mimochodem ted bezi na rootu clanek o programovani na RPI2040. Tady by se prece dalo polemizovat uplne stejne, ze RPi je "spatna" cesta a kdo to pouziva na produkci je lamer. Pointa je naprosto stejna jako predchozi.

[Pavel Píša]

Pico 1 se nelíbilo, chápal jsem kompromisy, tedy Flash mimo čip, kdy cena je daná použitím pokročilé technologie křemíku pro velké SoC a tím nabízí extrémně velké počty těchto drobotinek z jednoho waferu, stejně tak jako volbu Cortex M0+ z důvodu ceny licence (myslím že zdarma) od ARMu. Ale byl to slepenec s děličkou mimo atd... Takže to kazilo GCC kompilátor, knihovny atd... Myslím, že již tehdy šlo volit nějaký otevřený RISC-V.

Pico 2 se podle mě, co se týče jádra, povedlo, Cortex M33 je solidní volba, na kterou jsou k dispozici jak kompilátory tak vývojová prostředí, knihovny atd... Sám bych ho bral i jen s tím RISC-V HAZARD3, který ale beru spíš jako vypuštěnou vlaštovku pro nadšence, ale obecně Pico 2 beru jako dobrý startovací čip se zajímavými periferiemi.

A ano, doporučuji číst katalogové listy, pokud někdo má zájem použít tento HW i na průmyslové a prostředím, teplotou zatížené a kritické aplikace. Ale určitě se i na Pico lze naučit rozumnému přístupu k programování embedded řešení.

Myslí, že si tedy pořád nerozumíme, mám zájem, aby lidi získávali znalosti a ne aby sami a i ty schopnější nenutili používat DOS a nedělali z DPMI berliček standard a nezabetonovávali je, když je tady Linux nebo třeba i na PC možnost psát rovnou 32-bitové a 64-bitové low level aplikace jako pluginy do U-bootu nebo GRUBu. I to je mnohem lepší, než se zabetonovat na DOSovém Int 21 a Borland BGI Diverech (myslím, ani Vy byste dnes BGI drivery lidem nevnucoval jako ideální cestu), a to je podle mě ekvivalent Arduino v dnešní době. Přitom tlak nutí tvůrce přidávat to DPMI, Trumpet Winsock ve stylu Windows 2.0 atd.

Přitom je jěště kurióznější, že ti, kteří vás nutí do toho BGI, tak ho nakonec staví v emulátoru QEMU (tedy v embedOS nebo těď Zephiru), protože sami ví, že ten původní koncept je s požadavky na současné komunikace neudržitelný. Ale mnoho lidí jim za tu kle tleská a prohlašuje a píše knihy, že to je ta správná cesta.

Oběcně, třeba časem dospějete k podobnému názoru, třeba se Arduino nějak transformuje, že to bude měnší zlo a třeba i mě přesvědčíte. Ale zatím se na to dívám takto a považuji za velkou škodu že se na tom ztrácí čas, když by se mohl investovat do nějakého společného základu. Viz i odpověď Vlastikroot, vynalézáme kolo, ale podělit se o výsledky pro lepší řešení třeba i pro nás do budoucna se nechceme/sám možná i chci ale nemohu. Srovnejte se Stalmanovým tvrdým odmítnutím v osmdesátých letech se šířícího přikázání "A nepomůžeš bližnímu svému" (https://pretalx.linuxdays.cz/linuxdays-2023/talk/WTNNLG/) a vzdor a přesání vlastního Emacu, který mu otrávili licenčním trojským koněm atd... Díky jeho licenci zde máme Linux, prohlížeče a další technologie, bez kterých by ani Apple ani Microsoft nemohli dnes systémy ani vzdáleně se blížící dnešní použitelnosti nabídnout.

[trekker.dk]

AVR byl to anachronizmus již před 15, 20 lety, vidím ty problémy v kompilátorech a obcházení špatného návrhu.

Hm, nejdříve pro úplnost, kdyby sem někdo zabloudil z Google. (Doufám, že mě paměť moc neklame.) Problémy v kompilátorech jsou dle předchozích diskuzí zejména to, že přístup do programové paměti je potřeba mít uvozený do funkce, která provede příslušné instrukce. A je také nutné používat klíčová slova při práci s ukazateli na programovou paměť. Tj. není možné používat pointery "jen tak".

No a teď se podíváme do zdrojových kódu NuttX jako nováček a jako jedna z prvních věcí na nás v deklaraci funkce vykoukne "FAR". Skoro to vypadá, jako by na tom NuttX nebyl o moc lépe...

se střední a vyšší vrstvou řízení Trasgasu, RegioJet motoráků atd. přešli na GNU/Linux.

Co prosím? Linux, pokud vím, nemá žádné certifikace ohledně bezpečnosti nebo jako RTOS, takže s tím, že by byl součástí řízení vlaku, to se mi moc nezdá. Pokud tedy nemáte na mysli nějaké displaye apod., to pak jo - v roli levného GUI ho takhle najdete i jinde.

[Pavel Píša]

Ano v NuttXu je to FAR právě jen k tomu aby jádro a omezená relevantní část driverů mohla běžet na tom Arduino AVR HW, kde souhlasíte, že je to anachronismuz. Ale NuttX se takto přizpůsobuje tomu, aby i na něm mohli jeho uživatelé růst z AVR dále a začít využívat koncepčnější přístup k programování. Ale určitě není snaha držet AVR přes shieldy pro TCP/IP, Bluetooth a WiFi.

Takže Vaše kritika je jen potvrzením ochoty NuttX komunity spolupracovat...

[trekker.dk]

No, jestli dobře čtu zdrojáky, tak to tam není (jenom) kvůli AVR. O tom, jestli je něco anachronismus, jsem nijak nesoudil. Prostě a jednoduše mi nějaké PROGMEM netrhá žíly natolik, abych to jakkoliv bral v potaz při posuzování platformy. (To už by mě spíš rozčilovalo, kdybych musel používat to FAR.)

[Pavel Píša]

OK, FAR tak je to tam stále kvůli SDCC a Zilog kompilátorům pro některé varianty Z80 (konkrétně pro __SDCC_z80 __SDCC_z180 __SDCC_gbz80 __ZNEO__ __EZ8__ __EZ80__). Ale na všech ostatních architekturách je to prázdná define a ve všem, co je mimo ten společný základ a není pro ty omezené architektury, tak se již do kódu driverů atd. ani to FAR nepíše. Ale souhlasím, že je to trochu otrava. Ale uživatel při psaní aplikací na soudné architektury to nikde do kódu psát nemusí.

[petr_p]

Nějaké snahy o certifikaci jsou, ale stejně z toho nakonec vyleze nesvobodný software, protože těžko můžete certifikovat věčně měnící se kód. Certifikované RTOS na tom se svobodností nejsou lépe.

[Pavel Píša]

U vlaku to byl infotainment a podobné obslužné funkce, kritické věci jako VTB gateway byly na PowerPC s vlastní infrastrukturou. Ale u toho Transgasu realizoval GNU/Linux síť velmi sofistikovaných vlastních soft PLC, opět na PowerPC a vyšší řízení na serverech. Vlastní lokální safety bylo na industrial PLC. Ale pokud si třeba koupíte PLC od Wago, nebo Tecomat, případně National Instruments tu jejich špičku (stejný HW jako naše Zynq based MZ_APO), tak tam určitě byl a myslím, že stále je hlavní systém Linuxové jádro.

GNU/Linux se také používá při řízení velkých jeřábů, TRUMP, ten s lasery a vysekávačkami, ho také používá, existuje i projekt SIL2 Linux, kde byla snaha právě vytvořit tu znovuvyužitelnou dokumentaci, když již předtím SIL2 aplikace byly schválené. Jetli je to nebo není dobře bez dalšího nezávislého kontrolního systému je na diskuzi a sami jsme infúzn pumpu raději navrhli před lety s RTEMSem a druhým kontrolním MCU bez RTOS. Ale drahá konkurence to měla postavené na jednom CPU a někdy externím watchdog obvodu...

Jinak RTEMS ve verzi 4.6 byl právě ten komerční firmou certifikovaný bastl, kde ta firma ani nekomunikovala s core vývojáři. Přitom v rámci core vývoje se vědělo kolik kritických chyb bylo opraveno v novějším mainline a zpět se nedostalo. Nyní si ESA nechala precertifikovat (vytvořit kvalifikační/certifikační dokumentaci) k subsetu RTEMS mainline. Ono stjně nakonec se certifikují až finální aplikace, jen ta precertifikace dává odklady a testování na kterém to lze postavit.

[...]

hanit Arduino, ale zabit to NuttiXem... to chce specialni typ nadutosti, co jde jenom v bezvyznamnych koncinach bez uzitku, jako na ceske akademicke pude (ktera jeste do ted zije z toho, ze umi sem tam prodat neco padlym hvezdam typu Cisco, lol)

jak je vubec mozne, ze v praxi tak moc vyresenou vec, jako presne rizeni krokacu, ma Pisa jako vec, na kterou dal sbira obdiv tady nikdo nema zadny standardy, uz jenom travit cas komunikaci s nekym na tahle temata v cestine proste nema budoucnost

vsak se na to tady podivejte

smutne

[Pavel Píša]

OK, pošlete odkazy na to, co nabízíte, třeba i komerčně. Jinak pokud používáte fitness náramky od Xiaomi a dalších nebo nějaká sluchátka od Sony, tak tam NuttX máte. Stejně tak ve velké části dronů (PX4 Autopilot) střednní kategorie. Jinak sám (zatím) nepovažuji NuttX za RTOS vhodný pro kritičtější průmyslové aplikace, ale pro ne až tak kritické oblasti je vhodný a právě je podle mě velmi dobrou startovací/cvičební volbou pro ty, kdo chtějí růst. Přechod a RTEMS, VxWorks, Zephyr, RT_PREEMT GNU/Linux atd je při získání systémového přístupu snadný.

Naopak jen v tuto chvíli kolem sebe mám jinými vedené tři skupiny studentů, kde řeší různá řízení motorů, krokových, PMSM s těch skvělými knihovnami na Arduino, pochopitělně ne na tom příslušném AVR základu a řízení neběží na tom z mého pohledu silném Arduino HW (600 MHz ARMy - sám jsem 3 DC motory se zpětnou vazbou na 1 kHz řídil z 8051 s předností/odchylkou v jednotkách inkrementů před více než 30 lety) ale přes kupované a vyráběné další komponenty a pomáhám jim řešit problémy v těch skvělých ARduino knihovnách. Je škoda, že je někdo nepřesvědčil dříve, že Arduino není dobrá volba... Takže ukazuji alternativy... Že o nich nechcete slyšet je Vaše volba.

Jinak sám právě vím i o těch nedostatcích mnoha menších RTOS, kdyby nabídli i jen setinu svého úsilí na spolupráci na vývoji přenostitelných a systematičtějších řešení ti, kteří ztrácí čas v Arduino ekosystému a nebo v psaní vlastních driver modelů nebo spíš obírání různých dostupných open projektů a HALů of firem opět na bázi tak přispůsobených projektů jako je LwIP a pak jejich uzavřených ekosystémů, tak by většina jejich cílových projektů byla jen tenká obálka nad tím společně vyvíjeným základem a měli by do budoucna zajištěné pokračování na další platformy, jak s vývojem technologie polovodičů vznikají a zanikají. Takto nutí třeba Microchip udržovat nerentabilní, 35 starou výrobní technologii na něco, co nemá budoucnost. Ano, core Arduino vývojáři jsou o něco málo rigidní a nepoučení něž někteří zdejší zarytí propagátoři, ale i tak si myslím, že jejich roky z mého pohledu špatná technická rozhodnutí (a dobrá marketingová, připomíná mi to v mnoha ohledech Microsoft a ten DOS a DPMI) jsou důvodem nebýt na nich závislý a minimálně se bavit o alternativách.

Jinak příspevek anonyma bez projektových referencí považuji za irelevantní a doporučuji ho takto brát i ostatním.

[X]

.. a pomáhám jim řešit problémy v těch skvělých ARduino knihovnách. Je škoda, že je někdo nepřesvědčil dříve, že Arduino není dobrá volba...

Zeptal jste se jich proc si vybrali zeovna Arduino? Proste smula, dira na trhu, kterou vyhral nekdo jiny nez by jste si asi pral. Chapu Vas povzdech, ale tak to proste chodi. Zase, lepsi 3 skupiny studentu, nez zadna..

[Pavel Píša]

Jinak ano, jednoduché a často problematické řízení krokových motorů s rozhraním signálů "step/microstep" a "dir" vypadá jednoduše. Pokud má být to proudové řízení na tisíc mikrokroků, aby se neprojevilo z natáčení antény na vědckém payloadu mise LISA tak to i bez zpětné vazby je o něco zajímavější úloha. Pokdu pak chcete krokový motor řídit s přesností, odchylkou jednotek inkrementů z čidla s rozlišením 40 tisíc poloh na otáčku s kombinací s lineárním pravítkem s rozlišením 10 um, tak je ta úloha zase někde jinde. Mů zájem je mít řešení a celou tuto škálu úloh.

A neb, řešení soustavy lineárních rovnic je zvládnuté již nějaké ta staletí, ale pokud je požadavek na rychlost nebo velikost, tak je tam stále mnoho prostoru na zrychlení, ono to není tak jednoduché, jakmile máte řídké matice atd... Stejně tak dnes vyzdvihované AI, základem jsou neuronové sítě a pro ty je potřeba maticové násobení, zdá se, že i tento v principu zcela triviální problém dnes zaměstnává celé firmy a univerzity při vývoji kombinací SW a HW, reprezentací datových typů i třea mimo IEEE-754, kdy je snaha přijít se zvýšenou přesností kolem jedničky.

Takže pokud mojí kritiku nepodložíte fakty, beru jí jen jako výkřik anonymního trolla.

[RealJ]

Pro zajimavost, jaky je usecase pro 40000 poloh na otacku?

[Pavel Píša]

Dvouúrovňové řízení podle mikronovým pravítek a těch IRC polohování až 30 kg asférických čoček ve výrobě https://toptec.eu/ pod interferometrem, kde se využitím dostatečně přesného napolohování pod optiku (přesnost desítky um) a následného otáčení čočkou nasnímá množství interferogramů ze kterých lze rekonstruovat povrch čočky s přeností někde v jednotkách nanometrů (tu optickou část jsme neřešili). Pro polohování je potřeba nastavit výškově čočku nesenou otočným stolem. Tedy se hýbe výškově těžkým stolem kuličkovým šroubem připěvněným k asi tunovému kamennému bloku. Další dva kuličkové šrouby nastavují polohu interferometru and čočkou, celkem také pěkná váha ale vodorovně. Vlastní stůl se otáčí PMSM/BLDC motorem s kvalitní převodovkou (Servoactuator Harmonic Drive FHA-8C-100-D200-E) podobný motor se používá na náklon stolu. Ty ostatní pohyby pro přesnost a kompenzaci průžení a roztažnosti šroubů a dalších dílů navrhli s lineárními pravítky notovanými na tom těžkém na míru ulitém kamenu se zalitými kovovými válečky se závity pro montáž na dílů na leštěný povrch umělé žuly. Jednali jsme s více dodavateli vedení a pohonů a nakonec jsme se rozhodli, že kvalitním měřením na levných krokových motorech vyjde projekt výrazně levněji, než nákupem špičkových servopohonů. Vše řídí dvě jednotky LX_RoCoN. Z nadřazeného PC jsou řízené přes TCP/IP. Dokument, ze kterého je trošku vidět rozměry zde. Jinak celá ta těžká konstrukce plave na vzduchových polštářcích aby nebyla spojená s chvějící se zemí.

Stejný typ naší jednotky řídil i experiment na střeše ESA - W-band on the run. Projekt v repozitáři https://github.com/esa/lxrmount. Nebo třeba pozemní testování převodovek a chvění pro volbu pohonů na ESA LISA projekt. Tam dlouho hledali, jestli by našli na pozemní testování ekvivalent, ale nakonec se k nám vrátili, řídící SW pro projekt, jak je u nás zvykem, dodaný také přes veřejný repozitář přes veřejný repozitář.

Jinak jak správně anonymní X doporučuje, tady se asi moc lidí na takovouto spolupráci a sdílení nenajdou. Ale v diskuzi na Linux Kernel Mailinglistu byl můj příspěvek k diskuzi o [RFC PATCH 0/7] Add Linux Motion Control subsystem velmi vítaný a myslím, že je šance směřovat k nějakému cíli, bude to trvat a bude to hodně práce.

[RealJ]

Zajimave, diky moc!

[-pb-]

Tak jsem si ten Nuttx přes víkend zkusil. Postupuji dle návodu, a hle při první vzorové kompilaci skončím na tom, že nějaký modul nenajde math.h. A to jsem do toho ještě nesáhl. Opravdu to odradí.

[Pavel Píša]

Prosím, pošlete, která verze NuttXu, jaký systém a verze (Debian, Ubuntu, pod WSL?), jaký kompilátor, jak jste NuttX konfiguroval, tedy něco jako

tools/configure.sh teensy-4.x:pikron-bb

Zrovna u libm je docela pravděpodobné, že pro danou konfiguraci, kterou jste zvolil, je vybraná externí, více optimalizovaná libm, která musí být dodaná s toolchainem. Tedy volba

Math library from toolchain (LIBM_TOOLCHAIN)

Zkuste v "Library Routines" -> "Standard C Library Options" přepnout na

Math library from NuttX (LIBM)

Jinak jestli je to tento problém, tak bych ho nehodnotil jako větší chybu, je to opravdu zájem dodat pro desítky platforem řešení, které lze nakonfigurovat i pro profesionální práci. Ale určitě je vítaný patch do dokumentace, kde bude popsané, že tento problém lze jednoduše řešit výše uvedenou volbou. Pro získání maximálního výkonu je pak potřeba zjistit, jaké je přesné doporučení pro danou platformu a který řetězec se má použít. To je často u platforem uvedené.

To je konkrétně pro náš starší pokus teensy_bb. Moc nevyšel, SPIFI Flash i při velké cache je nakonec pro RT nad 1 kHz brzdou. Jinak na pomalejší věci je to sestava výkonná, další chyba je ale od autora Teensy špatný návrh napájení a reference ADC, takže na FOC řízení PMSM to nakonec je také nepoužitelně zašuměné. Ale s interní Flash na SAMv7 máme výsledky pěkné, s častováním před dedikovaný timer si troufáme v běžném POSIX tasku na 5 kHz a zdá se, že je to i při floodu z pingu a další zátěži pro již větší PMSM control aplikaci generovanou z pysimCoderu OK. Pro další testování přidal pan Pressl (autor HW a sestavení SW) do mainline NuttXu cyclictest s možností testování i proti dedikovaným timerům. Histogramy vychází slušně, i při zátěži task start jitter je pod 50 usec. Zajímá mě, jak to vychází na alternativách, máte představu? Testoval to někdo na Arduinu s pingem, Telenetem, nějakým logováním dat z RT procesu nad 100 Hz přes TCP nebo nějakou jinou pokročilejší komunikací třeba na Arduino, Zephyru atd...

Pokud testujete aktuální mainline z GITu, tak je možné, že je tam něco je pokažené, pak určitě má smysl reportovat do projektu, ať se to dá dohromady. Ono opravdu na rozdíl od projektů, které jsou různé forky vždy pro konkrétní platformu jako je STMduino, ESPduino atd... je udržení podpory pro všechny desky níročné. Zase pak máte pro všechny stejné prostředí a nevyvíjí se vše desetkrát. Zároveň je možné testovat na Linuxu (když se dodrží základní POSIX subset) a pak jen překompilovat na NuttX. Jinak vůbec nemám zkušenost s buildem pod Windows mimo WSL a nemíním tomu čas věnovat. Zpět k příkladu buildu na Teensy-4.1, v mainline jsem teď narazil na nějaký problém, budu ho řešit. Ale vždy lze vzít release

git clone https://github.com/apache/incubator-nuttx-apps.git apps git clone https://github.com/apache/incubator-nuttx.git nuttx ( cd apps && git checkout -b release-12_6 origin/releases/12.6 ) ( cd nuttx && git checkout -b release-12_6 origin/releases/12.6 )

Konkrétně pro to teensy jsme teď updatoval náš projekt s návrhem desky a základní podpory pro NuttX i jeho export pro náš build větších aplikací mimo zdrojáky NuttXu, kdy se vše konfiguruje pro daný target automaticky. Můžete zkusit

git clone https://gitlab.com/pikron/projects/imxrt-devel.git cd imxrt-devel/nuttx git submodule update --init make

Vše by se mělo pak sestavit automaticky i s nějakými našimi věcmi navíc pro ty externí buildy. nttx-export pak lze použít i přímo pro návrhy řídicích systémů přes pysimCoder.

Jinak ano, NuttX má mnoho potíží, podle mé, již starší analýzy, je jeho scheduler je vhodný jen pro menší projekty do tak jednotek, možná desítky naráz probuzených tasků. Stějně tak škálovatelnost čekání mnoha tasků na muttex nebude žádná sláva, ale nabízí POSIXový priority inherintace. NuttX sice SMP podporuje, ale sám bych si ho takto použít netroufl. Naopak třeba RTEMS má plánovače někde úplně jinde, již před 10 lety běhal na 24 jádrových PowerPC, jenže mu chybí podpora platforem a periferií, tu má dobrou pro těch několik letových systémů, ale ty jsou zase mimo možnosti běžných nadšenců. Zephy je pěkný popisem hardware přes device-tree, což sice pro začátečníky je také komplexní, ale smysl to má. Plánovač má podle mě tak někde mezi, nelíbí se mi zatahování celých HALů od výrobců čipů, bude tam obrovská duplikace a nekonzistence podpory a stylu programování mezi různými rodinami.

Přiďte se podívat na InstallFest, Michal Lenc tam bude povídat, jak připravují i přes NuttX mainline podporu updatování a vzdálené správy firmware Aktualizace embedded systémů pomocí NuttX bootloaderu v Elektroline.cz.

Sám jsem letos přednášku nepřipravoval (lze čerpat z minulých), ale když se stavíte na mých workshopech, které jsou spíše míněné jako setkání a společné pokusničení, a třeba si přinesete i svůj hardware a počítač s GNU/Linuxem nebo alespoň s Ubuntu ve WSL, tak s Vámi zkusím NuttX na Vaší platformě zprovoznit. Případné chyby, které jsou často závislé na konkrétní instalaci a nastavení když tak nahlásíme do mainline. Rád se podívám a třeba navrhnu proměření i na jiných embedded systémech RTOS i bez RTOS. Ideální je to s lidmi, co do nich přímo přispívají, aby měli přehled, případně bechmarky dostali i do jejich do mainline.

Jinak bát se nemusíte, pokud si potřebujete jen dokázat, že učit se něčemu novému nemá cenu, tak si určitě toto stanovisko dokážete i na základu toho, co se nám nebude dařit, dokážete potvrdit a žít s nějakým řešením od těch, co si vás chtějí zavřít do nějakého ekosystému bez dobré možnosti spolupráce s druhými a portace aplikací mimo, dlouho spokojeně, ale pozor, často to pak zruší, jako ARM Mbed, Microsoft ActiveX, Explorer ekosystém... Ale bát se také nemusíte, za Skype Vám nabídnou Teamsy (tedy práci open source komunity přes KHTML, Safari , Chrome až opět do uzavřeného prohlížeče od MS) kde si pro naplánování schůzky na čas koupíte uživatelskou licenci Exchange. Stejně je to většinou s Arduino ekosystémem, třeba na Teensy je zamknutý na updateru přes USB, takže si vlastní destičku nepostavíte, nebo si k ní musíte kupovat "licenční" čip. S tím, že jeho účel je zjednodušit nahrávání, ale zcela blokuje HW debuggování (SVD/JTAG). Sám jsem do imxRT šel přes Teensy jen proto, že si vybrali lidi držící se a propagující Arduino na katedře, kteří neumí vystoupit jinam a chtěl jsem jim ukázat alternativu. Ale nepomohlo, teď se plácají v CAN FD na Teensy na Arduinu a tak se jim snažím alespoň trochu pomoci s tím. Je to hrůza bez shellu, debugování a kód slepenec do několika "profesionálních" dodavatelů atd...

[-pb-]

Udělal jsem na to issue: https://github.com/apache/nuttx/issues/15966 Zabralo použít tu math z Nuttx. Ale jak již někdo konstatoval: pěkný projekt, ale díry v howto. Teď už to zkompiluji, protože jsem vás náhodou potkal, ale chci udělat aplikaci - a to už se hledá těžko. Prostě nějaký průvodce, co by nám méně znalým vysvětlil architekturu, postupy, rizika etc. Nedivím se, že někdo raději sáhne po jednoduché smyčce.

[Pavel Píša]

Díky za zpětnou vazbu, doplnil jsem informace k issue, třeba někdo při podobném problému najde alespoň issue.

Start vlastního programování lze začít tak, že si povolíte Application Configuration -> Examples -> "Hello, World!" example (EXAMPLES_HELLO)

Nebo a to je čistší, zkopírujete třeba v repozitáři apps ve složce examples adresář nějaký adresář, třeba to hello na jiné jméno, třeba mytest, a veškeré výskyty "hello" změníte v tom novém adresáři na "mytest" nebo "MYTEST", to je zachovat velikost. Jedná se o sobory (CMakeLists.txt, Kconfig, Make.defs, Makefile, hello_main.c), hello_main.c bych ještě přejemnoval na mytest_main.c. Nemělo by být potřeba nic registrovat, v konfiguraci se Vám objeví Vaše aplikace, povolíte jí a při konfiguraci se stratem na NSH by měla být ke spuštění z příkazové řádky. Pokud chcete později minimální sestavu, nastavíte si main jen na tu Vší aplikaci INIT_ENTRYPOINT="mytest_main" .

Verzovat pak můžete ten vlastní form main a nebo později aplikaci vytáhnou do nějakého repozitáře mimo použít mechanismus `EXTERNALDIR`. Sám to takto neprovozuji, používám make export a pak celý NuttX beru jako knihovnu zdroj nastavení kompilátoru pro ty větší aplikace mimo. Ale má to také své problémy, třeba na RISC-V se určité informace neexportují správě. Mám na to issue. Mám to zanalyzované, ale řešení je pozměnovat to u všech desek a tak to zatím obcházím...

[Pavel Píša]

Jinak rád bych třeba i bějaký růvodce trochu slepil, nějaké materiály máme i z té výuky, vychází z něčeho od Alana Assise, i to jeho jě někde je veřejně. Asi by bylo nějlepší to přidat do Getting Started, ale opravdu nestíhám, takže kdy, jestli se k tomu dostanu nevím. Ale v zásadě jsem se zde dobrali k nějakým základům, takže ideální by bylo, kdyby to podle nich sepsal někdo, kdo začíná, protože on nejlépe vidí, co by býval byl potřeboval. Chtělo by to anglicky, pak to projdeme, jestli je to v pořádku a může se to nabídnout jako pull request. Zde je pak popis těch examplů.

Tak jsem dohledal celkem podrobný popis jak začít s aplikací

Custom Apps How-to

Je přesně tam, kde být má a je celkem podrobný. Ale souhlasím, že by na něj měl být odkaz někde více viditelný.

[-pb-]

Díky. Zkusím se s tím prokopat, uvidím jestli to dotáhnu k aplikaci.

[zemingr]

Odkaz na tutorialy Alana Assise:

https://www.embeddedrelated.com/tutorials.php?searchfor=nuttx