CSP v embedded světě

Re:CSP v embedded světě
« Odpověď #45 kdy: 16. 03. 2021, 14:19:09 »
Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).
No prave. To reseni se zaviranim kanalu je elegantni jenom v pripade, ze komunikujes vyhradne pomoci kanalu. Jakmile mas i jiny komunikacni prostredky, tak to neni elegantni, ale haze ti to jenom klacky pod nohy.

Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.
Jasne. Jak rikam, pokud budes mit jenom kanaly a nic jinyho, bude to super.

Anebo by se jeste dalo uvazovat nad tim, ze by kanaly byly zaroven linky. To by asi taky slo, ale bylo by narocnejsi promyslet, jestli by to bylo rozumny za vsech situaci.


Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #46 kdy: 16. 03. 2021, 14:29:09 »
Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).
No prave. To reseni se zaviranim kanalu je elegantni jenom v pripade, ze komunikujes vyhradne pomoci kanalu. Jakmile mas i jiny komunikacni prostredky, tak to neni elegantni, ale haze ti to jenom klacky pod nohy.

Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.
Jasne. Jak rikam, pokud budes mit jenom kanaly a nic jinyho, bude to super.

Anebo by se jeste dalo uvazovat nad tim, ze by kanaly byly zaroven linky. To by asi taky slo, ale bylo by narocnejsi promyslet, jestli by to bylo rozumny za vsech situaci.
To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.

Re:CSP v embedded světě
« Odpověď #47 kdy: 16. 03. 2021, 14:31:41 »
To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.
Mozna z hlediska implementace. Ale z hlediska koncepcniho to s tim nema co delat.

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #48 kdy: 16. 03. 2021, 14:44:08 »
To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.
Mozna z hlediska implementace. Ale z hlediska koncepcniho to s tim nema co delat.
Tak si to představ tak, že kanály jsou jednoduše základní stavební prvky (něco jako asembler) a nad nimi si můžeš postavit linky. Udělat síťové kanály není tak těžké, když budou mít stejnou sémantiku, můžeš skrýt zavírání kanálů pod vlastní vrstvou vyšší úrovně. Takhle se dříve řešily i jiné věci (distribuované objekty, proxy) a byly s tím problémy (třeba se správou paměti) právě proto, že chtěli udržet jednotnou koncepci nezávislou na implementaci. Je to tradeoff. Osobně upřednostňuju jednodušší věci, žádné rádobyužitečné peudovýmysly v runtimu nechci, složitost patří do compile timu (hezký příklad je Rust, velesložitý překladač s borrow checkerem a výsledný kód je pak triviální). Ale určitě se rád inspiruju tvou inovativní implementací, až ji napíšeš ;)

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #49 kdy: 16. 03. 2021, 15:12:48 »
aby to "svítilo a hřálo", jak říká klasik :)
Dnes mi dorazilo Pico, hřát asi nebude, ale svítit určitě :) Jdu oprášit ARM32 asembler :)


Re:CSP v embedded světě
« Odpověď #50 kdy: 16. 03. 2021, 15:41:12 »
Je to tradeoff.
No dyť. To jsem právě říkal: k tomu net.Conn jsou možná implementační důvody, ale z koncepčního hlediska je ta dvojkolejnost otrava jako prase. A ani z hlediska výkonu to pak není příjemný, když u serveru musíš mít extra goroutinu pro každý spojení jenom proto, aby z net.Conn četla a posílala ti to kanálem. Nebo nemusíš, ale zas to má jiné otravné důsledky...

Dnes mi dorazilo Pico, hřát asi nebude, ale svítit určitě :) Jdu oprášit ARM32 asembler :)
Mně dorazilo v pátek :) Původně jsem ho ani kupovat nechtěl, ale pak jsem podlehl, že si ho aspoň zkusím. Aspoň to PIO bude zajímavý vyzkoušet.

První extra nemilý překvapení bylo, že se to nedá programovat pomocí ST-Linku. Takže doporučuju kupovat nejmíň po dvou kusech a z jednoho si udělat programátor.

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #51 kdy: 16. 03. 2021, 15:49:16 »
Je to tradeoff.
No dyť. To jsem právě říkal: k tomu net.Conn jsou možná implementační důvody, ale z koncepčního hlediska je ta dvojkolejnost otrava jako prase. A ani z hlediska výkonu to pak není příjemný, když u serveru musíš mít extra goroutinu pro každý spojení jenom proto, aby z net.Conn četla a posílala ti to kanálem. Nebo nemusíš, ale zas to má jiné otravné důsledky...
Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal. Jen musíš mít pro ni zásobník, což na serveru nevadí, ale na embedded by mohlo, i když bude malinký.

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #52 kdy: 16. 03. 2021, 15:52:00 »
Mně dorazilo v pátek :) Původně jsem ho ani kupovat nechtěl, ale pak jsem podlehl, že si ho aspoň zkusím. Aspoň to PIO bude zajímavý vyzkoušet.

