Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: ivoszz 04. 03. 2021, 14:08:33

Název: Arduino a knihovny
Přispěvatel: ivoszz 04. 03. 2021, 14:08:33
Protože teď není až zas tak moc co dělat, pořídil jsem si nějaké Arduino klony a začal experimentovat. A protože jsem trochu víc na sw než na hw, začal jsem se hrabat i v sw knihovnách. A nemile mne překvapila jejich kvalita. Vše je zpravidla podřízeno jednoduchosti a rychlosti, objevují se i systematické chyby. Pro příklady typu blikání led nebo čtení teploty to vystačí, ale pokud začnete uvažovat nad nízkou spotřebou a optimalizací, začíná to být problém. Neobvyklé nejsou prázdné časové smyčky a podobné záležitosti, naprosto nevhodné pro dlouhodobé používání. Fóra jsou pak plná stížností, že nějaký program přestává fungovat po x hodinách nebo dnech.

Chtěl bych se zeptat zkušenějších, jak to řeší? Existují nějaké zdroje nebo ukázky, jak to správně řešit? Máte potřebu si upravovat knihovny, když děláte něco "profesionálnějšího"? Díky za každou odezvu a zkušenost.
Název: Re:Arduino a knihovny
Přispěvatel: Daniel Novotný 04. 03. 2021, 14:18:26
Jsou ty knihovny open source? Že by člověk mohl přímo opravovat ty chyby a dělat pull requesty v daných volně dostupných repozitářích.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 04. 03. 2021, 14:30:59
Záleží na HW, u něčeho hodně primitivního není smyčka s nopy nic divného. IMHO nejrozumnější je jasně oddělit logiku aplikace ("business logic") od nízkoúrovňových částí kódu, pro experimenty pak stačí třeba i pochybné knihovny a v případě potřeby se vymění jen ta nízkoúrovňová vrstva (podle HW a zaměření projektu třeba FreeRTOS, na něčem výkonnějším Linux apod.).
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 04. 03. 2021, 19:51:20
Arduino knihovny jsou otřesné skrz na skrz a nikde v profesionálním prostředí by se používat neměly. Je to kontroverzní názor, že Arduino tím nováčkům vlastně škodí - kvalita je špatná, některé koncepty to abstrahuje/skrývá až moc, a dokumentace je vyloženě k ničemu (v poslední iteraci dokumentace už dokonce i skrývají datové typy).

Lidem, co na tomhle uvízli, doporučuju většinou Zephyr (RTOS a ekosystém okolo od Linux Foundation), případně PlatformIO a tam si už něco naklikat (mbed).
Název: Re:Arduino a knihovny
Přispěvatel: Longin 04. 03. 2021, 20:22:09
Lidem, co na tomhle uvízli, doporučuju většinou Zephyr (RTOS a ekosystém okolo od Linux Foundation), případně PlatformIO a tam si už něco naklikat (mbed).
Hmmm a co když nejsem čistej softwérář, co právě nikdy neprogramoval pod Linuxem, ale jako "embeďák" chtěl bych se posunout z RTOS na něco takového? Co bys doporučil? Jak s tím začít?
Makefile, Linker apod nejsou pro mě sprostá slova.
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 04. 03. 2021, 20:44:00
Ten Zephyr je teď asi nejjednodušší volba. Dokumentace je výborná, práce s tím je podobná jako s jádrem Linuxu (stejnej styl konfigurace) a ve své podstatě to nic neskrývá — tj. uživatel si může užívat ty komfortní nástroje, ale když chce, může do toho snadno rejpat (je to v postatě taky jen čitelnej "Makefile").

Getting Started je na 20 minut včetně instalace toolchainu... stačí mít po ruce nějakou běžnou destičku s stm32 nebo něčím podobným a můžete blikat :-) https://zephyrproject.org/
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 04. 03. 2021, 20:49:46
Ještě mám rád ChibiOS, ten má fantastickou dokumentaci, je aktuální, má excelentní kernel i HAL (většinu driverů pro stm32). Je ale na dnešní dobu vyvíjen trochu zastaralým způsobem (maily, source force, ...).

Na stm32 obecně funguje velmi dobře libopencm3 - je to jen spousta pomocných funkcí a driverů pro různé MCU s Cortexem, tj. není to RTOS. Hello worldy jsou tam asi nejjednodušší - opravdu jen tucet řádků Cčka, linker script, a Makefile.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 05. 03. 2021, 12:50:49
Je to kontroverzní názor, že Arduino tím nováčkům vlastně škodí - kvalita je špatná, některé koncepty to abstrahuje/skrývá až moc, a dokumentace je vyloženě k ničemu (v poslední iteraci dokumentace už dokonce i skrývají datové typy).
Zaslechl jsem někde i ostřejší názor, že Arduino sice otevřelo embedded svět širokému publiku, ale zároveň vrátilo vývoj o deset let zpátky, protože místo RTOSu a asynchronního/event driven/task-based programování zavedlo jednovláknový přístup.

Nemůžu říct, že bych s tím nesouhlasil. Už nějakou dobu je vidět, že ten jednoduchý až stupidní setup/loop přístup přestává stačit a je velkou limitací. Tak se na to různě krkolomnými způsoby začínají roubovat přístupy jiné - od jednoduchého Taskeru přes (zatajené) interrupt handlery až po zabalení FreeRTOSu do setup/loop high-level kabátu...

Naopak ale na Arduinu fakt oceňuju, že se z něj stal extrémně rozšířený HAL. Pokud je člověk s projektem v nějaké objevovací fázi, je fakt nejjednodušší použít Arduino (právě jako HAL), protože pak může s nulovým úsilím přejít na úplně jiný hardware.

Ještě mám rád ChibiOS
Souhlas, mám na něj taky skvělé vzpomínky, v současnosti ale nepoužívám (žádnej racionální důvod to nemá, prostě jsem ho nějak poslední dobou nepotřeboval).

Na stm32 obecně funguje velmi dobře libopencm3
Taky souhlas. Slušná, snadno použitelná knihovna se slušnou dokumentaci.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 05. 03. 2021, 13:34:34
zabalení FreeRTOSu do setup/loop high-level kabátu
To dělá kdo? Slušnej úlet...
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 05. 03. 2021, 13:43:30
zabalení FreeRTOSu do setup/loop high-level kabátu
To dělá kdo? Slušnej úlet...
Např. https://platformio.org/lib/show/2093/STM32duino%20FreeRTOS

Zas takovej úlet to není, je to prostě normální FreeRTOS, akorát je to přibalený k Arduino knihovnám, "main" se de facto jmenuje "setup" a config FreeRTOSu je schovanej někde v útrobách, takže se myslím dost dobře nedá upravovat. Ale používat se to dá - pokud si někdo chce FreeRTOS zkusit, zná Arduino a nechce se mu řešit nějaké krkolomné HAL knihovny, je to docela fajn.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 05. 03. 2021, 13:59:03
zabalení FreeRTOSu do setup/loop high-level kabátu
To dělá kdo? Slušnej úlet...
Např. https://platformio.org/lib/show/2093/STM32duino%20FreeRTOS
Ta funkce loop je v tom kódu fakt zajímavá...
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 05. 03. 2021, 14:44:39
Ta funkce loop je v tom kódu fakt zajímavá...
Hlavně je tam jenom na okrasu, protože main task se zastaví na tom while(1) v setupu. EDIT: Teda respektive na startu scheduleru před tím, pokud nezhavaruje.

Je to trochu bizár, ale tak proč ne, hlavně že je to užitečný.
Název: Re:Arduino a knihovny
Přispěvatel: fortran1986 05. 03. 2021, 14:58:58
Kua ja sa som sa tiež nechal ovplyvniť reklamou na facebooku na VisualMicro (nejaké Audrino IDE pre Visual Studio) a keďźe som na to pár krát zo zvedavosti klikol, google ad sense mi začal zobrazovať (na Amazone, Aliexpresse a Banggood) reklamu na rôzne zaujímavé súčiastky pre audrino a ja som na to všetko pažravo klikal a objednával. Nakoniec som si kúpil na Amazone Audrino Starter pack + ELEGOO Starter Pack + Sadu senzorov a ďalšie veci či už originál dosku tak aj pár lacných čínskych klonov. Dnes mi to doviezol kurie v takých plastových kufríkoch.

Natom predraženom originále (Audrino UNO R3) sa to plánujem učiť a pri reálnej aplikácii chcem potom používať tie lacné čínske dosky. Už som do toho zainvestoval cca 150 EURO (ak počítam profi spájkovačku, náradie do dielne a profi meracie prístroje (LCR meter, multimeter, osciloskop) tak možno aj 500 euro). Dnes mi priniesol kurier tú základnú sadu. A plánujem si večer začať tutorial.

Velice sa na to teším, kúpil som si to preto lebo sa chcem venovať C++ a low level programovaniu, ale ak som správne pochopil z podobných fór tak audrino je nakoniec v nejakom vlastnom jazyku? Čo je vlastne Cčko a nejaké makrá?

