Arduino Open Source Report 2024

Byl publikován Arduino Open Source Report 2024 (pdf). Vypíchnout lze, že k červenci 2026 končí podpora platformy a operačního systému Mbed. Vývojáři Arduina proto přechází z Mbed na Zephyr.

23.2. 04:44 | Ladislav Hagara | Komunita

Komentáře

[Pavel Píša]

Tak se plně potvrdila mnou již dříve deklarovaná nedůvěra v Arduino politiku i Mbed a MbedOS, kde nejdříve byly velké vlny, pak jetě větší po přechodu pod ARM, který pečlivě zařezal přenositelnost na jiné architektury a pak postupně dovedl platformu k tvrdému konci.

Ale situace se vyvíjí celkem dobře. Ti co se drželi Arduina a na větší projekty jím kazili systematičtější přístup a blokovali a nutili k špatným přísttupům schopnější vývojáře, kteří se jejich podporou na Arduino ekosystému živili, tak všichni musí přejít na Zephyr, K němu mám také nějaké výhrady, ale vidím někde i výhody proti jiným, mnou i oblíbenějším, RTOS. Ale to je opravdu na debaty a ne na zásadní hodnocení, že zcela kazí další generaci jako Arduino.

Takže nyní se slušní vývojáři přesunou na Zephyr, začátečníkům a těm, kteří znamenají kouli na noze, protože neuměli pokročit dále, nechají a budou tak někaj udržovat tu zhoršující vrstvu API a ti, a většina se přesune dále.

Arduino IDE je nyní již ve spodu OpenOCD + Codium nebo VS Code opět s likvidační vrstvou omezeného GUI nahoře. A tak ti, kteří již pochopí, narazí, že to dále nepůjde to opustí a přejdou třeba na Codium a https://github.com/Marus/cortex-debug a je šance, že se z tohoto marazmu začne i laická veřejnost, neprofesionálové a falešně se identifikující profesionálové postupně vykřesávat.

Doporučuji si znova přečíst můj rozbor Jaký systém, RTOS, HAL, atd... volit pro menší MCU.

Pro úplné začátečníky pak souhlasím, že něco grafického typu scratch může být výhoda.

Celkem se mi líbí jak projekt tak i autoři https://microblocks.fun/. Naposledy jsem je viděl na FOSDEMu 2025 a vystoupení měli pěkná:

Program to Learn: The Power of Creative Coding

MicroBlocks 2.0: a complete makeover

Sám jsem jim nabízel ale také ve spod opustit tu kriplící Arduino vrstvu a přejít na NuttX, kdy by rychle získali podporu desítek desek. Ale před rokem to odsunuli. Teď nakonec na Zephyru budou a třeba tu mezivrstvu konečně vyhodí.

Sám stále mám zájem o tu alternativu na NuttXu, tak pokud by se do toho chtěl někdo pustit třeba v rámci Google Summer of Code 2025 pustit, tak dejte vědět, myslím, že nebudu mít problém to s reprezentanty projektu dohodnout.

Nakonec jeden z mála NuttX GSoC co byl, pod naším vedením Ing. Michal Lenc dotáhl do pěkného stavu viz pysimCoder integration with NuttX. Zde jsou třeba videa od ROBOTS 5, kteří na výsledku staví výukové platformy pro university v USA.

Pokud by chtě někdo GSoC třeba i na RTEMS, tak se také ozvěte. Opět tam nějaký track record máme.

A není potřeba se bát, že je zájemce spíše začátečník, po projití našeho předmětu B35APO - Architektura počítačů v takových projektech i třeba v návrhu FPGA uspěli i studenti prvního ročníku. Ale potřeba být ochotný vykročit vpřed do světa.

Jinak o tom konci Arduino vím již od minulého léta moje názory znáte i z dřívějška, ale zde se to hodí uvést, když je to tak pěkně nahrané jeho propagátory. A jsem i zvědavý, jak budou reagovat nyní ti, kteří v roce 2023 nesouhlasili.

Jinak sám jsem si na FOSDEMu vzal velké sousto nad můj kredit, ale když organizátoři potvrdili, že nikdo jiný blíže core vývoji do toho nepůjde, tak jsem to dokončil Linux Kernel Mainline Real-Time History, Support and Experience Based on Robotic and Automotive Projects. Slide se líbily i těm, kdo RTLWS a další zakládali. S mojí angličtinou je to horší. Tak když tak je zde alternativa česky z OpenAltu, ale tam jsou ještě v horším (neupdatovaném) stavu slide (Záznam).

Jinak za poslední roky jsem moc čas na blogy na ABClinuxu neměl, ale alespoň nějaké zkratky zde https://social.kernel.org/ppisa. Říkal jsem si vícekrát, že si na nějaké shrnutí na ABClinuxu čas udělám, ale asi je většině jasné, jak to chodí

