Arduino a knihovny

[Ondrej Nemecek]

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.

Ano, ale jestli tomu dobře rozumím, tak ten druhý procesor umožňuje pracovat mimo hlavní vlákno a mimo hlavní program, což je ještě o kus dál co se týče asynchronnosti. Nejspíš by tím šly implementovat asynchronní akce i v případech, kde periferie nemá asynchronní podporu nativně. Čili tyto případy řeší systémově ta platforma, což je právě posun oproti Arduino, kde záleží co umí periferie a příslušná knihovna.

[Reklama]

[Idris]

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.

Ano, ale jestli tomu dobře rozumím, tak ten druhý procesor umožňuje pracovat mimo hlavní vlákno a mimo hlavní program, což je ještě o kus dál co se týče asynchronnosti. Nejspíš by tím šly implementovat asynchronní akce i v případech, kde periferie nemá asynchronní podporu nativně. Čili tyto případy řeší systémově ta platforma, což je právě posun oproti Arduino, kde záleží co umí periferie a příslušná knihovna.

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.

[Kizarm]

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.

Existuje např.
https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html

[Idris]

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.

Existuje např.
https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html

To vypadá hodně slušně. Já tuhle oblast teď moc nesleduju, musím to dohnat

[Mirek Prýmek]

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

[Reklama]

[Mirek Prýmek]

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.

[Idris]

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.

Kdyby se v této oblasti prosadilo CSP (a korutiny), to by skutečně byla pecka.

Myslím, že na něčem takovém pracují v Eirsatu, ale od začátku pandemie jsem s nimi nebyl v kontaktu.

[Mirek Prýmek]

[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/

[Wrána diskuze]

............
zavedlo jednovláknový přístup.
.............

57 vláken ti jako nestačí hele

[Mirek Prýmek]

............
zavedlo jednovláknový přístup.
.............

57 vláken ti jako nestačí hele

To ale není Arduino knihovna. To je plánovač, který někdo napsal. Arduino knihovna žádné tasky neobsahuje ani nepodporuje, jenom interrupty. Což je právě ten problém.

[Idris]

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

Rust má async/await docela použitelné. CSP by zvládnul hravě. Jo, bylo by fajn, kdyby se Rust na MCU víc prosadil, třeba na úkor (Micro)Pythonu (to asi nehrozí) nebo (Tiny)Go.

[ivoszz]

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

Rust má async/await docela použitelné. CSP by zvládnul hravě. Jo, bylo by fajn, kdyby se Rust na MCU víc prosadil, třeba na úkor (Micro)Pythonu (to asi nehrozí) nebo (Tiny)Go.

Zeptal bych se, co ti nejvíc chybí (vadí) u TinyGo pro reálnější (polo profi) nasazení? Pod pojmem polo profi myslím samo domo výroba pro vlastní potřebu, ale už s jakýmsi garantovaným výsledkem a dlouhodobějším provozem. A neberu do úvahy omezenou nabídku driverů.

[Idris]

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

Rust má async/await docela použitelné. CSP by zvládnul hravě. Jo, bylo by fajn, kdyby se Rust na MCU víc prosadil, třeba na úkor (Micro)Pythonu (to asi nehrozí) nebo (Tiny)Go.

Zeptal bych se, co ti nejvíc chybí (vadí) u TinyGo pro reálnější (polo profi) nasazení? Pod pojmem polo profi myslím samo domo výroba pro vlastní potřebu, ale už s jakýmsi garantovaným výsledkem a dlouhodobějším provozem. A neberu do úvahy omezenou nabídku driverů.

Nic zásadního, akorát je to jen (vlastní) podmnožina Go, hodně věcí z "plného" Go tam chybí. Nedávno jsem četl, že vývoj TinyGo začal finančně podporovat přímo Google, tak třeba to rychle vypilují. Bylo by fajn mít Go-style CSP i na MCU (o tom je celé vedlejší vlákno).

[Mirek Prýmek]

Nic zásadního, akorát je to jen (vlastní) podmnožina Go, hodně věcí z "plného" Go tam chybí. Nedávno jsem četl, že vývoj TinyGo začal finančně podporovat přímo Google, tak třeba to rychle vypilují. Bylo by fajn mít Go-style CSP i na MCU (o tom je celé vedlejší vlákno).

Co konkrétně zásadnějšího tam chybí? Nikdy jsem to nezkoumal, ten zmíněnej nedostatek driverů je pro moje osobní potřeby blocker.

[Idris]

Nic zásadního, akorát je to jen (vlastní) podmnožina Go, hodně věcí z "plného" Go tam chybí. Nedávno jsem četl, že vývoj TinyGo začal finančně podporovat přímo Google, tak třeba to rychle vypilují. Bylo by fajn mít Go-style CSP i na MCU (o tom je celé vedlejší vlákno).

Co konkrétně zásadnějšího tam chybí? Nikdy jsem to nezkoumal, ten zmíněnej nedostatek driverů je pro moje osobní potřeby blocker.

Nemá to plnou podporu deferu a map třeba. Taky tam nejde recover, to by se zrovna na MCU hodilo. Největší problém je ale IMHO přítomnost GC, na MCU bych si rád alokaci paměti řídil sám, nebo aspoň přesně věděl, co se děje pod pokličkou.