Dá sa pre audrino kódiť aj v normálnom C++? so všetkým čo k tomu patrí (templaty, classy, type traity atď)? lebo ešte som sa na to nepozeral (som v práci), ale už sa na to teším, ak sa to naučím, tak by som to mohol ponúkať ako službu.

Robiť rôzne riěšenia do domu, alebo do auta na zákazku (vrámci voľného času) A neskôr keby sa mi v tom darilo tak by som nahradil moj terajší zdroj obživy (FE development v ReactJS), tým čo ma baví naj-viac (elektronika a low level programovanie v C++).
Název: Re:Arduino a knihovny
Přispěvatel: Idris 05. 03. 2021, 15:00:26
Ta funkce loop je v tom kódu fakt zajímavá...
Hlavně je tam jenom na okrasu [...] Je to trochu bizár
Však právě. Ale jinak hezký přiohnutí...
Název: Re:Arduino a knihovny
Přispěvatel: Idris 05. 03. 2021, 15:06:41
Dá sa pre audrino kódiť aj v normálnom C++? so všetkým čo k tomu patrí (templaty, classy, type traity atď)?
Nedávno si někdo stěžoval, že tam nejsou výjimky, takže osekané to asi je, ale přežít se to dá. Už to nějakou dobu nesleduju, třeba to někdo s aktuální znalostí potvrdí/vyvrátí.
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 05. 03. 2021, 16:53:32
Pro ESP8266 a ESP32 se dá vyvíjet v Micropython, Lua (+ ve standardním Arduino IDE). Pro řadu použití je to IMHO celkem zajímavá alternativa k Arduino s wifi jakožto bonusem. 

ESP čipy jsou i ve spoustě spotřebních zařízení (např. chytrá zásuvka z OBI s ESP8266 - hotový kus hw, kam si můžete skvěle dobastlit další funkce, čidla, displej, atd.)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 05. 03. 2021, 23:05:26
Nedávno si někdo stěžoval, že tam nejsou výjimky, takže osekané to asi je, ale přežít se to dá. Už to nějakou dobu nesleduju, třeba to někdo s aktuální znalostí potvrdí/vyvrátí.
Preklada se normalnim C++ prekladacem, akorat zdrojaky jsou predtim specialne predzpracovane. Staci si zapnout verbose compilation a clovek to vidi, co se tam deje. Takze normalni C++ pouzit jde, neni to zadny "specialni jazyk" (navzdory urban legends).

Samozrejme jina otazka je, co pouzivaji a podporuji knihovny.

Specialne pak z duvodu, jak preklad probiha, byva (byvala?) tendence cpat do hlavickoveho souboru i implementaci, ktera by se do nej v "normalnim" C++ nedavala.

(http://www.sharetechnote.com/image/Arduino_Build_Verbose_02.png)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 05. 03. 2021, 23:14:21
Robiť rôzne riěšenia do domu, alebo do auta na zákazku (vrámci voľného času) A neskôr keby sa mi v tom darilo tak by som nahradil moj terajší zdroj obživy (FE development v ReactJS), tým čo ma baví naj-viac (elektronika a low level programovanie v C++).
To neni tak zabavny ani lukrativni, jak se to mozna na prvni pohled zda. Vyvoj HW je vyrazne narocnejsi, drazsi a rizikovejsi nez vyvoj software. Vysoka cena vyvoje se musi bud rozpocitat do (sta)tisicovych serii nebo musi jit o nejakou oblast, kde ve vzduchu litaji opravdu velke castky (a pak to zas nikdo nesveri amaterovi).

Tim nechci od bastleni odrazovat, v zadnym pripade, je to skvela zabava a seberozvoj, ale spis je to o bastleni si pro sebe a pro kamarady, nebo o klasickym zamestnani v nejake firme, nez ze by z toho koukaly nejake snadne miliony, ktere jenom cekaji, az se pro ne nejaky amater* sehne :)

---
* "amater" neni mysleno pejorativne. Ja jsem v hw taky amater - samouk.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 00:04:59
Nedávno si někdo stěžoval, že tam nejsou výjimky, takže osekané to asi je, ale přežít se to dá. Už to nějakou dobu nesleduju, třeba to někdo s aktuální znalostí potvrdí/vyvrátí.
Preklada se normalnim C++ prekladacem, akorat zdrojaky jsou predtim specialne predzpracovane. Staci si zapnout verbose compilation a clovek to vidi, co se tam deje. Takze normalni C++ pouzit jde, neni to zadny "specialni jazyk" (navzdory urban legends).

Samozrejme jina otazka je, co pouzivaji a podporuji knihovny.

Specialne pak z duvodu, jak preklad probiha, byva (byvala?) tendence cpat do hlavickoveho souboru i implementaci, ktera by se do nej v "normalnim" C++ nedavala.

(http://www.sharetechnote.com/image/Arduino_Build_Verbose_02.png)
Taky to je o nestandardních nastaveních, třeba ty výjimky jsou prostě jen vypnuté (protože kód pro unwinding je poměrně velký a vesměs nepotřebný).
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 00:08:05
Taky to je o nestandardních nastaveních, třeba ty výjimky jsou prostě jen vypnuté (protože kód pro unwinding je poměrně velký a vesměs nepotřebný).
Jo, to je možný, nevím, C++ se dvacet let vyhýbám jak čert kříži.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 01:00:24
Taky to je o nestandardních nastaveních, třeba ty výjimky jsou prostě jen vypnuté (protože kód pro unwinding je poměrně velký a vesměs nepotřebný).
Jo, to je možný, nevím, C++ se dvacet let vyhýbám jak čert kříži.
Co máš proti C++?
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 01:01:27
Co máš proti C++?
Spíš nemám nic pro :)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 01:07:06

Co máš proti C++?
Spíš nemám nic pro :)
Ale píšeš "dvacet let", tos přeskočil C++03, C++11 atd. V podstatě úplně jiný jazyk...
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 01:09:07
Ale píšeš "dvacet let", tos přeskočil C++03, C++11 atd. V podstatě úplně jiný jazyk...
Hm. A vůbec mi to neva :)
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 06. 03. 2021, 10:52:49
Nedávno si někdo stěžoval, že tam nejsou výjimky, takže osekané to asi je, ale přežít se to dá. Už to nějakou dobu nesleduju, třeba to někdo s aktuální znalostí potvrdí/vyvrátí.

avr-g++ backend výjimky nepodporuje, takže se podle dokumentace (http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus) musí front-endu předávat -fno-exceptions. Možná s Clangem by to šlo? Nebo rovnou s Rustem nebo Zigem, obojí má standardní error handling i na AVR. Ten poslední jmenovanej je na osmibitech raketa :-)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 11:21:38
Nedávno si někdo stěžoval, že tam nejsou výjimky, takže osekané to asi je, ale přežít se to dá. Už to nějakou dobu nesleduju, třeba to někdo s aktuální znalostí potvrdí/vyvrátí.

avr-g++ backend výjimky nepodporuje, takže se podle dokumentace (http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus) musí front-endu předávat -fno-exceptions. Možná s Clangem by to šlo? Nebo rovnou s Rustem nebo Zigem, obojí má standardní error handling i na AVR. Ten poslední jmenovanej je na osmibitech raketa :-)
Taky jsem pro Rust bez výjimek :)
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 06. 03. 2021, 11:29:14
MicroPython (nebo fork CircuitPython) je skvělá věc, když si to můžete dovolit (chce dost ROM i RAM). Máte pak v podstatě i na mikrokontroleru ekvivalent ssh přístupu a dá se velmi dobře ladit a vyvíjet. Na ESP s MicroPythonem to jde i přes wifi, over-the-air updaty jsou automaticky k dispozici.

Co se Arduino knihoven týče, ani mi tolik nevadí ta organizace do setup/loop funkcí. Je to primitivní, ale nic mě nenutí to používat - chovám se k setup() jako k main(), a v ní si napíšu vlastní event loop nebo cokoliv chci. Nebo jejich main.c s vyhodím úplně a používám vlastní main.c s klasickou funkcí main.

Co mi na nich vadí je ta kvalita. Je to jak kdyby někdo vzal desktop program a jen ho portoval na free-standing AVR. Všude drahý lookupy, zbytečný volání funkcí bez cachingu, ve standardní knihovně se používá heap, což je na mikru s několika sty bajty paměti sebevražda, atd.

Ale lidi jsou nepoučitelný. Rok co rok dělám na projektech, kde firma nejprve udělala proof of concept na Arduinu, pak si řekli "počkat, ono to už funguje!" a místo opravdového vývoje jen vzali Arduino a překlopili ho na custom desku. Po roce "dolaďování" bývají obvykle připravení to zahodit i s rukama :-) protože AVR je finanční a časová sebevražda.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 15:15:51
Co se Arduino knihoven týče, ani mi tolik nevadí ta organizace do setup/loop funkcí. Je to primitivní, ale nic mě nenutí to používat - chovám se k setup() jako k main(), a v ní si napíšu vlastní event loop nebo cokoliv chci.
On je problém spíš v tom "jednovláknovém přístupu", který Arduino nastolilo. Spousta knihoven obsahuje delaye, blokující čekání apod., což je úplně zbytečný.

