Vlákno názorů k článku Programovatelné IO na mikrořadičích RP2040: komunikace s PIO a ovládání PIO od Hugocz - Článek je to zajímavý a i já jsem...

Č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.