Vlákno názorů k článku Programovatelné IO na mikrořadičích RP2040 v Raspberry Pi Pico od xbastaj - Děkuji za článek a těším se na pokračování. S...

Děkuji za článek a těším se na pokračování.
S Rasberry jsem zatím nic nedělal, mé zkušenosti jsou hlavně s AVR ať už přímo v assembleru nebo jako Arduino. Načekal jsem že jsou PIO tak "vymakané".
Když ukazuji žákům jak se v assembleru ovládá sériový port (nic na tom není : nastavit pár konfiguračních registrů a IN / OUT s datovým registrem), nebo jak využít čítače, tak dostanu odpověď: "Na Ardinu je to jednodušší." No jasně, využiji knihovny, který napsal někdo přede mnou. Na druhou stranu tím ale přijdu o většinu výkonu procesoru, protože skoro vždy musí počkat až se daná operace dokončí. V assembleru lze snadno s využitím přerušení operaci spustit (například načtení analogové hodnoty) a přerušením se nechat informovat že je hotovo. Jenže pořád někde čtu nebo slyším, že assembler je nemoderní, překonaný,... Můžu to programovat v C, ale pokud půjdu na úroveň registrů tak už se to zas od assembleru zas tolik neliší, stejně musím nastudovat jak co funguje.

A tady si kladu otázku na kterou nějak nemohu nalézt uspokojivou odpověď: Mikrořadiče obsahují spoustu periferních modulů: čítače-časovače, sériové linky, řadiče displejů, AD převodníky, generátory signálů, tady teď vidím u RPi PIO. Jak se tyhle moduly využívají při programování ve vyšších jazycích? Respektive jak je dokáže využít programátor co využívá jen knihovny a netuší co se za nima skrývá. Nebo je to tak, že u velké části aplikací jsou tyhle moduly nevyužité a celé se to vyřeší softwarově hrubou silou hlavního procesoru (něco jako dopadla konzole Atari Jaguár)?

PS: na 8.bitovém Atmelu (ATMega32) dokážu využívat a v assembleru ovládat většinu modulů. Co jsem zatím nedal je I2C (přiznávám moc jsem tomu nedal, několikrát jsem s to to pokusil a vždy po pár hodinách bádání jsem to vzdal/odložil a radši se I2C vyhnul). Máte s tím někdo zkušenosti? Nebo třeba nějaké knihovny pro assembler? (Něco jsem si z internetu stahoval, ale když jsem to pak zkoumal, tak v několika případech, pokud jsem to správně pochopil ta implementace I2C byla dělaná softwarově na obyčejných pinech)

Se podivej na dokumentaci k pythonu pro RP2040. Vidis tam hezke priklady v pythonu, a bum najednou assembler decorator pro ty programovatelne io. Pokud clovek chce jit na plny vykon, assembleru se nevyhne.

Přesně toto bych chtěl probrat příště. Protože PIO umožňuje zkombinovat třeba ten MicroPython s assemblerem těch stavových strojů. Poměrně zajímavé řešení - low level věci se opravdu řeší low level (bez bit bangingu) a zbytek klidně může běžet souběžně v tom interpretru (tedy MicroPython umí i vkládat assembler Cortexu, to je možná pro výuku taky zajímavé).

My jsme kdysi museli pracovat na úrovni strojáku (PMI-80), ale to by dneska asi neprošlo :)

(osobně mi připadne ten přístup RP Pico dobrý - může se použít Python pro začátku, u toho se vysvětlí GPIO a potom se může jít do céčka. Je to IMHO lepší a levnější, než micro::bit a další podobné věci. Navíc když se připlatí dolar či dva, je v tom i WIFI).

Wifi je vyhoda. Bezi mi na tom budik u postele, a sice tam je modul pro hodiny realneho casu, ale ten se kontroluje vuci NTP serveru. Takze to je uplne bezudrzbove - kdyz nejede wifi, drzi cas velmi dobre. A kdyz jede wifi, tak cas drzi jeste lepe.