Ale lidi jsou nepoučitelný. Rok co rok dělám na projektech, kde firma nejprve udělala proof of concept na Arduinu, pak si řekli "počkat, ono to už funguje!" a místo opravdového vývoje jen vzali Arduino a překlopili ho na custom desku. Po roce "dolaďování" bývají obvykle připravení to zahodit i s rukama :-) protože AVR je finanční a časová sebevražda.
Takhle absolutně to těžko můžeš říct. Je to prostě procesor jako jakejkoliv jinej. My třeba ve firmě máme produkt postavenej na AVR a funguje, prodané jsou desetitisíce.

Akorát teda dneska už AVR moc nedává smysl, už je poněkud za zenitem :)
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 06. 03. 2021, 15:43:47
Jo, myslel jsem to v nových produktech. Vídám běžně IoT projekty staré 1-2 roky, kde se začalo na Arduinu, pak se postupně nabalovaly periferie, a výsledek je ATMega2560 za 250 Kč, kolem ní další tisícovka v periferiích (RTC, Ethernet, CAN, lepší ADC atd.), a k tomu neskutečná doba zabitá hackováním kolem těch nejtriviálnějších problémů (například aby to umělo odeslat HTTPS GET). Přitom "moderní" (8 let staré) STM32 to všechno integruje za slabou stokorunu, knihovny s běžnou funkcionalitou na tom normálně fungují, není třeba šít na koleni SSL. V lidech pořád existuje jakýsi mem, že AVR = prověřená a stabilní věc (protože nečetli errata :) zatímco cokoliv novějšího je risk.

Myslím, že právě Arduino má prsty v tom odporu k RTOS, co vídám - operační systém nechceme, protože je to další point of failure, ale klidně postavíme aplikaci s gigantickou MotherOfAllMainLoops, ve které může kterákoliv pochybná knihovna blokovat :-)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 16:30:37
On je problém spíš v tom "jednovláknovém přístupu", který Arduino nastolilo. Spousta knihoven obsahuje delaye, blokující čekání apod., což je úplně zbytečný.
"Jednovláknový" neznamená "blokující", klasické "non-blocking IO" (i ne-IO) je jednovláknové.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 16:33:18
Myslím, že právě Arduino má prsty v tom odporu k RTOS, co vídám - operační systém nechceme, protože je to další point of failure, ale klidně postavíme aplikaci s gigantickou MotherOfAllMainLoops, ve které může kterákoliv pochybná knihovna blokovat :-)
To zní skoro hororově...

Trochu odbočím: Nějaký tip na knihovny/OS pro eZ80?
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 16:34:45
Jo, myslel jsem to v nových produktech. Vídám běžně IoT projekty staré 1-2 roky, kde se začalo na Arduinu, pak se postupně nabalovaly periferie, a výsledek je ATMega2560 za 250 Kč, kolem ní další tisícovka v periferiích (RTC, Ethernet, CAN, lepší ADC atd.), a k tomu neskutečná doba zabitá hackováním kolem těch nejtriviálnějších problémů (například aby to umělo odeslat HTTPS GET). Přitom "moderní" (8 let staré) STM32 to všechno integruje za slabou stokorunu, knihovny s běžnou funkcionalitou na tom normálně fungují, není třeba šít na koleni SSL. V lidech pořád existuje jakýsi mem, že AVR = prověřená a stabilní věc (protože nečetli errata :) zatímco cokoliv novějšího je risk.
Jasný, tak to máš každopádně pravdu. Dneska stavět cokoli kromě nejprimitivnějších sensorů na AVR nedává moc smysl a ten nedostatek periferií a RAMky je děsná limitace.

Myslím, že právě Arduino má prsty v tom odporu k RTOS, co vídám - operační systém nechceme, protože je to další point of failure, ale klidně postavíme aplikaci s gigantickou MotherOfAllMainLoops, ve které může kterákoliv pochybná knihovna blokovat :-)
Je to možný. Anebo je to už jenom tím názvem. Někdo slyší "OS", představí si Windows a už vidí, jak bude mít problémy s balastem pitomostí v registrech :))) Proto je potřeba si nějakej RTOS vyzkoušet, aby člověk zjistil, že to je vlastně jenom přepínání konktextu a primitivní semafory a fronty :)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 16:36:34
Trochu odbočím: Nějaký tip na knihovny/OS pro eZ80?
Proč?
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 16:44:29
Trochu odbočím: Nějaký tip na knihovny/OS pro eZ80?
Proč?
Protože to je super procesor.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 19:02:29
Protože to je super procesor.
Na hraní, kvůli kompatibilitě se Z80, nebo kvůli něčemu jinýmu?
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 19:05:35
Protože to je super procesor.
Na hraní, kvůli kompatibilitě se Z80, nebo kvůli něčemu jinýmu?
Do produkce, je směšně levný, superskalární a zvládá 16 MB RAM, což je v embedded segmentu docela luxus. (Ta kompatibilita se Z80 je v dnešní době podružná až nedůležitá.)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 20:53:05
Do produkce, je směšně levný, superskalární a zvládá 16 MB RAM, což je v embedded segmentu docela luxus. (Ta kompatibilita se Z80 je v dnešní době podružná až nedůležitá.)
To je zajímavý. Ale slyším o něm teda poprvé, nijak zvlášť se asi nepoužívá.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 21:23:03
Do produkce, je směšně levný, superskalární a zvládá 16 MB RAM, což je v embedded segmentu docela luxus. (Ta kompatibilita se Z80 je v dnešní době podružná až nedůležitá.)
To je zajímavý. Ale slyším o něm teda poprvé, nijak zvlášť se asi nepoužívá.
Používá se dost, ale nejsou k němu kity na hraní (kdysi byly). Je nativně 24-bitový a třístupňově superskalární, takže poměrně rychlý. Ideální pro RT s nízkým příkonem.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 06. 03. 2021, 22:00:28
Používá se dost, ale nejsou k němu kity na hraní (kdysi byly). Je nativně 24-bitový a třístupňově superskalární, takže poměrně rychlý. Ideální pro RT s nízkým příkonem.
Na Wikipedii mě zaujalo "equally predictable when it comes to exact execution times", což mi teda nejde dohromady s těma pajplajnama, ale tak třeba jsou deterministické, nebo to tvrzení nesmím brát tak doslova :)
Název: Re:Arduino a knihovny
Přispěvatel: FKoudelka 06. 03. 2021, 22:02:19
Protože teď není až zas tak moc co dělat, pořídil jsem si nějaké Arduino klony a začal experimentovat. A protože jsem trochu víc na sw než na hw, začal jsem se hrabat i v sw knihovnách. A nemile mne překvapila jejich kvalita. Vše je zpravidla podřízeno jednoduchosti a rychlosti, objevují se i systematické chyby. Pro příklady typu blikání led nebo čtení teploty to vystačí, ale pokud začnete uvažovat nad nízkou spotřebou a optimalizací, začíná to být problém. Neobvyklé nejsou prázdné časové smyčky a podobné záležitosti, naprosto nevhodné pro dlouhodobé používání. Fóra jsou pak plná stížností, že nějaký program přestává fungovat po x hodinách nebo dnech.
Mezi svátky jsem se nudil a vydal jsem se toutéž cestou. Koupil jsem originál arduino uno , doporučený zdroj 12 V a ethernet shield, abych si postavil jednoduchý web, s použitím Arduino knihoven. (Jen pro test dostupnosti).
 Byl jsem nadšený, do 30 minut od vybalení to jelo. Asi tak den.
Tak jsem začal pátrat. Kromě modifikace jednoho pinu mi bylo doporučeno, že se to hřeje kvůli (doporučeným) 12V, ať tam dám 7V zdroj. No nebudu se rozepisovat, postupně jsem vystřídal asi 4 zdroje, různá voltáž, přes USB nebo Jack - různý TTL. Teď jsem na 9V Jack a vydrží  mi to už týden :-O (Ironie). Program a knihovny pořád ty stejné.
Jak jsem to vyřešil ? Půjde to do .... šuplete.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 06. 03. 2021, 22:20:29
Používá se dost, ale nejsou k němu kity na hraní (kdysi byly). Je nativně 24-bitový a třístupňově superskalární, takže poměrně rychlý. Ideální pro RT s nízkým příkonem.
Na Wikipedii mě zaujalo "equally predictable when it comes to exact execution times", což mi teda nejde dohromady s těma pajplajnama, ale tak třeba jsou deterministické, nebo to tvrzení nesmím brát tak doslova :)
Ty pajplajny jsou celkem primitivní, žádná intelí černá magie.
Název: Re:Arduino a knihovny
Přispěvatel: Tomas-T 07. 03. 2021, 20:23:39
Mezi svátky jsem se nudil a vydal jsem se toutéž cestou. Koupil jsem originál arduino uno , doporučený zdroj 12 V a ethernet shield, abych si postavil jednoduchý web, s použitím Arduino knihoven. (Jen pro test dostupnosti).
 Byl jsem nadšený, do 30 minut od vybalení to jelo. Asi tak den.
