Názory k článku Programovatelné IO na mikrořadičích RP2040: komunikace s PIO a ovládání PIO

Článek je to zajímavý a i já jsem kdysi napsal nejeden program v assembleru pro jednočipy. Ta doba je už ale dávno pryč a tak mi nebylo jasné, proč nevyužít nějakou hotovou standardní knihovnu, třeba PIGPIO. Spustí se daemon a já pak komunikuji ve vyšším jazyce, nemusím se babrat v asm. Pak jsem se podíval na specifikace a hele, RAM v kB maximálně MB. Aha. Chápu. Ale jaký je důvod dnes něco takového používat? I ta nejstarší "klasická" malina umožňuje používat plnohodnotný linux. Výhoda tohoto je snad jen spotřeba elektřiny. Takže dotaz na čtenáře: jakou aplikaci řešíte, kde se nedá použít "vyšší" verze HW a je tedy zdůvodnitelné použití tohoto ořezaného "nic" + asm? Nechci vyvolávat zlou krev, ale vymýšlet dnes softwarové PWM mi přijde absurdní.

ešte dodám že si práve staviam elektromer a malina by sa mi s ostatnými komponentami ani nezmestila do krabičky na din lištu

Kamarád staví "inteligentní" dům, taky používá klasické RPI - několik pro různé subsystémy, a myslím, že s umístěním na DIN lištu problémy neměl. Ale nejsem si jistý.

Krabicky na DIN existuji, spis muze byt nekde to nasochat do existujiciho (maleho) rozvadece, kde uz je proste plno diky pritomnosti jinych pristroju (jisticu&pod)...

Hele,
a v dnešní době, vyplatí se to?
Ještě bych pochopil nějaký modu ala PZM-004T a nějaké ESP s firmware, co to dokáže zpracovat ( třeba ESPeasy ).
Ale začínat na zelené louce s RP2040...
Když tu máme třeba Shelly Pro 3EM-3CT63

SW PWM je ukázka, která je dobře pochopitelná, dobře odladitelná (prostě snížím frekvenci a vidím blikání) a má to pár instrukcí, takže je to dobré na naučení PIO. Troufám si říct, že to, co dokáže PIO, klasická malina s ne-RT systémem těžko zvládne. Určitě ne tak jednoduše, jak to může znít. Ale dám se rád překvapit (tuším něco podobného řešili studenti pana Píši).

Spoustu veci je treba resit v garantovanym case = mas 100 cyklu a chci videt, jak libovolnou knihovnu a libovolnej kompilator presvedcis o tom, ze ten kod za zadnych okolnosti nesmi trvat dyl nez 100 cyklu.

A predevsim, jak to pak overujes ...

Na takovy veci se nic na cem bezi libovolnej OS pouzivat vubec neda ... fakt te chci videt v aute, ktery nebrzdi, protoze se zrovna ted system venuje obsluze cidel smradu z vejfuku a na brzdy nema cas ...

Ano, tohle je pravda. Ale jsem zvědavý, jestli se v nějakém budoucím článku dostaneme až ke spuštění RTOS na tomto HW. Třeba FreeRtos by byl fajn. Ale ptal jsem se na konkrétní aplikaci. Já jsem třeba dělal ovládání pozicionéru pro satelitní talíř. A k mému překvapení stačil i "pseudo" realtime. Rp3 už je dost silná, aby reagovala celkem slušně rychle. A nějaká setinka vteřiny zde není rozhodující. HW čítač maliny sleduje půlzy ze snímače polohy pozicionéru, vygeneruje přerušení a to zpracuje akci, třeba zastavení motoru. Nic přesnějšího není potřeba.

No, ono je potreba rozlisit mezi domacim bastlenim nebo spotrebni elektronikou a kritickymi aplikacemi, kterych je kupodivu docela dost. Predrecnik tu nakousl automotive. Jakmile delate v teto branzi neco "zivot ohrozujiciho" (a ze tech kritickych ECU v aute docela je), tak se najednou zacnou objevovat bubaci typu ISO26262, FuSi, ASIL, Misra C, TARA/HARA atd., atd. Najednou zjistite, ze nejenze cokoliv s Linuxem je nepouzitelne protoze vam ho nikdo necertifikuje, ale zacnete mit i potize s certifikaci prekladace, std. knihoven (nemluve o povetsinou tragickych knihovnach vyrobcu mcu) atd. atd. Typicky mate pozadavek na superloop <= 10 ms (nebo dokonce 1 ms), 10.1 ms jednou za rok je neakceptovatelne. Linux je mimo hru (nepredikovatelne), RTOSy musite nasilim nejak priohnout, a pak pred auditorem prokazte, ze priohnutost garantuje casove requirementy na 100 % za vsech podminek. V superloopu i ve vsech periodickych subprocesech (i interrupty) si musite merit dobu provadeni a periodu vykonavani, hlidat zasobnik(y), selhani systemu se detekuje watchdogem internim/externim + hw SFU (Safety Management Unit), monitorujete napajeci hladiny, rekalibrace ADC,... Jeden potom rad pouzije neco certifikovaneho (Autosar) nebo holt baremetal, a ty nejkritictejsi casti resite asm (hard fault exception), protoze tak nejsnaze garantujete splneni casovych pozadavku na reakci systemu.

