Příspěvky

241

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

« kdy: 16. 03. 2021, 07:24:38 »

Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).

Já si (po zkušenosti s Elixirem) pořád myslím, že mailbox se selektivním výběrem je daleko mocnější nástroj, ale pro jednoduchou implementaci by nebufferované kanály imho měly stačit.

Bufferovaný kanál by se z nebufferovaného dal udělat, pokud by byla k dispozici operace testu, jestli je kanál prázdný. Pak můžu v případě potřeby ukládat do lokálního bufferu. Nenapadá mě teď případ, ve kterém by to nebylo funkčně ekvivalentní k "nativnímu" bufferu.

Kromě toho, nevybavuju si, že bych se někdy setkal se situací, kde by buffer na kanálu byl nutně potřeba pro korektnost algoritmu a nedalo by se to napsat jinak.

242

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

« kdy: 15. 03. 2021, 23:15:04 »

Tak mě napadá, jak tam hodláš řešit select?

Takhle nízko ještě nejsem, zatím mám jenom mlhavou, high-level představu.

Nad tímhle jsou ještě jiná zajímavá rozhodnutí - jestli pojmenovávat kanály nebo procesy, jestli si vystačit s nebufferovanými kanály nebo přidat nějakou kapacitu, jestli kanál pojmout jako frontu nebo mailbox, jestli umožnit selektivní výběr zpráv...

Jestli má jít o srandu na jedno dvě odpoledne, tak to vidím na pojmenované kanály bez kapacity a tímpádem bez selektivního výběru. V takovým jednoduchým případě by select neměl být nic, nad čím by bylo potřeba dumat (?). Prostě z množiny kanálu náhodně vybereš jeden připravený ke čtení. Pokud by tam byl ten run to complete scheduler, tak by select vůbec nemusel být potřeba se mi intuitivně zdá.

243

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

« kdy: 15. 03. 2021, 17:21:26 »

Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání?

Tak predstavit si umim ledasco

Postavil jsem robota nad ESP32 a stvalo me, jak dlouho trva OTA uprage firmwaru. Tak jsem tam udelal uplne jednoduchoucky virtualni stroj s par instrukcemi a upgrade timpadem prenasel jenom par desitek bytu. Tady by se to dalo udelat stejne, kdyby clovek chtel. Minimalisticka implementace CSP by vyzadovala jenom par instrukci, takze "virtualni stroj" by byl jeden switch s nekolika malo kejsy

A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?

Tak pokud mam vyreseny komunikacni kanal, je synchronizace casu (s nejakou rozumnou presnosti) uz jenom snadna skolni uloha

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).

Tak on ma RDa v principu pravdu, ze to striktne vzato neni potreba. Synchronizaci blikani po CAN busu si muzu napsat i natvrdo v C a bude to efektivnejsi, zejo...

Mne to prijde zajimavy ciste z "vyzkumnych", sebevzdelavacich a sebe-potesujicich duvodu

244

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

« kdy: 15. 03. 2021, 10:32:47 »

Na cem jedete, ja chci taky takovej caj

Tyhle látky začne mozek produkovat přirozeně sám, stačí par let programovat v Elixiru

245

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

« kdy: 15. 03. 2021, 01:53:48 »

Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).

Bingo! To jsem právě naťukl v tom původním vláknu s tím PRU na Beaglebone. To jsou dva oddělený procesory. A jakmile by bylo CSP rozchozený, je to už jenom kousek k dalším srandám.

Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda

246

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

« kdy: 15. 03. 2021, 01:36:23 »

To CSP je to zajímavé, scheduler je tam prostě z nutnosti

Presne! Scheduler je tam jenom technikalie, kterou je proste potreba nejak vyresit, aby to "svítilo a hřálo", jak říká klasik

247

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

« kdy: 15. 03. 2021, 01:32:40 »

Snazit se o multi-processing v systemu, ktery nema MMU je ponekud marne.

Myslim, ze se trochu mijime. To, co mam na mysli, je spis Erlang, nez Linux kernel.

Takze polozim velice jednoduchou otazku:

Co prinese vas odlisny a pre-komplikovany system oproti obycejnemu main-loop cyklu, kde se kazdy "proces" projevuji svym loop-handlerem?

Za prve: urcite ne pre-komplikovany. Jde mi prave o co nejvetsi jednoduchost.

Pak by se na to dalo odpovedet snadno: srandu, o nic jinyho nejde. Rict: "hele, tady mas Hoareho priklady implementovany na Atmeze v 1000 radcich cecka". To by bylo cool, nestaci to?