Tak jsem začal pátrat. Kromě modifikace jednoho pinu mi bylo doporučeno, že se to hřeje kvůli (doporučeným) 12V, ať tam dám 7V zdroj. No nebudu se rozepisovat, postupně jsem vystřídal asi 4 zdroje, různá voltáž, přes USB nebo Jack - různý TTL. Teď jsem na 9V Jack a vydrží  mi to už týden :-O (Ironie). Program a knihovny pořád ty stejné.
Jak jsem to vyřešil ? Půjde to do .... šuplete.
Loni na jaře jsem měl v práci volněji tak jsem dostal interní úkol IoT - spáchat něco co bude kontrolovat kvalitu vzduchu v kanceláři a upozorňovat, pokud je pořeba vyvětrat.
Trochu jsem si zadání rozšiřil, krabička měří teplotu, vlhkost, tlak, CO2, organické plyny, hluk, světlo a pohyb v okolí. Frekvence skenování 1x za sekundu, frekvence odesílání dat přes wifi na server 1x za minutu. Na serveru pak běží webová služba ukládající data do databáze vyhodnocující limity a rozesílající maily. K tomu pak aplikace pro zobrazování dat v grafech a konfiguraci limitů, email adres  a pár dalších věcí.
Krabičku založenou na ESP32 + hromádku senzorů jsem v kanceláři na stole zapnul v srpnu 2020 od té doby běží bez výpadku (nebo zaseknutí řeší automaticky nějaký interní HW watchdog) já v kanceláři od září nejsem jen přes VPN - za mě se spolehlivostí a funkčností spokojenost.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 07. 03. 2021, 21:55:23
Mezi svátky jsem se nudil a vydal jsem se toutéž cestou. Koupil jsem originál arduino uno , doporučený zdroj 12 V a ethernet shield, abych si postavil jednoduchý web, s použitím Arduino knihoven. (Jen pro test dostupnosti).
 Byl jsem nadšený, do 30 minut od vybalení to jelo. Asi tak den.
Tak jsem začal pátrat. Kromě modifikace jednoho pinu mi bylo doporučeno, že se to hřeje kvůli (doporučeným) 12V, ať tam dám 7V zdroj. No nebudu se rozepisovat, postupně jsem vystřídal asi 4 zdroje, různá voltáž, přes USB nebo Jack - různý TTL. Teď jsem na 9V Jack a vydrží  mi to už týden :-O (Ironie). Program a knihovny pořád ty stejné.
Jak jsem to vyřešil ? Půjde to do .... šuplete.
Loni na jaře jsem měl v práci volněji tak jsem dostal interní úkol IoT - spáchat něco co bude kontrolovat kvalitu vzduchu v kanceláři a upozorňovat, pokud je pořeba vyvětrat.
Trochu jsem si zadání rozšiřil, krabička měří teplotu, vlhkost, tlak, CO2, organické plyny, hluk, světlo a pohyb v okolí. Frekvence skenování 1x za sekundu, frekvence odesílání dat přes wifi na server 1x za minutu. Na serveru pak běží webová služba ukládající data do databáze vyhodnocující limity a rozesílající maily. K tomu pak aplikace pro zobrazování dat v grafech a konfiguraci limitů, email adres  a pár dalších věcí.
Krabičku založenou na ESP32 + hromádku senzorů jsem v kanceláři na stole zapnul v srpnu 2020 od té doby běží bez výpadku (nebo zaseknutí řeší automaticky nějaký interní HW watchdog) já v kanceláři od září nejsem jen přes VPN - za mě se spolehlivostí a funkčností spokojenost.
FKoudelka mluví o Arduinu Uno s ethernet shieldem a ty o ESP32. Takže to je asi tak jakoby někdo nadával, že mu Trabant jede špatně a tys na to reagoval, že s Porsche jsi nezaznamenal žádný problém :)

Ethernet shieldy pro Arduino Uno opravdu jsou problematické samy o sobě (speciálně ENC28J60) a knihovny navíc nejsou moc kvalitní. Takže to opravdu moc stabilní být nemusí. Důvodů může být spousta, od sice deterministických, ale pro nováčka těžko odhalitelných, přes černou magii (HTTP komunikace je už docela na hranici toho, co má smysl s AVR dělat, takže stačí mít tam pár nešťastných dynamických alokací a nedeterministické padání je na světě...) až po opravdu hw problémy. ESP32 s pohodlným dostatkem paměti a zabudovaným wifi chipem je úplně jiný případ.
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 07. 03. 2021, 23:36:52
Pro začátečníka je nelehké se v „Arduino“ světe vyznat - různý hw (nejen ATmega328 ale taky třeba zmíněné ESP32 nebo taky STM32), k tomu různé knihovny a navíc Arduino IDE. A většina zdrojů opomíjí některá témata, třeba výběr adekvátního hw, vhodné programátorské postupy nebo právě informace o RT systémech. Podle mě moho Arduino bastlířů ani pořádně neví, jak to pod kapotou funguje (IMHO trochu didaktická chyba, pokud to měl být původě hlavně vzdělávací projekt). To tak nějak i koreluje s úrovní knihoven a setup/loop() mantrou (nic proti, ale bylo by asi fajn mít i pokročilejší možnosti, které se ostatně mohou ledaskdy i snáze používat).

Chci tím třeba říct, že třeba netuší, co může čekat (co získá) pokud bude (s Arduino IDE) používat místo Arduina třeba STM32 BluePill.
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 08. 03. 2021, 00:08:59
Ono to bude souviset s tím, že Arduino původně vůbec neměla být vzdělávací platforma (a podle některých není ani dnes). Vzniklo to někdy kolem roku 2005 jako jednoduchej nástroj pro umělce, kteří si chtějí rozblikat nějakou svoji instalaci, aniž by se zbytečně museli něco učit.

The objective of the thesis was to make it easy for artists and designers to work with electronics, by abstracting away the often complicated details of electronics so they can focus on their own objectives.

https://arduinohistory.github.io/
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 01:54:38
Ono to bude souviset s tím, že Arduino původně vůbec neměla být vzdělávací platforma (a podle některých není ani dnes). Vzniklo to někdy kolem roku 2005 jako jednoduchej nástroj pro umělce, kteří si chtějí rozblikat nějakou svoji instalaci, aniž by se zbytečně museli něco učit.

The objective of the thesis was to make it easy for artists and designers to work with electronics, by abstracting away the often complicated details of electronics so they can focus on their own objectives.

https://arduinohistory.github.io/
Hm, to hodně vysvětluje. Vzdělávání v této oblasti by mělo být zaměřené na asynchronní, událostmi řízené aplikace. To je asi jen zbožné přání.
Název: Re:Arduino a knihovny
Přispěvatel: Longin 08. 03. 2021, 08:10:15
Také to vysvětluje, proč se vyrojilo tolik "odborníků", co si myslí, že jsou embeďáci. :D
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 11:23:29
Také to vysvětluje, proč se vyrojilo tolik "odborníků", co si myslí, že jsou embeďáci. :D
Nestačí umět používat setup/loop? :D
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 08. 03. 2021, 19:11:58
Hm, to hodně vysvětluje. Vzdělávání v této oblasti by mělo být zaměřené na asynchronní, událostmi řízené aplikace. To je asi jen zbožné přání.
To by bylo moc pěkný téma na celodenní brainstorming+hackaton.

Prvně si vyjasnit, co myslím slovem "vzdělání" - u Arduina a podobných popularizačních projektů to imho není "naučit dobré základy pro seriozní vývoj v embedded", ale spíš "poskytnout děckám a jiným laikům co nejvíc cool quick win, abysme je vůbec k zájmu o techniku přitáhli" (a tohle se mu imho daří fantasticky, alespoň v mojí generaci, u mladších si tím nejsem jistej).

Udělat něco, co by poskytlo podobně nízkoprahový quick win a zároveň neučilo špatným návykům, to by byla fakt výzva. Protože bohužel v C ten asynchronní, událostmi řízený kód vyžaduje spoustu ne moc srozumitelné bižuterie, která by asi laiky dost odrazovala. Možná by šel zbastlit nějakej pěknej, čistej framework v Rustu nebo Go?

Byl by to super hackaton, úplně to vidím, hned bych do toho šel :)
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 08. 03. 2021, 20:24:00
Prvně si vyjasnit, co myslím slovem "vzdělání" - u Arduina a podobných popularizačních projektů to imho není "naučit dobré základy pro seriozní vývoj v embedded", ale spíš "poskytnout děckám a jiným laikům co nejvíc cool quick win, abysme je vůbec k zájmu o techniku přitáhli" (a tohle se mu imho daří fantasticky, alespoň v mojí generaci, u mladších si tím nejsem jistej).

