Příspěvky

226

Vývoj / Re:Arduino a knihovny

« kdy: 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ší...

227

Vývoj / Re:Arduino a knihovny

« kdy: 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.

228

Vývoj / Re:Arduino a knihovny

« kdy: 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.

229

Sítě / Re:POE řešení pro malou síť

« kdy: 18. 03. 2021, 13:41:20 »

Já už switch mám, neexistuje něco tupějšího jako je obyčejný injektor, jen prostě aby jich bylo 16 spojených k sobě v racku?

Pasivní injektor?

Pokud ano, kde a jak jsi hledal, že jsi nic nenašel?

230

Vývoj / Re:Arduino a knihovny

« kdy: 18. 03. 2021, 13:14:34 »

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

57 vláken ti jako nestačí hele

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

231

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

« kdy: 17. 03. 2021, 22:40:46 »

Doporučuju používat objekty jako v CoreFoundation, bude to bezpečnější.

Objekty mi do domu nesmí

232

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

« 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

233

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

« 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

234

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

« 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

235

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

« 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

236

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

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

237

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

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

238

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

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

239

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

« kdy: 16. 03. 2021, 14:06:43 »

Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba “dropdead”) může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.

Jasný, prostě context.Context. Nutný to není, dá se to udělat jinak. A dokonce i elegantněji V Erlangu jsou to linky (viz spawn_link). To je daleko robustnější řešení, protože nezávisí na kooperaci konsumenta. Mně tohle zavírání kanálů přijde spíš jako jejich zneužití. Z jistého pohledu to elegantní je, z jiného nikoli

Shodou okolností jsem přesně na tohle právě teď pěkně nasranej, protože píšu server, který musí obsluhovat net.Conn a zároveň kanály. Právě proto (!), že context.Context funguje přes kanály, není s net.Conn.Read kompatibilní a musí se kolem toho dělat opičky. Nevede to k elegantnímu kódu, ale přesně naopak...

240

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

« kdy: 16. 03. 2021, 13:27:15 »

Ten “lokální buffer” mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba.

Prisne vzato neni, protoze kanal s konecnou kapacitou ma stejny potencialni dusledky jako kanal s kapacitou 1. Nekdy se proste muze zablokovat. A to je asi tak vsechno Jiny by to bylo s kanalem s neohranicenou kapacitou, ale nad tim predpokladam nepremyslis.

Spíš se zaměřuju na zdánlivě nepodstatné, ale veledůležité detaily, třeba to zavírání kanálů, aby šel udělat fan in/out s kontextem apod.

Nejsem si uplne stoprocentne jistej, jestli je zavirani kanalu nutny. Muzes zkusit trochu detailneji popsat, proc si pripadne myslis, ze jo?

Idealni by byl nejakej protipriklad - priklad konkretni situace, ktera bez zavirani kanalu nepujde vyresit.