(Mozna se nekdo divi proc mam budik u postele co bezi na RP2040 - ale nenasel jsem komercni budik ktery by bylo mozno docasne vypnout. Napr. vzbudim se o deset minut drive, takze vstanu hned ale nechci aby budik zbytecne vzbudil deti. Takze zmacknu tlacitko, a jeden nasledujici budik se nespusti. Druhy den budik funguje zase jako vzdy. Mohl bych si vzpomenout a znovu zapnout budik, ale na to jsem zapominal. Tuhle funkci mam treba i na mobilu, ale me se nechce porad tahat mobil do loznice. Jo, jeste existuji 'chytre' budiky co muzu ovladat hlasem, ma to vlastni cloud, napojeni na google ucet, a mozna by takovou funkci umely, ale takovehle piiiiip veci fakt nemusim, protoze az vyrobce prestane podporovat cloud pro tenhle typ tak by z toho byla leda cihla.)

Hele, tuhle frustraci z chybějících primitivních funkcí bez zbytečného balastu znám...

Rád bych se zeptal, jak máš řešené napájení (a jaký displej) a případně jak dlouho vydrží na baterku?

mam tenhle displej:
https://www.waveshare.com/wiki/Pico-Clock-Green

ale ukazkovy kod je slabsi, i kdyz funkcni, takze pouzivam tohle:
https://github.com/astlouys/Pico-Green-Clock

Plus tam mam nejake vlastni malou modifikaci tlacitek.

Uplne nejlepsi je sensor jasu, takze ve dne je displej citelny i pri slunci a v noci slabounce sviti takze nerusi.

Záleží jak moc vysokoúrovňové jsou ty knihovny.

Arduino je hodně vysoko a neumožňuje skoro žádné optimalizace, ale na většinu uměleckých a blikacích věcí to bohatě stačí.

Ještě se dá celkem snadno použít superloop a polling, to už stačí skoro na všechno a má to výhodu známého časování (teda ne v Arduinu s busy loop waitem všude možně).

Interrupty a DMA jsou potřeba až u věcí co jsou hodně rychlé nebo potřebují šetřit energií. Ale zase je tam větší problém garantovat časování, protože interrupty přerušují běh hlavního "vlákna" atd.

Jinak I2C je hodně složitý protokol, hlavně když dojde na podporu clock stretchingu a odsekávání stavu sběrnice. Třeba STM32 čipy mají u i2C i docela dlouhou erratu.

Co se praxe týče, tak ty moderní mikrokontrolery jsou hodně o nastavení pár registrů a nechat to dělat svoji práci. Stejný přístup jsme používali u nějakého DSP od Motoroly (myslím) už před 20 lety v předmětu Mikropočítačové řízení na VUT.

Prakticky jsem kombinoval všechno.. Arduino knihovny na prototypování, C/C++ s přístupem k registrům i kusy assembleru na speciality nebo workaround bugů (ale málo, C přístup k registrům obvykle stačil).

V Rustu jsem ještě assembler použít nemusel, stm32 knihovny maji nízko i vysokoúrovňovou část, takže se to dá dobře kombinovat. A superloop mám schovanou za async abstrakci s vlastním jednoduchým executorem (interrupty jen probudí danou úlohu a hned skončí).

I2C neni slozite.
Da se to rozpadnout cca na 4 operace (ktere maji HW podporu) a vyse resit uz softwarove. Ja to delam tak, ze mam takto dvovrsve, a ten lowlevem mam jak bit bang, tak abstrakci na STM a pak svoji FPGA IP.
proble s tim je, kdyz je prilis inteligence v HW. Typicky tam pak nekdo neco nedomysli a musi se to ruzne obchazet.
Uplne tedy neberu napr. multimaster, ale to jsem nikdy nepotreboval.

6. 2. 2025, 13:04 editováno autorem komentáře