Mě by se líbilo to samé, ale pro programátory, tj. zprostředkovat pokročilejším vývojářům  specifika a různé možnosti v přístupu k embedded vývoji. Klidně to udělat na základě nějaké existující vývojové desky (nevím zda se na to hodí Arduino, ale třeba ten ESP nebo STM32 mi přijde vhodný určitě). Věřím že spousta programátorů si ráda pohraje nebo se jim to bude hodit v nějakém projektu.

Udělat něco, co by poskytlo podobně nízkoprahový quick win a zároveň neučilo špatným návykům, to by byla fakt výzva. Protože bohužel v C ten asynchronní, událostmi řízený kód vyžaduje spoustu ne moc srozumitelné bižuterie, která by asi laiky dost odrazovala. Možná by šel zbastlit nějakej pěknej, čistej framework v Rustu nebo Go?

Tak mě přijde, že by šel klidně zahrnout i docela vysokoúrovňový přístup, četl jsem o robotech programovaných v Smalltalku apod. Události, fronty, zpracování streamů, hlídání limitů - IMHO podle mě ideální pro řadu aplikací. A zkušenější programátoři se s tím už určitě setkali jinde, navíc je tu synergie se současným trendem mikroslužeb. To by bylo ideální téma na Arduino v2.0 nebo konkurenční projekt.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 20:26:32
Prvně si vyjasnit, co myslím slovem "vzdělání" - u Arduina a podobných popularizačních projektů to imho není "naučit dobré základy pro seriozní vývoj v embedded", ale spíš "poskytnout děckám a jiným laikům co nejvíc cool quick win, abysme je vůbec k zájmu o techniku přitáhli" (a tohle se mu imho daří fantasticky, alespoň v mojí generaci, u mladších si tím nejsem jistej).
Na tom Svazarmu něco bylo.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 20:27:49
Možná by šel zbastlit nějakej pěknej, čistej framework v Rustu nebo Go?
Určitě šel, ale kdo to udělá?
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 08. 03. 2021, 21:49:40
Mě by se líbilo to samé, ale pro programátory, tj. zprostředkovat pokročilejším vývojářům  specifika a různé možnosti v přístupu k embedded vývoji. Klidně to udělat na základě nějaké existující vývojové desky (nevím zda se na to hodí Arduino, ale třeba ten ESP nebo STM32 mi přijde vhodný určitě). Věřím že spousta programátorů si ráda pohraje nebo se jim to bude hodit v nějakém projektu.
Existují různé knížky pro Arduino, které jdou fakt krok za krokem přes různé experimenty. Většina asi jenom v angličtině, ale u nás máme úplně úžasný triptych od Martina Malého. Každá z knížek má jiné téma, takže si člověk musí dobře vybrat, co ho opravdu zajímá. Jsou k dispozici zdarma v PDF, ale silně bych doporučil je koupit papírové, protože si to autor fakt zaslouží, je to úžasně udělané. (EDIT: to nejdůležitější bych málem zapomněl: https://www.nic.cz/page/4205/v-edici-cznic-vychazi-kniha-data-cipy-procesory-autorem-je-znamy-publicista-martin-maly/ )

Tak mě přijde, že by šel klidně zahrnout i docela vysokoúrovňový přístup, četl jsem o robotech programovaných v Smalltalku apod. Události, fronty, zpracování streamů, hlídání limitů - IMHO podle mě ideální pro řadu aplikací. A zkušenější programátoři se s tím už určitě setkali jinde, navíc je tu synergie se současným trendem mikroslužeb. To by bylo ideální téma na Arduino v2.0 nebo konkurenční projekt.
To částečně existuje ve formě Micropythonu nebo Lua a mně osobně to moc nesedí. Něco tomu podle mě chybí. Mně by se líbil framework buď fakt výkonný (rustí zero-cost abstraction by mohly být nadějné) nebo naopak geniálně vysokoúrovňový (ten smalltalk je dobrej příklad, ale možná i nějaká spešl verze Erlangu by mohla být cool). Micropython mi přijde přesně v tom prostředku, který mi přijde nejmíň sexy (čistě subjektivní záležitost).

Určitě šel, ale kdo to udělá?
Tak chce to chytrej design, na to je potřeba někoho trochu zkušenějšího, s otevřenou myslí a rozhledem, a pak je to kupa rutinní práce, která by byla krásným zadáním diplomky. Takže minimálně tu druhou část bys mohl trochu pošťouchnout ty, ne? ;)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 21:59:06
Rust by technicky šel (jen teda nevím, nakolik je vhodný pro začátečníky... vlastně vím...), ale to Go — cos zmiňoval výše — není dobrý nápad, ledaže by existovala nějaká verze s korutinami a kanály, ale bez GC (jo, vím o TinyGo, ale to není to pravé). Smalltalk by byl vhodný z didaktických důvodů.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 08. 03. 2021, 22:04:51
Rust by technicky šel (jen teda nevím, nakolik je vhodný pro začátečníky... vlastně vím...), ale to Go — cos zmiňoval výše — není dobrý nápad, ledaže by existovala nějaká verze s korutinami a kanály, ale bez GC (jo, vím o TinyGo, ale to není to pravé). Smalltalk by byl vhodný z didaktických důvodů.
Jo, já si taky myslím, že Rust by byl daleko vhodnější. "Pro začátečníky" - no ten framework by musel být natolik vysokoúrovňový, aby se nováček se samotným jazykem vůbec netrápil - podobně jako se v Arduino netrápí s C++...

K té druhé úplně vysokoúrovňové variantě taková kacířská myšlenka: spoustu lidí (včetně mě) hodně baví Factorio. Z informatickýho hlediska je to vlastně stavění masivně paralelního stroje. Ale z takových primitiv, která jsou naprosto srozumitelná a dají se skvěle spojovat do větších celků. Takže člověk úplně bezbolestně vytvoří něco, co by v C absolutně neměl šanci dát, i kdyby to byla funkčně ekvivalentní věc. Takhle nějak bych si to představoval. Kanály, eventy, transformace. Vůbec neřešit vlákna, coroutiny, procesy, paměť... Prostě jenom skládat srozumitelná primitiva ve funkční celek. To by byla nirvána :)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 22:07:50
Rust by technicky šel (jen teda nevím, nakolik je vhodný pro začátečníky... vlastně vím...), ale to Go — cos zmiňoval výše — není dobrý nápad, ledaže by existovala nějaká verze s korutinami a kanály, ale bez GC (jo, vím o TinyGo, ale to není to pravé). Smalltalk by byl vhodný z didaktických důvodů.
Jo, já si taky myslím, že Rust by byl daleko vhodnější. "Pro začátečníky" - no ten framework by musel být natolik vysokoúrovňový, aby se nováček se samotným jazykem vůbec netrápil - podobně jako se v Arduino netrápí s C++...
Na tohle má Go mnohem lepší syntax. Ale v tom Rustu by to asi taky šlo, je to o zvyku, blikat diodou se dá i s borrow checkerem :)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 22:12:45
Rust by technicky šel (jen teda nevím, nakolik je vhodný pro začátečníky... vlastně vím...), ale to Go — cos zmiňoval výše — není dobrý nápad, ledaže by existovala nějaká verze s korutinami a kanály, ale bez GC (jo, vím o TinyGo, ale to není to pravé). Smalltalk by byl vhodný z didaktických důvodů.
Takhle nějak bych si to představoval. Kanály, eventy, transformace. Vůbec neřešit vlákna, coroutiny, procesy, paměť...
To je easy, stačí CSP. Buď osekané Go, nebo třeba Smalltalk s kanálama (a odpovídající syntaxí) by byl na tohle super (trochu úlet, ale pozitivní).
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 08. 03. 2021, 22:13:20
Na tohle má Go mnohem lepší syntax.
To urcite jo, ale plati se za to, zejo, nic neni zadarmo...

Ale v tom Rustu by to asi taky šlo, je to o zvyku, blikat diodou se dá i s borrow checkerem :)
Kdyby se vhodne navrhlo API, tak by se na vetsine mist na ten borrow checking vubec nemuselo narazit. Kdyz budes vetsinou predavat skalary (u toho blikani: cislo pinu a true/false) a slozitejsi veci jako zpracovani eventu budou z drtive vetsiny immutable struktury, neni problem.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 08. 03. 2021, 22:16:08
To je easy, stačí CSP. Buď osekané Go, nebo třeba Smalltalk s kanálama (a odpovídající syntaxí) by byl na tohle super (trochu úlet, ale pozitivní).
Jj, tak jsem to presne myslel - dat lidem CSP s peknym API a vhodnou sadou nastroju a lisacky jim vubec nerikat, ze je to CSP :)

