Příspěvky

256

Vývoj / Re:CSP v embedded světě

« kdy: 14. 03. 2021, 23:48:37 »

Vykopnu jeden nápad:

Jenom tak intuitivne, bez jakyhokoli researche si rikam, jestli by se nedal udelat nejaky jakoby "sdileny stack" - ze by se pouzily treba kontinuace bez moznosti returnu, takze by se nemusel udrzovat stack a kazda kontinuace by dostala cely potrebny kontext (stav) a pak by existovala treba nejaka globalni tabulka vsech kontinuaci, ze ktere by se pri kazdem kroku jenom vybrala nahodne kontinuace, ktera ja pripravena bezet. Cili misto spousty individualnich stacku by byla jedna globalni tabulka, ktera by pamet vyuzila lip a stacilo by kontrolovat, ze nepretece ona. Stav by mohl byt bud alokovany na halde, nebo by byla treba svrchu omezena jeho maximalni velikost, aby polozky v tabulce mely fixni velikost.

Prakticky by se teda program musel rozdělit na části, které by vždycky začínaly nějaký čekáním na něco - typicky na zprávu v kanálu. Z každé části by se pak udělaly funkce (callbacky). Každý callback by musel všechna data, která potřebuje, dostávat jako argumenty. "Globální stack" by potom spočíval v seznamu callbacků spolu s jejich argumenty a podmínkami, za kterých můžou běžet. Scheduler by pak prostě jenom z tabulky náhodně vybral callback, u nehož jsou podmínky splněné, a spustil ho.

Prostě princip podobný futures, resp. async/await, ale s jinou motivací a ruční implementací.

257

Vývoj / CSP v embedded světě

« kdy: 14. 03. 2021, 23:36:08 »

Čau,

snad nevadí, když nepoložím dotaz, ale (zne|vy)užiju fóra k neformálnímu brainstormingu.

V sousedním vlákně jsme s Idrisem narazili na myšlenku [1], která mi nedá spát.

V krátkosti shrnu:

• knihovna pro embedded (tj. systémy přibližně velikosti ARM Cortex M0-3, RAM v řádu desítek až menších stovek kB)
• API založené od základu na event-driven přístupu
• programování využívající co nejvíc principy CSP [2]

Aniž bych si udělal nějaký větší research, zkusil jsem si představit, jestli by se dalo pro zábavu naprogramovat v C aspoň malé demo/technology preview takové knihovny. Komunikační primitiva, scheduling nejsou problém, nějaký jednoduchý virtuální stroj si případně taky umím představit. Co mi ale dělá vrásky, jsou procesy. Ty totiž musí být vytvořitelné dynamicky a knihovna jich musí zvládat potenciálně "velké" množství (definici "velké" zatím nechme být, řekněme třeba desítky?) A pokud se chceme bavit o konkurentnosti, každý proces musí mít vlastní stack. Alespoň v nějaké standardní, přímočaré implementaci.

A to už začíná být v embedded problém. Stacky musí být vyhrazené, dostatečně velké a naplno se zaplní jenom občas, navíc typicky ne naráz. Takže dost neefektivní využití paměti. A co je horší - člověk těžko získá nějakou jistou garanci, že stack bude vždy stačit. Pokud vím, obvykle se prostě nastaví "dostatečně velký", což se ale dá udělat třeba u FreeRTOSu s pár statickými tasky ručně, ale ne u předpokládaného hodně dynamického systému se spoustou procesů.

Takže otázka je, jestli vás nenapadá, čím by se daly klasické stacky nahradit, případě jestli by se nedala konkurentnost implementovat nějakým způsobem, který by problémem řídce využité a přesto potenciálně příliš malé paměti netrpěl.

Berte to prosím fakt jako brainstorming, takže žádná myšlenka není příliš pitomá nebo sci-fi, aby nemohla zaznít Jde o srandu a mentální cvičení, raketu tím řídit nehodlám, takže žádná křeč

[1] https://forum.root.cz/index.php?topic=24381.msg346418#msg346418
[2] https://en.wikipedia.org/wiki/Communicating_sequential_processes - tj. program je rozdělený na konkurentní procesy komunikující pomocí kanálů

258

Vývoj / Re:Arduino a knihovny

« kdy: 12. 03. 2021, 21:27:02 »

[Asi hlavne pro Idrise]

Tak mi to nedalo se na stav konkurentnosti v embedded Rustu aspon z rychliku nekouknout. Ciste subjektivni shrnuti po jenom par hodinach pruzkumu a zkouseni...