Takže je to tak jak jsem čekal: složitý a náročný. Musím umět vyšší jazyk, chápat jak funguje hardware, nastudovat jak fungují knihovny, umět aspoň základy assembleru a pak to celý spojit.
Když jsem přemýšlel jak je co složitý, tak pokud je programování ve vyšším jazyku (obecné C, wiring pro arduino) obtížnost 1, psaní čistého assembleru pro mikrořadiče je úroveň 2-3, a celý to spojit pak úroveň 4-6 možná i víc. Aspoň tak to vnímám.
Na střední škole, kde učím, se i ti nejlepší žáci přiblíží někde k úrovni 2 (ve 3. a 4. ročníku dvě hodiny týdně teorie kde musím začít od nuly (ALU, přerušení, sběrnice, paměti, paralelní rozhraní, sériové rozhraní, čítače, mikrořadiče,... končím stručně u programovatelných obvodů) plus k tomu asi 25 dvojhodinových cvičení na assembler AVR (paralelně s tím jedou s kolegou cvičení na Arduino). Myslím že to jak to učím, je dost podobné kurzům co jsou tady na rootu - postupně společně vytváříme program, který mám odzkoušený a kometuju co a jak. Sami by to nevymysleli, ale většina alespoň pochopí jak to funguje. Slibuju si od toho, že tahle dám aspoň nějaký základ pro ty co se budou chtít tomu věnovat dál. Docela by mne zajímalo kolik (kolik procent programátorů) se dostane na ten vyšší level (sám sebe vidím tak někde 3-4).

Jinak dříve jsem používal hodně spojení TurboPascal + asm (neboli jak jsme tomu říkali "GreenPascal". Tam se to opravdu hodně povedlo. Když jsem před časem četl články jak vkládat assembler do microPythonu a jak se tam předávají parametry, moc se mi to líbí. Zatím jsem se nedostal k tomu zkusit si to nějak prakticky, ale na první přečtení mi to dávalo smysl.

Strašně záleží, co od toho člověk chce. Arduino se mi moc nelíbí - originál má výrobní cenu asi dolar a prodává se za pár stokorun, všechny věci se řeší stylem kup si modul, stáhni knihovnu. Super pokud člověk chce něco na ovládání LED pásku nebo jednoúčelovou věc nebo jako start pro dvanáctileté děti protože se rychle dostaví výsledek. Jestli má smysl se učit Arduino a Wiring API těžko říct - na hobby projekty fajn, ale o tom, že by to někdo používal na komerční projekty nevím.

RPI Pico jsem zatím popravdě používal pouze s MicroPythonem právě jako levnější Arduino s WiFi a BLE, protože jsem nepotřeboval výkon ani provoz na baterky a navíc se část kódu dala odladit na PC. Co vím, tak se dá programovat v MicroPythonu, CircuitPythonu, C a C++ přes RPI Pico SDK a navíc asi použít FreeRTOS a Zephyr.

Psaní v ASM, C, C++ vidím tak, že assembler je ukecaný a psaní v něm není těžké, ale je to opruz (skládání všeho do registrů, tabulka syscallů, linkování knihoven) a znalosti jsou nepřenosné. C je podstatně menší opruz, ale přijde mi, že minimálně půlka kódu je obsluha chyb a management zdrojů jako paměť a otevřené soubory a v C++ se píše nejpohodlněji díky existenci unique_ptr, shared_ptr, ofstream apod. které zavírají soubory a uvolňují paměť, když se zavolá destruktor, což snižuje prostor pro chyby. Jenže C++23 je tak složitý jazyk, že se všechno nedá naučit a věci nemají jednoznačné řešení. Vyšší jazyky mají velkou výhodu v tom, že celá logika se dá odladit na PC zatímco ladit assembler na jiné platformě je vyšší dívčí.

Co se týká učení, tak za půlrok to dělá pár hodin. Tady je asi nejlepší do žáků nalít nějaké základy a principy, které mají obecnou platnost, učit se knihovny, které fungují na jednom mikrokontroleru nemá smysl. Sám se chci trochu podívat právě na FreeRTOS a Zephyr, které se používají na tučnějších mikrokontrolerech. Podle mě se sem moc programátorů nedostane, protože je to úzká specializace na průmyslové a řídící aplikace, regulaci a zpracování signálů. A každý programátor se dnes úzce specializuje. Někdo na web, javascript a specifické frameworky, databáze, někdo na mikrokontrolery a hradlová pole, integritu dat, regulaci, někdo na PC aplikace a grafiku, k tomu možná nějaké části matematiky, fyziky, optimalizační úlohy. Někde jsou průniky, někde vůbec.