Akorat teda treba u toho Rustu jsem si jeste neprostudoval, jakej je soucasnej stav prace s konkurenci. Nejaky kanaly jsem nekde z rychliku videl, ale jak je to pouzitelny netusim.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 22:18:53
Na tohle má Go mnohem lepší syntax.
To urcite jo, ale plati se za to, zejo, nic neni zadarmo...

Ale v tom Rustu by to asi taky šlo, je to o zvyku, blikat diodou se dá i s borrow checkerem :)
Kdyby se vhodne navrhlo API, tak by se na vetsine mist na ten borrow checking vubec nemuselo narazit. Kdyz budes vetsinou predavat skalary (u toho blikani: cislo pinu a true/false) a slozitejsi veci jako zpracovani eventu budou z drtive vetsiny immutable struktury, neni problem.
IMHO stačí slušný “select” (jako v Go, Rust to má tuším jako makro, kdyby byl nativní, není co řešit).
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 22:20:10
To je easy, stačí CSP. Buď osekané Go, nebo třeba Smalltalk s kanálama (a odpovídající syntaxí) by byl na tohle super (trochu úlet, ale pozitivní).
Jj, tak jsem to presne myslel - dat lidem CSP s peknym API a vhodnou sadou nastroju a lisacky jim vubec nerikat, ze je to CSP :)
Zrovna k tomuhle jsem nedávno došel, když jsem psal překladač Go pro eZ80 :)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 22:22:05
To je easy, stačí CSP. Buď osekané Go, nebo třeba Smalltalk s kanálama (a odpovídající syntaxí) by byl na tohle super (trochu úlet, ale pozitivní).
Akorat teda treba u toho Rustu jsem si jeste neprostudoval, jakej je soucasnej stav prace s konkurenci. Nejaky kanaly jsem nekde z rychliku videl, ale jak je to pouzitelny netusim.
Mají async/await. Kanály taky (mpsc, posláním se předá vlastnictví (“move”)).
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 08. 03. 2021, 22:41:17
Mají async/await. Kanály taky (mpsc, posláním se předá vlastnictví (“move”)).
Jo, vim. Ale nemel jsem zatim cas si to dobre prostudovat a vyzkouset. Dabel je vzdycky v detailu. V Erlangu jsem treba poznal, jak extremne sikovny, az bych rekl v nekterych pripadech nezbytny, je moznost selektivniho vyberu zprav. Coz treba Go nema a Rust nevim. Ale strasne to zvysi expresivnost. (Jak rika klasik: ...a pritom takova blbost :) )
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 22:45:00
Mají async/await. Kanály taky (mpsc, posláním se předá vlastnictví (“move”)).
Jo, vim. Ale nemel jsem zatim cas si to dobre prostudovat a vyzkouset. Dabel je vzdycky v detailu. V Erlangu jsem treba poznal, jak extremne sikovny, az bych rekl v nekterych pripadech nezbytny, je moznost selektivniho vyberu zprav. Coz treba Go nema a Rust nevim. Ale strasne to zvysi expresivnost. (Jak rika klasik: ...a pritom takova blbost :) )
Různé libůstky a blbůstky se najdou všude. Na blikání diodou stačí bare bones CSP. Ovšem ani to nikde v embedded/IoT nevidím.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 08. 03. 2021, 22:50:55
Různé libůstky a blbůstky se najdou všude. Na blikání diodou stačí bare bones CSP. Ovšem ani to nikde v embedded/IoT nevidím.
Embedaci jsou z velke casti dost stara skola, pokrok je, ze uz neprogramuji v assembleru :)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 08. 03. 2021, 23:03:28
Různé libůstky a blbůstky se najdou všude. Na blikání diodou stačí bare bones CSP. Ovšem ani to nikde v embedded/IoT nevidím.
Embedaci jsou z velke casti dost stara skola, pokrok je, ze uz neprogramuji v assembleru :)
Někteří jo ;)
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 09. 03. 2021, 00:11:28
Mě by se líbilo to samé, ale pro programátory, tj. zprostředkovat pokročilejším vývojářům  specifika a různé možnosti v přístupu k embedded vývoji. Klidně to udělat na základě nějaké existující vývojové desky (nevím zda se na to hodí Arduino, ale třeba ten ESP nebo STM32 mi přijde vhodný určitě). Věřím že spousta programátorů si ráda pohraje nebo se jim to bude hodit v nějakém projektu.
Existují různé knížky pro Arduino, které jdou fakt krok za krokem přes různé experimenty. Většina asi jenom v angličtině, ale u nás máme úplně úžasný triptych od Martina Malého. Každá z knížek má jiné téma, takže si člověk musí dobře vybrat, co ho opravdu zajímá. Jsou k dispozici zdarma v PDF, ale silně bych doporučil je koupit papírové, protože si to autor fakt zaslouží, je to úžasně udělané. (EDIT: to nejdůležitější bych málem zapomněl: https://www.nic.cz/page/4205/v-edici-cznic-vychazi-kniha-data-cipy-procesory-autorem-je-znamy-publicista-martin-maly/ )

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.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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é.
Název: Re:Arduino a knihovny
Přispěvatel: uwe.filter 09. 03. 2021, 12:40:04
Zajímavá diskuze, zkusím poskytnout ještě jeden pohled na věc. Nějakých pár blbostí s Arduinem jsem sesmolil a až bude čas, plánuju sesmolit další. Přes veškeré výhrady ke konceptu Arduina si myslím, že pokud se použije rozumně, dá se na nějaké jednodušší projekty nebo prototypy použít, jen to chce mít na paměti, že ne vše tam je úplně ideální. Milion návodů, milion knihoven (dobře, asi ne vždy dobře napsaných), obrovská komunita, pro začátečníka z tohohle pohledu ideální.

No a pak člověk na eBay objeví Blue Pill za prakticky stejnou cenu jako menší varianty klonů arduina a mimo jiné s mnohem vyšším výkonem, jenže co teď s tím? Dá se to pořád programovat stejně jako Arduino. 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? 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é? Samé otázky :). Aspoň takhle nějak se to honí mně hlavou, když pomyslím na to, že bych si chtěl pohrát třeba s tím STM a naučit se s ním pracovat nějak koncepčně... Asi kdybych v tom týden ležel a hledal a četl, tak bych to nakonec dal nějak dohromady, ale chybí mi nějaký informační a funkční celek, který by byl ekvivalentní arduinu, jen řekněme náročnější na naučení, pokud by měl vést k řešení věcí správnější cestou a využívání vlastností složitějšího MCU.
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 09. 03. 2021, 14:48:10
Zajímavá diskuze, zkusím poskytnout ještě jeden pohled na věc. Nějakých pár blbostí s Arduinem jsem sesmolil a až bude čas, plánuju sesmolit další. Přes veškeré výhrady ke konceptu Arduina si myslím, že pokud se použije rozumně, dá se na nějaké jednodušší projekty nebo prototypy použít, jen to chce mít na paměti, že ne vše tam je úplně ideální. Milion návodů, milion knihoven (dobře, asi ne vždy dobře napsaných), obrovská komunita, pro začátečníka z tohohle pohledu ideální.

No a pak člověk na eBay objeví Blue Pill za prakticky stejnou cenu jako menší varianty klonů arduina a mimo jiné s mnohem vyšším výkonem, jenže co teď s tím? Dá se to pořád programovat stejně jako Arduino. 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? 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é? Samé otázky :). Aspoň takhle nějak se to honí mně hlavou, když pomyslím na to, že bych si chtěl pohrát třeba s tím STM a naučit se s ním pracovat nějak koncepčně... Asi kdybych v tom týden ležel a hledal a četl, tak bych to nakonec dal nějak dohromady, ale chybí mi nějaký informační a funkční celek, který by byl ekvivalentní arduinu, jen řekněme náročnější na naučení, pokud by měl vést k řešení věcí správnější cestou a využívání vlastností složitějšího MCU.

STM se snaží dělat podporu. Ale nemám s tím zkušenost, nevím zda to stačí ke vstupu do tématu. Něco vyšlo i tady na rootu https://www.root.cz/clanky/pristupy-k-programovani-stm32/ https://www.root.cz/clanky/stm32-mikrokontroler-vstricny-k-amaterum/ Podle mě to je pořád aktuální téma, třeba se toho někdo chytne...
Název: Re:Arduino a knihovny
Přispěvatel: _Jenda 09. 03. 2021, 15:17:31
No a pak člověk na eBay objeví Blue Pill za prakticky stejnou cenu jako menší varianty klonů arduina a mimo jiné s mnohem vyšším výkonem, jenže co teď s tím? Dá se to pořád programovat stejně jako Arduino.