První extra nemilý překvapení bylo, že se to nedá programovat pomocí ST-Linku. Takže doporučuju kupovat nejmíň po dvou kusech a z jednoho si udělat programátor.
Jo, mám dvě. Teď nemám moc čas, ale po večerech si budu hrát. Viva assembly :)

Re:CSP v embedded světě
« Odpověď #53 kdy: 16. 03. 2021, 16:12:25 »
Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal.
No tak pokud by to tak bylo, tak to ma knihovna udelat sama a neprezentovat mi nejaky ujety bufferovy API s ujetym nastavovanim timeoutu :)

https://www.embedded.com/build-a-super-simple-tasker/
Ten clanek je pekne napsany, diky! Akorat teda nevim, proc je ten konec tak ukousnuty :)


Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #54 kdy: 16. 03. 2021, 16:29:35 »
Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal.
No tak pokud by to tak bylo, tak to ma knihovna udelat sama a neprezentovat mi nejaky ujety bufferovy API s ujetym nastavovanim timeoutu :)

https://www.embedded.com/build-a-super-simple-tasker/
Ten clanek je pekne napsany, diky! Akorat teda nevim, proc je ten konec tak ukousnuty :)
To mě vede k dotazu: Preemptivní přepínání tam neplánuješ?

Re:CSP v embedded světě
« Odpověď #55 kdy: 16. 03. 2021, 16:45:29 »
To mě vede k dotazu: Preemptivní přepínání tam neplánuješ?
Ze zacatku urcite nebude potreba, ale jestli pouziju ten nejjednodussi moznej RTC scheduler, tak u nej by to bylo skoro zadarmo, takze kdo vi :)

Re:CSP v embedded světě
« Odpověď #56 kdy: 17. 03. 2021, 00:33:00 »
Takze jo, dneska byl pernej den, odreagovat jsem se potreboval, prvni trivialni verze je na svete :) 20B na task a 8B na kanal (to jenom kvuli zarovnani). Takze neco lehce pod tisic tasku na BluePillu :)

Implementaci si zatim necham pro sebe, podelim se jenom o main.

https://gist.github.com/mprymek/d1176be039c8f58e7d3ba4b3b7358e51

Stupidni, ale sviti to a hreje. A vo to go! :)

EDIT: P.S. cely to ma 282 radku :)
« Poslední změna: 17. 03. 2021, 00:35:02 od Mirek Prýmek »

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #57 kdy: 17. 03. 2021, 15:35:59 »
Takze jo, dneska byl pernej den, odreagovat jsem se potreboval, prvni trivialni verze je na svete :) 20B na task a 8B na kanal (to jenom kvuli zarovnani). Takze neco lehce pod tisic tasku na BluePillu :)

Implementaci si zatim necham pro sebe, podelim se jenom o main.

https://gist.github.com/mprymek/d1176be039c8f58e7d3ba4b3b7358e51

Stupidni, ale sviti to a hreje. A vo to go! :)

EDIT: P.S. cely to ma 282 radku :)
Stylem to připomíná GCD.

Re:CSP v embedded světě
« Odpověď #58 kdy: 17. 03. 2021, 21:10:26 »
Stylem to připomíná GCD.
:) Vykládám si to jako poctu :)

Nicméně co mi ještě vrtá hlavou, je, jaký datový typ přes ty kanály přenášet. Tady mám (void *), což je docela praktický, páč se tam dá protlačit v případě potřeby integer a za cenu pohlídání si případné alokace i cokoli přes pointer a velikost je předem známá, dá se alokovat staticky.

FreeRTOS má fronty udělaný přes makra tak, že se dá při vytvoření nastavit velikost přenášených dat, což je fajn, ale zas to kód znepřehledňuje. Implicitní kopírování by se mi líbilo víc než přenášení pointerů, ale nevím, jestli to za tu šarádu kolem stojí... Navíc chci kanály vytvářet dynamicky, což by to ještě komplikovalo... Nevím. Asi to nechám tak, jak to je, a doplním to nějakým hezkým alokátorem. Třeba https://github.com/pavel-kirienko/o1heap

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:CSP v embedded světě
« Odpověď #59 kdy: 17. 03. 2021, 21:50:08 »
Stylem to připomíná GCD.
:) Vykládám si to jako poctu :)

Nicméně co mi ještě vrtá hlavou, je, jaký datový typ přes ty kanály přenášet. Tady mám (void *), což je docela praktický, páč se tam dá protlačit v případě potřeby integer a za cenu pohlídání si případné alokace i cokoli přes pointer a velikost je předem známá, dá se alokovat staticky.

FreeRTOS má fronty udělaný přes makra tak, že se dá při vytvoření nastavit velikost přenášených dat, což je fajn, ale zas to kód znepřehledňuje. Implicitní kopírování by se mi líbilo víc než přenášení pointerů, ale nevím, jestli to za tu šarádu kolem stojí... Navíc chci kanály vytvářet dynamicky, což by to ještě komplikovalo... Nevím. Asi to nechám tak, jak to je, a doplním to nějakým hezkým alokátorem. Třeba https://github.com/pavel-kirienko/o1heap
Doporučuju používat objekty jako v CoreFoundation, bude to bezpečnější.