No nevím, to auto jsem bral jen jako takový příklad mimo. Fakt by někdo koupil desku v Číně za stovku a pak by s tím dělal automotive? A na základě tohoto článku? Prostě jsem myslel, že se bavíme o domácím bastlení. A tam si dovedu představit tuto desku třeba jako generátor nějakého signálu. Což dělá málo kdo. A nic víc. Na řízení domácího skleníku je Rpi3 skvělá. A s linuxem a Pythonem a skoro RealTime.

Tak treba ja to mam ve stolnich hodinach. A opravdu nepotrebuju aby na tom linux startoval 5 minut, a hodiny problikavaly protoze nejaka vicemene nedulezita softwarova komponenta cojavim zkousi hledat sitove tiskarny, a kratkodobe sezere CPU. A prekreslovani vetsi matice diod vyzaduje opravdu presne casovani, jinak to blika a ani rychly cip nemusi stacit kdyz je prerusovan jinyma blbostma. V hodinach potrebuju jen tu jednu vec - hodiny. Takze mi nejde ani o tu spotrebu, ale prave o tu jednoduchost.

Ale treba v kalendari co se zobrazuje v kuchyni uz mam plnohodnotnou malinu, protoze tam potrebuju aby se to prihlasilo na google dvou ruznych uctu (ja+manzelka), vycetlo udalosti, vygenerovalo novy kalendar, vykreslilo ikonku pocasi, prevedlo do png a to se poslalo do driveru pro eink. Coz je ve vysledku celkem dost komplikovanych operaci, na ktere uz je potreba prakticky plnohodnotny OS.

Ono ide aj o latencie. Resp ich rozptyl. S malinou nikdy nedosiahneš to, čo obyčajným MCU. Na maline aplikácia beží na CPU spolu s ďalšími procesmi a naťahuje sa s nimi o cache. Tento problém aplikácia ktorá má celý MCU pre seba nepozná. Takže tam kde je to nejak časovo/latenčne kritické budú mať MCU vždy výhodu.

U vicejadernych MCU jakym je napr. i tohle RPico, je rozptyl/jitter horsi pokud budete pouzivat obe jadra a delat tam nejake kriticke PIO bitbangy - ono si jaksi i transakce na zbernici musi poradit se sdilenym pasmem - rozhodne to neni tak ze sudy/lichy takt je pro jedno/druhe cpu (v podstate cokoliv co ma i-cache / d-cache uz nema zarucenou predikovatelnost latence).

Takze tahle nepredikovatelnost zrejme donutila vyvojare implementovat ty IO procesory na hranici cipu, takze tam je uz presne casovani zaruceno.

( Treba kdyz jednou uvidite VGA signal, ktery je generovan na zaklade hodin se SSC, tak zjistite co znamena nutnost presneho casovani :D )

Vida zrovna generovani video signalu jsem mel zminit, tam je to dobre videt "na vlastni oci", i kdyz se clovek sekne o jeden-dva takty.

Dnes sa ani jednočipy neprogramujú v assembleri, toto je podľa mňa špecialita pre ultra nízku spotrebu, aby to dlho vydržalo bežať na batérie ak stačí len ovládať nejaký vstup/výstup. Podľa mňa nemá zmysel dávať malinu niekam na jednoúčelové použitie ako napr. zber hodnôt zo snímačov. Na to je malina drahá, komplikovaná (údržba plnohodnotného OS), má vysokú spotrebu. Mne doma momentálne bežia 4x ESP32, teplota a snímač dverí v záhradnom domčeku, ďalší snímanie teplôt na kotli, jeden v izbe na CO2 a snímače okien v dome, jeden na LED pás - alarm pre príliš dlho otvorené okná. Nezdá sa mi optimálne mať doma 4 maliny