No právě že nedá. Ten port (https://github.com/stm32duino/Arduino_Core_STM32) je zabugovanej a nemá různé featury. Např.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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í :)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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.
Název: Re:Arduino a knihovny
Přispěvatel: _Jenda 09. 03. 2021, 16:11:44
Při použití Platformia obě tyhle věci odpadají.
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á.

Zalinkovaný balast moc neumím posoudit.
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/.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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?
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 09. 03. 2021, 16:50:39
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?
Název: Re:Arduino a knihovny
Přispěvatel: Idris 09. 03. 2021, 16:51:46
Aha, tak to jsem nezkoušel, ale to spíš asi budou nějaký debug symboly nebo tak něco, ne?
Přesně kvůli tomuhle je nejlepší používat co nejjednodušší nástroje/knihovny a třeba i ten vysmívaný asembler, když to člověk umí. Debug symboly nebo zbytečné alokace na haldě rozeseté po pochybných knihovnách by se neměly vyskytovat (v produkci, na hraní to je celkem jedno). Otázka je, kde najít hranici NIH.
Název: Re:Arduino a knihovny
Přispěvatel: FKoudelka 09. 03. 2021, 17:05:08
potřebujeme sledovat teplotu v kamrlíku se serverem“ → připojím k Arduinu za $2 DHT22 za $2, Examples → DHT, Upload, hotovo. „
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 :-(
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 09. 03. 2021, 17:21:13
Otázka je, kde najít hranici NIH.
To je podle mě nejtěžší otázka IT vůbec ;)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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
Název: Re:Arduino a knihovny
Přispěvatel: Idris 09. 03. 2021, 17:35:56
Otázka je, kde najít hranici NIH.
To je podle mě nejtěžší otázka IT vůbec ;)
Ano. IMHO je to silně individuální.
Název: Re:Arduino a knihovny
Přispěvatel: FKoudelka 09. 03. 2021, 18:00:10
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
Jj díky, zkusím to esp32 az bude cas. Taky mam jeste arduino uno wifi, tak zkusim i to. Jen mam obavy, ze mi to degraduje rychlost na AP.
Název: Re:Arduino a knihovny
Přispěvatel: _Jenda 09. 03. 2021, 18:41:59
potřebujeme sledovat teplotu v kamrlíku se serverem“ → připojím k Arduinu za $2 DHT22 za $2, Examples → DHT, Upload, hotovo. „
No a jak to máš se stabilitou programu a kam tu teplotu vypisuješ ?
Po sériáku.

Mimochodem tohle je zrovna hezký příklad toho, co se psalo výše: knihovny obsahující v hlavním „vlákně“ čekání. Třeba u DS18S20 trvá změření teploty 750ms. A ta knihovna samozřejmě defaultně čeká… Takže když chceš dělat ještě něco jiného, tak ti program na tuto dobu zatuhne a ty se pak třeba divíš, že ti přetéká buffer sériáku, i když ho přece pravidelně čteš. (a jinak zrovna v této knihovně je i možnost udělat to neblokující)
Název: Re:Arduino a knihovny
Přispěvatel: ivoszz 10. 03. 2021, 00:21:24
Když jsem svůj dotaz pokládal, nenapadlo mne, že se tady rozvine taková zajímavá diskuse (několik dní jsem se sem nedostal). Každopádně děkuji za náměty, vyzkouším si teď asi FreeRTOS, případně něco dalšího. Taky když jsem použil výraz Arduino, neměl jsem na mysli konkrétně AVR, ale spíš celý ten ekosystém kolem. Sám mám ESP32 a SAMD51.

Rust by technicky šel (jen teda nevím, nakolik je vhodný pro začátečníky... vlastně vím...), ale to Go — cos zmiňoval výše — není dobrý nápad, ledaže by existovala nějaká verze s korutinami a kanály, ale bez GC (jo, vím o TinyGo, ale to není to pravé). Smalltalk by byl vhodný z didaktických důvodů.
S TinyGo si taky zkouším hrát a zatím jsem u sebe na limity nenarazil (teda až na omezenější nabídku driverů). Na druhou stranu přemýšlím, jestli není na konkrétní projekt lepší si pak ten driver napsat sám, pořádně a podle vlastní potřeby. Příkladů je sice málo, ale když si člověk otestuje těch pár "vzorů", tak vše ostatní je už zase standardní.  Výhledově bych chtěl vyzkoušet i Rust (tam je to s těmi drivery podobné).
Název: Re:Arduino a knihovny
Přispěvatel: Idris 10. 03. 2021, 00:47:02
S TinyGo si taky zkouším hrát a zatím jsem u sebe na limity nenarazil (teda až na omezenější nabídku driverů). Na druhou stranu přemýšlím, jestli není na konkrétní projekt lepší si pak ten driver napsat sám, pořádně a podle vlastní potřeby. Příkladů je sice málo, ale když si člověk otestuje těch pár "vzorů", tak vše ostatní je už zase standardní.  Výhledově bych chtěl vyzkoušet i Rust (tam je to s těmi drivery podobné).
TinyGo je na hraní super. Rust taky doporučuju, ani ne tak pro embedded, ale obecně pro rozšíření obzorů.

Jinak napsat si driver sám je užitečné vždy, už jen z didaktických důvodů. Sám se teď chci podívat na Pico, jen tak z hecu (a výhledově pro výuku robotiky apod.).
Název: Re:Arduino a knihovny
Přispěvatel: uwe.filter 10. 03. 2021, 08:16:44
Děkuju Mirkovi Prýmkovi a dalším za tipy vztahující se k mým četným otázkám k STM32 :). Výhledově snad vyzkouším a kdyby náhodou ne, snad se to aspoň bude hodit i někomu jinému.
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 10. 03. 2021, 14:36:08
Mimochodem tohle je zrovna hezký příklad toho, co se psalo výše: knihovny obsahující v hlavním „vlákně“ čekání. Třeba u DS18S20 trvá změření teploty 750ms. A ta knihovna samozřejmě defaultně čeká… Takže když chceš dělat ještě něco jiného, tak ti program na tuto dobu zatuhne a ty se pak třeba divíš, že ti přetéká buffer sériáku, i když ho přece pravidelně čteš. (a jinak zrovna v této knihovně je i možnost udělat to neblokující)

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:

Citace
If you want to take measurements using ADC, internal temperature sensor or external I2C sensors, while the main processors are in deep sleep mode you need to use ULP coprocessor. At the moment ULP can be used only with the Espressif IoT Development Framework.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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.
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 10. 03. 2021, 14:47:40
To PlatformIO vypadá podstatně profesionálněji.
Nevím, jestli "profesionálněji", každopádně je to pohodlnější, komfortnější.

Hodnoceno na základě porovnání Arduino IDE (v1.x) vs toho VSCode rozšíření - to VSCode vypadá poněkud pokročileji :D (samosebou to nové Arduino IDE v2.x na tom bude nejspíš lépe - nezkoušel jsem).

Citace: Mirek Prýmek link=topic=24381.msg346472#msg346472
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.

Jj, to vypadá docela to dobře, mít to takhle po kupě. Navíc se člověk může pak nejspíš podívat pod kapotu, pokud ho zajímá jak ty tooly fungujou.
Název: Re:Arduino a knihovny
Přispěvatel: Ondrej Nemecek 10. 03. 2021, 14:58:00
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.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 10. 03. 2021, 15:08:31
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.
Název: Re:Arduino a knihovny
Přispěvatel: Kizarm 10. 03. 2021, 16:46:35
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 (https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html)
Název: Re:Arduino a knihovny
Přispěvatel: Idris 10. 03. 2021, 17:17:24
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 (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 :)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 10. 03. 2021, 19:04:52
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.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 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/
Název: Re:Arduino a knihovny
Přispěvatel: Wrána diskuze 18. 03. 2021, 13:10:50
............
zavedlo jednovláknový přístup.
.............

