Odpověď na názor

V tom prvním máte určitě pravdu, že staré API se špatně opravuje a jediná schůdná cesta je pak přes nové alternativní API, které zase vede k nutnosti udržovat obě. A rozumím, není to jednoduché.

Taky můj rozbor digitalWrite a pinMode nebyl míněn jako kritika, ale jako určité vyjádření pochopení. Já bych si představoval něco jako pinModeEx(pin, mode), která by třeba mohla nastavit pin do libovolného z výše uvedených stavů, kdy HIGH a LOW jsou také chápány jako móde. Pak by se mi líbil systém transkačních nastavení pinů, kdy nastavím víc pinů a jednorázově to commitnu, a někdo under hood zařídí operaci atomicky. Je to rozšíření API

Namítám ale jednu věc. Arduino R4 UNO (Minima i Wifi) byly uvedeny v červnu 2023. Předpokládejme že vývoj SW probíhal rok, tedy bavíme se o programátorských standardech z roku 2022. Navíc pro překladač, který v té době už 6 let podporuje C++17. Ty programátorské styly které se tam používají byly platné před rokem 2011, to je nějaký 12 let!!!! Kritika je na místě

Bridge mezi ESP32 a Renesas je softwarové vybavení které vzniklo přímo určené pro Arduino R4, jinde se nepoužívá . Github tohoto projektu začíná 16. května 2023

https://github.com/arduino/uno-r4-wifi-usb-bridge/commit/9d2e7d71183d8a6e3e7e3511237dd7e0f2a7aa58

Takže se prosím přestaňme vymlouvat na stará API a neexistenci ESP čipů. Ten kód je z brusu nový.

Pak bych potřeboval vysvětlit ty poznámky kolem superlooup. Jestli jse z toho pochopil, že mi chybí multitasking - nic takového jsem neříkal, je rozdíl mezi "parallel a concurrency". Stejně tak když někde zmíním asynchroní přístup, nemyslím s tím multithreading. Právě asynchronní přístup umožnuje dobře navrhnout superloop. Ten jen není pevně danný, ale dynamicky provádí to, co je požadováno. Typicky mohu superloop použít pro eventové řízení. V rámci superloopu se zjistí změna stavu nějakého čidla a vygeneruje se event. Asynchronní kód pak může vypadat takto


co_await wait_pin(1, HIGH); //čekej na až bude pin 1 na HIGH


přitém co_await vrací řízení do superloopu. To je concurrency, to je asynchronní řízení. Pokud nemám co_await, mohu postaru použít callbacky, třeba


on_pin(1, HIGH, [=]{... /* dělej něco */ ...});


I to je asynchronní přístup.

Scan network by šel realizovat


WiFi.scanNetwork( [=] (auto result) {... zpracuj vysledek ...} );


S tím, že lambda callback se zavolá jakmile je scan hotový a kód mezitím dělá něco jiného. Samozřejmě se callback zavolá ze superloopu když se zjistí, že operace je dokončena.

A tím se dostávám k poolingu nad ESP. Nemáte pravdu, pooling tam nejde zapnout, nebo jen pro některé operace. Ano WiFiServer.ava­ilable() tam je, stejně jako WiFiClient.ava­ilable() ale to je všechno. Třeba WiFi.localIP je blokující s timeoutem až 10 sekund. WiFi.begin() je blokující, ale timeout si mohu nastavit (naštestí), WiFiClient.send() je blokující, pokud ESP zrovna loví signál a nemá kam data odeslat

Aby ten bridge byl plně asynchroní, musel by ten protokol vypadat jinak. API by muselo používat callbacky nebo korutiny (C++20), Muselo by se v superloopu volat nějaké udělátko co zjišťuje, jestli ESP už dokončil činost. V protokolu by na to musel existovat nějaká krátká zpráva, která by se na serial portu neztratila. Třeba znak. Jakmile by se ten znak objevil, ze strany Renesas by se poslal command na přečtení výsledku.

To by pak umožnilo superloopu vyvolávat asynchronní callbacky na požadované operace.

Uvažoval jsem, že bych to samozřejmě celé přepsal, ale pro koho? Kdo to ocení? Já zřejmě žádný další projekt zatím dělat nebudu.

(navíc bych musel asi přepsat i ten bridge, změnit protokol)

Doufám, že si teď rozumíme.