[Max]

Díky za pěkné shrnutí. Ten OpenAlt mě nějak minul, musím to zkouknout. Jinak mám rozepsaných víc, jak 10 blogů a ne a ne nějaký dokončit. Asi už lenivím...
Zdar Max

[ehmmm]

Uz jsem si s tim par let nehral, ale nechce se mi verit, ze jsem tak mimo.

Ono uz arduino neni nejaka obycejna atmega s par kilobajtama pameti a cca 16 MHz krystalem a k tomu nejake stupidni ale funkcni IDE, ze ktereho to do te atmegy (obvykle po usb) nahraju?

[Max]

Řekl bych, že je, viz třeba Arduino nano. Nicméně také je možnost LAN, Wifi, BT, GSM, Lorawan, různá správa režimu spotřeby a milion věcí okolo včetně různých čidel / periferií (např. display). Předpokládám, že to vyžaduje nějaký větší projekt. Cílová velikost a nároky konkrétního zařízení pak není podle mně moc směrodatné k určení velikosti projektu. Viz třeba Linux, jak je obrovsky monstrózní a přitom může běžet na opravdu hodně osekaném hw.
Zdar Max

[Pavel Píša]

No ono ta Arduino komunita postupně došla k absurdní situaci, že hlavní procesor s uživatelskou aplikací bývalo to 30 let architekturou staré osmibitové AVR, kde se řešilo/neřešilo, že na Harwardskou architekturu vychází kompilátory špatně. Konstanty, textové řetězce atd. se buď zbytečně kopírují do RAM, které je málo a plýtvá se jí, nebo je každý přístup přes ukazatel volání funkce...

Pak začal být požadavek na IoT, a tak se přidalo TCP/IP stylem dáme shield s dalším, řádově silnějším procesorem než AVR (Cortex M, ESP32), často s uzavřeným a neudržovaným TCP/IP stackem, tedy bezpečnostní díra a absurdita, že uživatel se nemůže vejít do omezené RAM a Flash AVR, tam píše webové servery a vedle má řádově výkonnější procesor bez možnosti update.

Takže Arduino postupně začalo přecházet na ten ARM, ono i kvůli cěně, když ho tam již máme, tak to AVR je cena navíc a obecně propojení těch dvou MCU blokuje cenné výstupy nebo dokonce piny na shieldy.. Přitom u těch malých MCU je často cena závislá více na počtu pinů pouzdra než na architektuře a velikosti pamětí...

Takže se vše přesunulo na jeden MCU, ale zde, pokud chceme mít blokující main aplikaci tak, ak byli uživatelé zvyklí, tak TCP/IP stack musí běžet na pozadí/popředí...Potřebujeme tedy plánovač, pokud má stále být ta uživatelská část alespoň trochu RT, tak je nutné přejít na RTOS s prioritami, původně ten FreeRTOS (reklama trap na SafetyRTOS). Nyní Zephyr. I tak se postupně musí uživatelé přeučit, že nelze časovat pulzy na pinech for smyčkami jako na AVR, ale ono používají knihovny, třeba na LED pásky, a jejich autoři, kteří již jsou ochotní přečíst i část manuálu k MCU, jim to naportují.

Takže to je vývoj Arduino, jak ho z dálky a spíše s odporem, jak zakrývá základy a učí lidi špatným praktikám, sleduji. Ještě horší je, že blokuje mnoho schopných lidí, kteří by na lepším základě snadno připravili třeba hezké abstrakce i pro ty začátečníky. Ale teď alespoň nebudou psát znova a znova vše od nuly...

Jinak sestava dvou procesorů zase někde smysl má, i pokud máme programovatelný ten větší procesor a na něm RTOS, tak se rozumně dostaneme na časování v řádu 100 usec. A pokudu je potřeba nějaké složitější počítání přímo na vzorkovací frekvenci, třeba siny/cosiny pro BLDC/PMSM motory a nepodaří se funkci přenést na hardwarové periferie, tak se hodí další jádro bez RTOS k realizaci co nejjednodušší real-time smyčky časované také proti nějakému čítači.

Proto se třeba na AM335x na BeagleBone objevuje PRU jednotka, později pak u T i NXP často jeden i více Cortex-M, třeba i slabších, které doplňují Linuxový systém, i když i ten s RT PREEMPT je celkem schopný a otestovaný, že třeba i na těchto ARM bez dlouhodobě detekovaného vynechání dává 5 kHz. Ale tam, kde je potřeba jít dále a nebo je potřeba bezpečnost včetně časování prokázat, tak je výhodnější tu kritickou nebo rychlou část přesunout na dedikovaný Cortex-Mx nebo i Cortex-Rx i když propustnost mají o řád nižší. U jitteru vyhrávají..