57 vláken ti jako nestačí hele (https://hackaday.com/2021/03/17/running-57-threads-at-once-on-the-arduino-uno/) :o :o ;D ;D ;) ;)
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 18. 03. 2021, 13:14:34
............
zavedlo jednovláknový přístup.
.............

57 vláken ti jako nestačí hele (https://hackaday.com/2021/03/17/running-57-threads-at-once-on-the-arduino-uno/) :o :o ;D ;D ;) ;)
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.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 18. 03. 2021, 13:51:56
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.
Název: Re:Arduino a knihovny
Přispěvatel: ivoszz 18. 03. 2021, 18:28:10
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ů.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 18. 03. 2021, 19:31:15
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).
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 18. 03. 2021, 19:47:28
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.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 18. 03. 2021, 20:09:25
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.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 18. 03. 2021, 21:48:02
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.
Hm, to je zvláštní, zrovna defer bych nečekal, že bude těžký implementovat. GC jsem myslel, že to nemá. S ním to imho moc nedává smysl. S gočkovým GC jsme si užili trochu WTF momentů i na serveru, na MCU bych to fakt viděl nerad.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 18. 03. 2021, 22:11:40
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.
Hm, to je zvláštní, zrovna defer bych nečekal, že bude těžký implementovat. GC jsem myslel, že to nemá. S ním to imho moc nedává smysl. S gočkovým GC jsme si užili trochu WTF momentů i na serveru, na MCU bych to fakt viděl nerad.
Jakých momentů? GC v Go šlape jako hodinky. TinyGo je kompletní přepis pro MCU a s "normálním" Go má společnou jen syntax. Nicméně mark-and-sweep GC jsem tam taky nečekal.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 18. 03. 2021, 22:36:09
Jakých momentů? GC v Go šlape jako hodinky.
Přesný detaily už si nepamatuju, ale tak prostě GC, no...

Myslím, že prvotní příčina byla v tom, že GC neuvolňuje paměť dokud má pocit, že "paměti je dost", takže když máš stroj, na kterým ti běží kontejnery, tak žere paměti víc než kolik by reálně potřeboval, protože v tom společným "poolu paměti" je jí pořád "dost". Něco takovýho to bylo, ale dohadovat se o to nebudu, prostě si pamatuju, že jsme si s pamětí v Go nějak lámali hlavu, vypadalo to jako memory leak a mohl za to GC.

EDIT: P.S. Celý to až moc nápadně připomínalo šťourání se v GC Javy, takže od té doby už jsem i ohledně toho gočkovýho GC poněkud vlažnější...
Název: Re:Arduino a knihovny
Přispěvatel: Idris 18. 03. 2021, 23:19:45
Jakých momentů? GC v Go šlape jako hodinky.
Přesný detaily už si nepamatuju, ale tak prostě GC, no...

Myslím, že prvotní příčina byla v tom, že GC neuvolňuje paměť dokud má pocit, že "paměti je dost", takže když máš stroj, na kterým ti běží kontejnery, tak žere paměti víc než kolik by reálně potřeboval, protože v tom společným "poolu paměti" je jí pořád "dost". Něco takovýho to bylo, ale dohadovat se o to nebudu, prostě si pamatuju, že jsme si s pamětí v Go nějak lámali hlavu, vypadalo to jako memory leak a mohl za to GC.

EDIT: P.S. Celý to až moc nápadně připomínalo šťourání se v GC Javy, takže od té doby už jsem i ohledně toho gočkovýho GC poněkud vlažnější...
Takhle funguje každý GC (pokud nějak drasticky nesnížíš GOGC). Nicméně právě správa paměti se mi líbí na Rustu, žádný GC, všechno hezky na zásobníku nebo explicitně v krabicích. Pro MCU jako dělané.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 18. 03. 2021, 23:22:02
Takhle funguje každý GC (pokud nějak drasticky nesnížíš GOGC).
Nepamatuju si, že bysme tohle řešili s Pythonem.

Nicméně právě správa paměti se mi líbí na Rustu, žádný GC, všechno hezky na zásobníku nebo explicitně v krabicích. Pro MCU jako dělané.
Jo.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 18. 03. 2021, 23:24:27
Takhle funguje každý GC (pokud nějak drasticky nesnížíš GOGC).
Nepamatuju si, že bysme tohle řešili s Pythonem.
Python nemá klasický GC. Nebo se něco měnilo?
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 18. 03. 2021, 23:25:48
Python nemá klasický GC. Nebo se něco měnilo?
Vůbec nevím, co má nebo nemá Python, ale vím, že paměť nějak hlídá a tyhle brikule nedělá :)
Název: Re:Arduino a knihovny
Přispěvatel: Jakub Štech 18. 03. 2021, 23:29:35
Python má normální refcounting, paměť se uvolní v destruktoru poslední reference, která na něj ukazuje. Garbage collector se spouští periodicky jen aby našel a zlikvidoval cyklické závislosti jinak už zahozených (out of scope) objektů, tzn. když nemáte závislostní graf jak rodokmen Habsburků, tak GC nic nedělá a správa paměti je hezky deterministická.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 18. 03. 2021, 23:29:48
Python nemá klasický GC. Nebo se něco měnilo?
Vůbec nevím, co má nebo nemá Python, ale vím, že paměť nějak hlídá a tyhle brikule nedělá :)
Protože počítá reference. Když napíšu, že se tracing GC chová jako v Go obecně, tak nemůžeš argumentovat něčím, co má počítání referencí, to je zjevně irelevantní ;) (Python má i mark-and-sweep jen pro cykly, jako zadní vrátka, což ovšem na věci nic nemění)

[edit] P.S. Kolega mě předběhl s vysvětlením.
Název: Re:Arduino a knihovny
Přispěvatel: Mirek Prýmek 18. 03. 2021, 23:31:09
Když napíšu, že se tracing GC chová
Tos neudělal. Ale fakt to nechci řešit.
Název: Re:Arduino a knihovny
Přispěvatel: ivoszz 19. 03. 2021, 16:33:29
Ty argumenty mi nepříjdou dvakrát přesvědčivé, myslel jsem, že to bude silnější. Navíc lecos z toho už asi neplatí nebo nebude platit v blízké budoucnosti. Například u defer, dokumentace tvrdí:
Citace
The defer keyword is almost entirely supported, with the exception of deferring some builtin functions.
Navíc i když zpřehledňuje kód, dá se bez něj docela dobře žít.

Recover osobně nepoužívám, takže mi taky nechybí, net není a nebude v dohledné době podporován, takže to mne taky neomezuje. Externí síťová knihovna recover nepoužívá. Problémem je map, ani ne tak to omezení typů, ale co jsem četl, tak jeho neoptimalizovanost v některých případech. Chtěl bych věřit, že tohle se brzy spraví.

GC mi připadá, že není tak hrozný jak bylo prezentováno. Zaprvé jde vypnout (jinak by to na malých AVR ani nejelo) a s příchodem čipů s větší pamětí to není kritické. Je jasné, že na alokace člověk musí myslet, ale to platí i když to píše v C. Zadáním gc=none lze navíc trasovat místa, kde se alokuje paměť a jestli s tím nejde něco udělat. RT byl vždy vyšší dívčí a člověk musí myslet na věci, které jinde řešit nemusí. A co se týče zmiňovaného Pythonu, ve zdrojových kódech autoři píší, že se silně inspirovali GC z MicroPythonu. :)

Co se týče knihoven driverů, kupodivu jsem zatím nenarazil. Osobně to zatím jako velký problém nevidím. V projektech, které plánuji, těch používaných zařízení zase tolik není a přepsat případně driver z C do Go nevidím jako zásadní problém (největší může být s časováním). Zvláště poté, co jsem viděl jaká zvěrstva tam jsou občas páchána, takže bych to musel stejně upravovat. Navíc mi i myšlenka naprototypovat to rychle v Go a pak to případně přepsat do C, pokud je potřeba, připadá jako zajímavá.

Nejsem naivní a je mi jasné, že určitě někde narazím, ale zatím to zkusím dál. Pro kontext ještě jednou doplním, že se primárně bavím o CortexM.
Název: Re:Arduino a knihovny
Přispěvatel: Idris 19. 03. 2021, 18:31:24
Ty argumenty mi nepříjdou dvakrát přesvědčivé, myslel jsem, že to bude silnější. Navíc lecos z toho už asi neplatí nebo nebude platit v blízké budoucnosti. Například u defer, dokumentace tvrdí:
Citace
The defer keyword is almost entirely supported, with the exception of deferring some builtin functions.
Navíc i když zpřehledňuje kód, dá se bez něj docela dobře žít.

Recover osobně nepoužívám, takže mi taky nechybí, net není a nebude v dohledné době podporován, takže to mne taky neomezuje. Externí síťová knihovna recover nepoužívá. Problémem je map, ani ne tak to omezení typů, ale co jsem četl, tak jeho neoptimalizovanost v některých případech. Chtěl bych věřit, že tohle se brzy spraví.

GC mi připadá, že není tak hrozný jak bylo prezentováno. Zaprvé jde vypnout (jinak by to na malých AVR ani nejelo) a s příchodem čipů s větší pamětí to není kritické. Je jasné, že na alokace člověk musí myslet, ale to platí i když to píše v C. Zadáním gc=none lze navíc trasovat místa, kde se alokuje paměť a jestli s tím nejde něco udělat. RT byl vždy vyšší dívčí a člověk musí myslet na věci, které jinde řešit nemusí. A co se týče zmiňovaného Pythonu, ve zdrojových kódech autoři píší, že se silně inspirovali GC z MicroPythonu. :)

Co se týče knihoven driverů, kupodivu jsem zatím nenarazil. Osobně to zatím jako velký problém nevidím. V projektech, které plánuji, těch používaných zařízení zase tolik není a přepsat případně driver z C do Go nevidím jako zásadní problém (největší může být s časováním). Zvláště poté, co jsem viděl jaká zvěrstva tam jsou občas páchána, takže bych to musel stejně upravovat. Navíc mi i myšlenka naprototypovat to rychle v Go a pak to případně přepsat do C, pokud je potřeba, připadá jako zajímavá.

Nejsem naivní a je mi jasné, že určitě někde narazím, ale zatím to zkusím dál. Pro kontext ještě jednou doplním, že se primárně bavím o CortexM.
Jo, výhled je pozitivní, určitě to postupně vylepší. Go by bylo pro MCU ideální jazyk, kdyby se podařilo nějak eliminovat GC (což je jednodušší, než se může zdát).