A taky by se to dalo vzit seriozne a diskutovat o tom, 1. co to je "obycejny main-loop cyklus" (umoznuje za behu vytvaret nove tasky?) 2. cim se principielne lisi od jakehokoli jineho scheduleru 3. ze moje predstava neni jenom o scheduleru, ale o tom celkovem systemu CSP, ktery prave jenom dohromady dava smysl.

...ale do toho se asi poustet nebudu. Urcite ne ted, je pokrocila hodina a zitra musime roztacet kola kapitalismu, chlapi

248

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

« kdy: 15. 03. 2021, 01:15:48 »

Tak se pak pochlub

Jj, určitě, za tu spolupráci si to zasloužíte

249

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

« kdy: 15. 03. 2021, 01:02:31 »

V C? To asi nebude problém.

Nechci, aby to byl problém. Implementaci chci věnovat tak jedno odpoledne, kdyby mě to extra bavilo, tak možná víkend

Já kdysi napsal korutiny pro C na AMD64 a pak se mi to nějak povedlo přepsat i pro ARM (je to kupa let zpátky, tak asi ARM32, ale už si to nepamatuju, jen že to běhalo na iPhonu). Kanály tam nějak byly taky, ale ty nejsou problém. Zkusím to najít, co si tak pamutuju, největší opruz byl scheduler. Sranda taky bude rozběhat to na více jádrech (třeba Zobák má dvě).

Záměrně to nechci vidět, to bych přišel o všechnu zábavu

Představuju si to jako punkovou srandu, implementovanou cestou nejmenšího odporu, v tom stylu, jak píše Křišťan. Když to bude blikat deseti LEDkama s tím, že třeba jenom dvě bliknutí zařídí jeden task a pak nějaký "supervisor" spustí automaticky další, bude to v mých očích mission accomplished

250

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

« kdy: 15. 03. 2021, 00:50:43 »

Tj. každý task může být kdykoliv spuštěn, ale musí potom doběhnout (nebo spustit další task).

No, to je v podstatě ta stejná myšlenka jako ta moje.

251

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

« kdy: 15. 03. 2021, 00:48:04 »

A co to bude za jazyk?

Tak především nevím, jestli bude, TODO list rozhodně nemám prázdný Ale jestli si budu chtít někdy od všeho odpočinout, představoval bych si fakt jenom úplně nejjednodušší možné demo spousty tasků na malém MCU. Naprostý minimalismus ve stylu původního Hoareho článku nebo Occamu.

Samozřejmě se nebudu babrat s překladačem, na to fakt čas nemám, jde mi jenom o naimplementování těch primitv v C.

252

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

« kdy: 15. 03. 2021, 00:41:21 »

Jo, občas se kopíruje paměť (při nafukování zásobníku), proto se ti občas pod rukama změní ukazatel na instanci objektu (to může být zábavné, když v Go předáš ukazatel přes cgo někam ven a runtime ho při nafukování aktualizuje)

To mi neva, můj quick&dirty pokus, jesti se k němu někdy dostanu, rozhodně ukazatele podporovat nebude

253

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

« kdy: 15. 03. 2021, 00:39:08 »

Ten tvůj "divoký" nápad

Nepopírám, že divoký. Nikdy jsem se tímhle nezabýval, překladače nikdy nebyly moje hobby Dík za nasměrování.

254

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

« kdy: 15. 03. 2021, 00:27:51 »

Nejjednodušší je mít normální zásobníky a v případě potřeby je zvětšovat. Takhle to má Go a šlape to skvěle. Na MCU by mohla každá korutina začít třeba s 512B paměti (nebo i méně) a v případě potřeby růst. Není to žádná věda.

Jo, to by asi šlo. Zvlášť pokud by procesy byly short-lived jako v Erlangu, mohlo by to být dost dobrý řešení, paměť by se často uvolňovala. Zároveň by se musela sem tam kopírovat, ale na to asi sere pes

Samozřejmé to není, asi se shodneme na použití kooperativního multitaskingu, což implikuje použití korutin. A ty můžou být bezzásobníkové.

Aha! Klíčové slovo teda "stackless coroutine". Co na to zatím z rychlíku dívám, přijde mi to dost podobné té má intuitivní představě.

Ok, dík, ještě na to víc kouknu, vypadá to zajímavě.

255

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

« kdy: 15. 03. 2021, 00:13:10 »

Proč?

Přijde mi to samozřejmý, ale tak asi tou otázkou někam míříš...

Protože každý task se může v danou chvíli nacházet v libovolném místě programu a potřebuje teda mít někde uložený kontext volání?

viz obrázek "Memory layout of a multi-threaded program" tady: https://ferrous-systems.com/blog/embedded-concurrency-patterns/

P.S. Posílal jsem ti tohle i jako SZ, ale jsou tady blbě viditelný, asi jsi to nepostřehl.