Takže i na tom Zephiru a menších MCU se může vyplatit další, třeba i slabší jádro pro asymetrický multiprocesing, koprocesor. Třeba na ESP32C6 je druhé pomalejší RISC-V jádro. Může mít i druhou funkci, udržení komunikace a základní aktivity, když je potřeba snížit příkon a hlavní jádro se vypne. Když se pak třeba IR čidlem detekuje pohyb, tak se odstartuje to hlavní jádro, připojí se na WiFi sejeme a odešle obrázek.

[Max]

Oěpt díky za pěkné vysvětlení.
Zdar Max

[ehmmm]

Dekuji za odpoved. Stacila by i min obsahla. :)

Budu se muset podivat, co v tom je teda v soucasnosti za brouky.

[Radovan]

Je nějaký vůbec nějaký důvod použít na něco Arduino a nedat tam rovnou Pico?

Zvlášť když Panda jede jak ďábel a konečně získává dávno zasloužený světový věhlas...

[Pavel Píša]

Tak to Arduino je dnes v zásadě jen to jméno sady API, na které je komunita kolem závislá. Jinak co se týče reálných aplikací, tak on někde opravdu ten 8-bit může stačit a být spolehlivější. Než PICO určitě, to je hezké cenou a ta je důsledkem použití novější technologie křemíku určené pro větší SoC (třeba mobily), kdy na takto jednoduchý čip je potřeba tak nepatrná plocha, že je cena proti starším technologiím zlomková. Jenže to má i důsledky, "jemnější" "node" je více citlivý na radiaci, dále na něm v dané verzi nelze implementovat Flash (podobně jako na ESP32 nebo imxRT), takže se na kód dává SPIFI externí Flash, ta vyjde levně, protože je to technologie přizpůsobená právně na tyto buňky a ne rychlou logiku. Jenže SPIFI je zaprvé u těchto malých většinou interface bez ECC (opravy chyb) a zadruhé je velmi pomalý. To se sice co se týče propustnosti SW vyřeší cache, ale nedeterminusmus občas překvapí i toho, kdo o cache a dalším učí, viz B0B35APO. Opravdu ty záseky a zpomalení na NuttXu na našem experimentu teensy_bb byly horší, než jsme čekali. Nepodařilo se nám dobře dostat na kilohertz s řízením motorů. Potíž bylo 20 kHz přerušení od AD převodníků, které nám vytloukalo cache. Víme jak to řešit jinou kombinací ADC a DMA s cyklickým bufferem, ale i tak potřebné 4 kHz vypadaly bídně. Na nějaké neural network zpracování snímků by ale imxRT chodilo dobře. Po přechodu na slabší/pomalejším SAMv7, viz projekt SaMoCon, se dostáváme na 5 kHz PMSM řízení. Přitom ten má interní Flash, i ta frekvenci CPU nestíhá, je tam sice měnší buffer, než imxRT cache, ale přecejenom je to připojení paralelní (přes piny by stálo moc) a ty latence jsou únosná. Zároveň je Flash s ECC...

Takže zase, velmi nerad vidím tlačení Raspberry PICO a i Raspbery Pi do seriózních projektů. Tam i u Linuxu patří něco navrhované se záměrem průmyslového použití, NXP i.MX5/6/7/8/9, Ti AM335x a výše... U MCU ty SAMvX, PIC32, PIC64, spíš ne imxRT ale S32 atd... Je potřeba mít přehled a to stojí čas a zde dostáváte možná zkreslený, ale desetiletí vytvářený názor z reálných aplikací, výuky a komunikace s lidmi, kteří dělají pro ESA, NASA, zabezpečení pro vlaky, tramvaje, výrobce PLC, network systémy atd...

Takže pokud si i předchozí tazatel přeje neúplné ale krátké odpovědi tak ho odkazuji ať je hledá tam, kde nadšením výská Arduino komunita. Například jeden často zmiňovaný autor ke mě byl až sprostý, proč neučíme architektury počítačů na osmibitech jako Z80, že s MIPSem a RISC-V jsme mimo a je to jen aby se vysokoškoláci vytahovali. Přito opravdu do podrobna popsat třeba 8080 bude mnohem náročnější než RISC-V, kde je stavba CPU přímočará a dekodér bezstavový. U Z80 bude nutné začít mikrokódem nebo složitými stavovými automaty. Tedy pro výuku zcela špatně. Také ty univerzity, které světu pokrok nesporně v IT přinesly největší, již od 80 let učili na RISC architekturách, které u nich vznikly i e zapojením jejich studentů...