Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Ano, je tam jistá neinfinitezimální podobnostSamozř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ě.
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)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
Posílal jsem ti tohle i jako SZS dovolením odpovím tady, ať to je na očích. Jo, je to zajímavé, sám si pohrávám s myšlenkou napsat překladač (podmnožiny) Go pro MCU. Osobně bych z několika důvodů upřednostnil ty už zmíněné nafukovací zásobníky. Ten tvůj "divoký"
nápad má v sobě rysy bezzásobníkových korutin (stackless), ale to by asi bylo na MCU zbytečně komplikované. Implicitně toho jde dosáhnout přes bloky, tak jak je má Apple v C (viz Wikipedie: https://en.wikipedia.org/wiki/Blocks_(C_language_extension)). Překladač kopíruje proměnné v případě potřeby naprosto transparentně na haldu (schválně si zkus udělat lokální int p a zírej, jak se po přesunu bloku na haldu změní &p). Tohle je alternativní cesta (výzvou pak je napsat překladač, který by to zautomatizoval).
Ne, SZ jsem si všiml až teď, po upozornění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.
Takže otázka je, jestli vás nenapadá, čím by se daly klasické stacky nahradit, případě jestli by se nedala konkurentnost implementovat nějakým způsobemNejjednodušší 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.
každý proces musí mít vlastní stackProč?
Co se matematiky týče, otevře člověku strašně moc oči. Asi se z nikoho nestal znalec C++, protože studoval algebru, matematickou logiku nebo funkcionální analýzu... Podobné matematické disciplíny ale dávají možnost dívat se na problémy systematicky, využívat netriviální matematické struktury nebo relace atp.Ono to je jedno k druhému, samotná matematika je k ničemu stejně jako učit se izolovaně psát kód. Z VŠE člověk už vyleze se znalostí matematiky, i kdyby šlo jen o absolventa ekonomie bez IT (pár jsem jich doučoval analýzu a lingebru
), s trochou motivace pak dá případné mezery rychle doplnit.
Doporucovat cloveku z VSE, kteryho uz jednou nekde vyrazili MFF nebo FJFI je hodne naivni...Zas tak černě bych to neviděl, na magistru panuje úplně jiný přístup a v případě potíží vyučující pomůžou individuálně.
FIT CVUT je o neco lehci nez vyse zminene (ale slysel sem i od matfyzaku kladne hodnoceni vyuky programovani na FIT), ale prochazka ruzovou zahradou to urcite neni.
Nevim jak jsou ted postaveny PARy, ale bez aspon zakladu diskretky, datovejch struktur a algoritmu to - aspon tenkrat - bylo totalni nogo, nedavali to ani lidi, co meli Bc. z FITu.
Dalsi vec jsou runtime systemy. Na magistru na FITu se nikdo nepta, jestli umis programovat, jestli neumis, zkousnes si v tomhle predmetu hodne horkou pilulku. Nakodit ve dvou za semestr VMku (a mit k tomu jeste dalsi predmety) je dost sousticko i pro zkusenyho.
Tim nerikam, ze to nejak neprebrkas, ale u statnic to po tobe budou stejne chtit.
Asi nemusis bejt nejak extra genialni (i kdyz to je samozrejme vyhoda), to vubec netvrdim. Ale stopro musis mit aspon trochu zkusenosti s kodenim a rozhodne byt dost systematickej, odhodlanej a peclivej.
No offense, ale na tohle te IMO VSE nepripravi...
(viz zprávička na hlavní straně)
Pokud je AJ problém, tak doporučuji knihy Aleše Pultra (matematická analýza a matematické struktury, tj. algebra). Některá jeho skripta jsou volně ke stažení. Nejsou určena pro samouky, ale přinejmenším první díl může posloužit.Pokud se nebojíš, tak doporučuji Feynmanovy přednášky z fyziky. Je to bible fyziků. Feynman byl (mimo jiné) skvělý učitel a jednou na Caltechu učil úvodní kurzy fyziky (měli je i biologové a jiní nefyzici). Nepotřebuješ žádnou předchozí znalost, jede se od nuly. Matematika je tam vysvětlována spíše fyzikálně. Pokud máš rád knihy, mohlo by to být dobrý i v tom, že Feynman rád povídá, takže to není jen výčet rovnic, ale textově dost obsáhlé.
Z Feynmanovych prednasok mam doma jednotku. Ked som ale cital rozne fora, tak tam bolo spominane, ze ich nie je vhodne citat bez predoslych matematickych znalosti. Az potom, ked si ich dostudujem. Preto sa pytam najprv na matematicku literaturu. Vidim a som poteseny, ze mi kolegovia na fore nejake knihy radia. Aj ked kvoli mojej nedobrej znalosti anglictiny by som prijal skor ceske, alebo slovenske knihy, aj ked som rad aj za anglicke.
Dobry programator za dosavadni karieru nasbiral tolik zkusenosti, ze mi prijde skoda je zahodit.Proto by IMHO takoví měli učit/školit.
Kdyby se v této oblasti prosadilo CSP (a korutiny), to by skutečně byla pecka.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.
To vypadá hodně slušně. Já tuhle oblast teď moc nesleduju, musím to dohnatTohle 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
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.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.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.