Hodne jsem valil bulvy na tenhle projekt: https://rtic.rs/0.5/book/en/ Hlavne proto, ze dobre ilustruje, jaky brutality se s Rustem daji delat, kdyz mu clovek rozumi. Makra vytezeny na maximum Je to fakt zajimavej framework, ale CSP to neni, protoze tasky musi byt staticky definovany (muzou se dynamicky planovat, ale nemuzou se - jestli jsem neco neprehlidl - uplne libovolne dynamicky vytvaret). A vysoka uroven garanci se dosahuje za cenu takove, jak to rict neurazlive... no, treba "komplikovane syntakticke ztuhlosti".

Viz https://github.com/rtic-rs/rtic-examples

Pak je taky zajimavy, ze v Rustu pro embedded (minimalne ARMv7) by mel uz fungovat async/await. Bohuzel samozrejme s jeho typickou nectnosti - "cervenomodry svet"[1] = vsechny dosavadni knihovny je na nej potreba naroubovat. Takze treba pro Blue Pill nejake knihovny jsou, ale v ruznem stavu rozvrtanosti Presne jak v Pythonu, kdyz s async/await zacal

Takze nejaky to technology preview CSPcka by se asi pomoci async/await napsat dalo, ale asi jenom pro vybranej hardware a na moznost solidnejsiho pouziti je potreba si jeste nejakou chvilku pockat...

Jinak je ale pekny, ze se v Rustu MCUs uz fakt programovat daji dost slusne (alespon teda ten Blue Pill, co jsem zkousel). A je to presne takova pecka, jakou jsem ocekaval - nejenom, ze se hlida bezpecnost pameti, to je v Rustu tak nejak samozrejmy, ale kompiler mi treba vynadal, ze na tomhle pinu s LEDkou blikat nemuzu, protoze je tam namapovanej debugger. Say WOW!

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

259

Vývoj / Re:Arduino inšpirácia

« kdy: 12. 03. 2021, 21:07:16 »

Vzhledem k tomu, ze k Arduinu sezenes hotove knihovny pro uplne vsechno, vysel bych spis z toho, jaka oblast te nejvic zajima a bavi. Ja jsem si treba dost vyhral se vsim moznym kolem pestovani (automatizace zalivani, sviceni, hydroponie, ...), ale daji se stavet roboti, letadla, daji se delat low power sensory posilajici data na velke vzdalenosti (LoRa), suprove se da vyhrat s domaci automatizaci. Moznosti jsou doslova nekonecne, takze se spis koukni kolem sebe, co te nejvic bavi, a pak si vymysli, co by se na tom dalo zautomatizovat nebo inovovat, vylepsit. I kdyby se to dalo treba za petistovku koupit, daleko vic cool je si to za 450Kc vyrobit

260

Vývoj / Re:Arduino a knihovny

« kdy: 10. 03. 2021, 17:33:57 »

osobně odzkoušeno, pracuje se s tím fakt dobře a Linux přímo pěkně podporuje i předávání dat).

BTW, data se předávají přes de facto kanály. Tohle kdyby se zabalilo do nějakýho toho CSP frameworku, tak by to byla úplná pecka.

Tohle protlač někomu jako diplomku, to by byla nádherná práce.

261

Vývoj / Re:Arduino a knihovny

« kdy: 10. 03. 2021, 17:31:37 »

Tohle uměl kdysi Edison, malinká destička (jako Pico) s Atomem (na kterém byl Linux) a vedle s Quarkem, kde běžel RT systém, takže Atom mohl klidně spát a různá měření apod. řešil Quark. Něco takového s ARMem (Intel na to fakt není, proto to taky vzdali) by byla paráda.

Skvělý je Beaglebone - přesně na tohle má dva PRU koprocesory, kde se dá dobře řešit RT, protože PRU má deterministické trvání instrukcí, takže se s tím dají dělat časovací divy (osobně odzkoušeno, pracuje se s tím fakt dobře a Linux přímo pěkně podporuje i předávání dat).

http://beagleboard.org/pru

262

Vývoj / Re:Arduino a knihovny

« kdy: 10. 03. 2021, 14:39:40 »

Pokročileší platformy to mají vyřešené, třeba ESP32 umí měřit mimo hlavní procesor a to dokonce i v deep sleep modu:

Tento konkrétní problém není problém měření, ale knihovny. DS18B20 potřebuje nějaký čas na změření hodnoty a její převod na patřičně formátované číslo a má na to asynchornní instrukce ("začni měřit", "už máš změřeno?" apod.)

Takže to s procesorem ani periferií nesouvisí, je to prostě právě relikt toho jednovláknového, ne-eventového arduinovského přístupu. I v této knihovně to jde používat asynchronně, jenom to není default, takže i v examplech se spíš používá busy waiting.

263

Vývoj / Re:API pre ziskanie ceny kryptomeny v urcitom case

« kdy: 09. 03. 2021, 20:31:18 »

https://min-api.cryptocompare.com/

264

Vývoj / Re:Arduino a knihovny

« kdy: 09. 03. 2021, 17:28:21 »

No a jak to máš se stabilitou programu a kam tu teplotu vypisuješ ? Já jsem k tomu chtěl použít ten "padající" web :-(

Nestavěj to nad AVR, kup si ESP32. Velmi dobrou inspirací by mohl být Wifi Teploměr od Petra Stehlíka, kompletně open source (https://teploty.info/).

Pokud bys AVR nutně chtěl, s ethernetem se budeš trápit. Lepší (ve smyslu "potenciálně stabilnější") je to propojit na normální PC (nebo SBC) pomocí nějakého sériového protokolu, já rád používám https://github.com/bakercp/PacketSerial

Vtipná vychytávka je použít SLIP a pomocí něj odesílat MQTT-SN pakety. Viz https://github.com/mprymek/mqtt-sn-slip

265

Vývoj / Re:Arduino a knihovny

« kdy: 09. 03. 2021, 17:21:13 »

Otázka je, kde najít hranici NIH.

To je podle mě nejtěžší otázka IT vůbec

266

Vývoj / Re:Arduino a knihovny

« kdy: 09. 03. 2021, 17:19:31 »

To PlatformIO vypadá podstatně profesionálněji. Chápu to dobře, že PlatformIO  je takové „Arduino pro více platforem“ (+a více hardware), takže tam můžu použít třeba i RTOS? A knihovny pro periferie a další to používá jiný než Arduino? Je to cca tak?

Nevím, jestli "profesionálněji", každopádně je to pohodlnější, komfortnější.

Já bych spíš řekl, že je to takové "apt pro bastlení" - řekneš si, pro jaký procesor píšeš, jaký chceš framework a jaké knihovny (u všeho si můžeš říct i verzi) a ono ti to samo pěkně všechno stáhne, včetně toolů, překladače... nemusíš vůbec nic řešit, celý to přeložíš a nahraješ jedním příkazem přímo z vanilla zdrojáků, nic nemusíš ručně stahovat kromě samotnýho Platformia.

Jo, RTOS můžeš použít několik. Ja jsem říkal, nejsnazší je asi ten FreeRTOS nad Arduino knihovnou ( https://platformio.org/lib/show/2093/STM32duino%20FreeRTOS ).

Jesti chceš, můžu ti pro BluePill připravit prázdný projekt, to je otázka chvilky.

267

Vývoj / Re:Arduino a knihovny

« kdy: 09. 03. 2021, 16:19:41 »

Jo, ale to asi není kompatibilní s tou hromadou špatně napsaných arduiních knihoven a examplů, ne? Právě to je jeden z důvodů proč používám Arduino, i když je to technickou kvalitou dost slabé - „potřebujeme sledovat teplotu v kamrlíku se serverem“ → připojím k Arduinu za $2 DHT22 za $2, Examples → DHT, Upload, hotovo. „Potřebuju udělat první krok pro ověření funkčnosti PLL“ → google „arduino adf4351“, připojím 5 drátů, Upload, ověřeno, a teď můžu začít s datasheetem zkoumat co která volba dělá.

Jak jsem říkal, Platformio podporuje několik frameworků a Arduino je jeden z nich - to "originál Arduino". Tj. pokud si v konfiguráku Platformia vybereš jako framework Arduino, udělá platformio přesně to samý jako to arduino-cli. Mělo by to být 100%ně kompatibilní.

Takže to, co popisuješ, bys s Platformiem udělal přesně stejně.

Tím jsem myslel že když spustím strings na hotovou binárku firmwaru, tak tam doslova je několikrát napsáno /home/jenda/.arduino15/packages/STM32/hardware/stm32/1.8.0/cores/arduino/.

Aha, tak to jsem nezkoušel, ale to spíš asi budou nějaký debug symboly nebo tak něco, ne?

268

Vývoj / Re:Arduino a knihovny

« kdy: 09. 03. 2021, 15:24:05 »

není pro to Arduino Makefile, takže to musím kompilovat buď z Arduino IDE nebo pomocí https://github.com/arduino/arduino-cli, což je gigantická Gočková binárka. Při každém buildu to analyzuje použité knihovny přes celé STM32 HAL, což trvá klidně 10 sekund.

Při použití Platformia obě tyhle věci odpadají. Zalinkovaný balast moc neumím posoudit. Pokud nějakou funkci nepoužiju, binárka se zmenší, takže to nějak funguje. Jestli kompletně správně, to nevím, zatím jsem to nepotřeboval řešit.

269

Vývoj / Re:Arduino a knihovny

« kdy: 09. 03. 2021, 15:21:12 »

Ale co když bych chtěl od toho víc? Pak mi přijde, že tam je obrovská propast - neexistuje tak široká komunita, neexistuje tolik návodů a knihoven, celé je to řádově složitější. Jak to vlastně programovat [pod linuxem, samozřejmě]? Jak to provázat s IDE a s jakým? Jak to rozumně debugovat?

Myslím, že nejrozumnější na domácí bastlení je Platformio. Jako IDE používám VS Code, ale to není nutný, šlo by použít jakýkoli jiný C/C++ IDE, platformio se dá v klidu ovládat z příkazové řádky (narozdíl od Arduina, kde to dost dlouho dobře nešlo).

Debugging mají STMka nativní, přes programátor. Ve VS Code je mysím pro to i podpora, ale jak dobře se to používá, nevím, zatím jsem si vždycky vystačil s jednoduchými výpisy i u složitějších projektů.

Kde vzít knihovny pro podporu periferií? Programovat to celé od nuly, nebo se chytit nějakého RTOS/frameworku? Jak to nejlíp projít krok za krokem od toho jednoduššího až po to složité?

To je z toho asi nejsložitější otázka. Pokud chceš hladký přechod z Arduina AVR, tak nejsnazší je použít Arduino. Pokud si chceš zkusit RTOS, tak opět cesta nejmenšího odporu je asi ten FreeRTOS nad Arduino, co jsem linkoval výš. Až by ti to přestalo stačit (pro domácí hraní spíš nepřestane), můžeš se posunout jinam. Platformio pro Blue Pill nabízí celkem šest frameworků, takže přechod jinam je otázka změny jednoho řádku, nemusíš kompletně překopávat žádné makefily, složitě integrovat knihovny atd.

Podpora periferií toho vlastního STMka bude ve všech těch frameworcích velmi slušná až výborná. Horší je to spíš s podporou všelijakých sensorů třetích stran. Tam si s STM32/Arduino oproti AVR/Arduino mírně pohoršíš. Velká část knihoven jde použít, ale ne všechny. Pokud z Arduina přejdeš třeba na LibOpenCM, budeš na tom výrazně hůř. Co se dá dělat, Arduino je prostě fakt rozšířené a knihoven je neuvěřitelné množství. Platformio má na webu prohledávání knihoven, můžeš se sám podívat, jestli tam najdeš všechno, co by tě zajímalo. Posuď sám: https://platformio.org/lib/search?query=framework:libopencm3%20%20platform:ststm32 vs https://platformio.org/lib/search?query=framework%253Aarduino%2520%2520platform%253Aststm32

Takže když to tak shrnu, jestli si chceš hrát, jdi cestou Platformio + VS Code + Arduino + [volitelně FreeRTOS]. Takhle budeš mít nejvíc muziky s nejmenší námahou a bolestí

270

Vývoj / Re:Arduino a knihovny

« kdy: 09. 03. 2021, 12:18:42 »

Ano, Martin Malý je legenda (viděl jsem nějaká videa a četl pár článků). Dobrých praktických bastlířských návodů a inspirace je asi dost, ale já to ale myslel spíš po softwarové stránce - jak se pracuje na RTOS nebo jak se dobré programátorské praktiky aplikuji v embedded a co tam je naopak úplně jinak. Tenhle level podle mě přesahuje běžnou Arduino kulturu.

Jo, sorry, špatně jsem četl. To máš pravdu, s touhle literaturou je to daleko horší. Něco jsem viděl, ale moc mě to nenadchlo. Navíc tyhle knížky pro "polodoborníky" jsou dost špatně dostupné a občas už docela zastaralé.