jen na okraj: Raspberry Pi Pico (které má ten čip RP2040, který tady popisuji) má s klasickou Rapsberry společné jen jméno. RP2040 má mnohem blíž právě k ESP32, než k plnohodnotnému CPU.

Když zůstanu u známějších e-shopů, tak RP2040 stojí 29 korun. Celé Pico pak 109 korun, ale dá se sehnat levněji.

jj, malinou som myslel klasický raspberry, aký myslel hugocz.
Nepoznal som tento stavový automat RP2040, zistil som, že ESP32 má ULP, podľa popisu vyzerá byť na vyššej úrovni (viac registrov a inštrukcií + podpora I2C senzorov), ale nemám s tým skúsenosti, možno by bolo zaujímavé porovnanie z pohľadu spotreby (napr. či jednoduchší RPi má výhodu v nižšej spotrebe)

ad spotřeba: to je zajímavá problematika. Tím, že na Picu je možné vypínat různé subsystémy, tak se může hodně lišit (například jde vypnout nějaká paměťová banka a systém může používat ostatní; samozřejmě jde udělat deep sleep a vypnout všechno včetně hodin atd.). Uvádí se cca 6-10mW pro běžíci RP2040, ale popravdě to nemám změřené, protože to je pod přesností měřáku, který mám k dispozici :-)

Obecně bych čekal vyšší spotřebu, protože to je dvoujádro na celkem vysoké frekvenci, ale nejsem v tomto ten pravý na kvalifikované odpovědi.

Jenze 10 mW pri 3.3V je porad 3mA ... skutecne usporne mcu jsou o tri rady vedle, treba na 3uA, a kdyz zacneme googlit, tak nalezneme 10nA sleep u C8051F911 ... jiste neni to tak velikej cip, ale uspora je milionkrat jinde. To jen na okraj ,)

Já své ESP32 projekty ani nemusím moc programovat. Pomocí ESPHome udělám deklaraci "programu" v YAML a v případě potřeby jen doplním funkcionality krátkým kódem v C++ a je to. :))

Zatím můj nejsložitější projekt s ESPHome je vytvoření "palubního počítače" na Jawu 50 - tachometr, otáčkoměr, teploměry, měření hladiny paliva, zobrazení dat na Nextion displeji - vše to v pohodě stíhá.

27. 2. 2025, 12:21 editováno autorem komentáře

Ano, když jsem mluvil o spotřebě, myslel jsem právě na ESP32. Chvíli jsem si s ním hrál v oblasti Zigbee aplikací. Je k RP2040 podobný i cenově. Nicméně se zeptám: a ty máš ty 4 aplikace připojené k internetu? A řešíš u nich bezpečnostní aktualizace? Pokud ne, tak tě k tomu nikdo nenutí aní u Rpi s linuxem. Takže jaká údržba OS? Jen ještě poznámka, předpokládám, že na každý projekt používáš samostatné ESP32 kvůli spolehlivosti, aby v případě poruchy nekleklo všechno najednou. Určitě by totiž na to všechno stačil jeden počítač.

všetky 4 sú pripojené na net, nie je to z dôvodu spoľahlivosti, ale preto, že každá je v inej miestnosti / budove. Neaktualizujem, možno to je len pocit, ale full OS má zrejme väčší attack surface. Programujem to v C++, na RPi by som to programoval tak isto v C++, takže nevidím v RPi žiadnu výhodu.

V pohodě. Každý jsme zvyklí na to svoje. Mě dělá dobře když vím, že mi 4GB RAM určitě nebudou svazovat ruce. :-) Ostatně tento článek je o RP2040. To může být dobrý start pro začátečníky na výuku. I cenově. A k tomu temhle článek sedí a je výborný. Ale v dalším kroku bych už opravdu radši sáhnul po ESP32.

Velmi povedený článek. Kombinace micropythonu a asembleru pro ARM. Pokud dobře rozumím momentálnímu stavu vývoje Micropythonu, tak tato možnost je dostupná jen pro určité procesory. Jde o procesory ARM a Espressif Xtensa, na ostatních platformách (Risc V // ESP32-C či RP2350 Hazard3) je toto ve fázi vývoje.
Jedná se o moderní, ale stále malé SoC. Zajímalo by mě jaká je "cena" např. velikost kódu obsluhující dekorátory @asm umožnující zkombinovat micropython s asemblerem? [Odhaduji, že se jedná poměrně omezený nárůst velikosti fw]

20. 3. 2025, 17:50 editováno autorem komentáře