Fórum Root.cz

Práce => Studium a uplatnění => Téma založeno: klondike12 11. 08. 2018, 15:24:41

Název: Embedded systémy a microcontrollers
Přispěvatel: klondike12 11. 08. 2018, 15:24:41
Pro ty kdo se v této problematice orientují, jak jste začali?

V nabídkách práce je po těchto lidech docela poptávka a vždy mě zajímala "práce na železe". Bohužel nemám žádné praktické zkušenosti. Kde byste je dneska hledali, pro juniorskou pozici?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Mirek 11. 08. 2018, 15:32:47
V nabídkách práce je po těchto lidech docela poptávka a vždy mě zajímala "práce na železe". Bohužel nemám žádné praktické zkušenosti.
Co umíš?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Géomètre 11. 08. 2018, 15:47:32
Pro ty kdo se v této problematice orientují, jak jste začali?
Experimenty doma, s Arduinem, RPi, Mindstorms s pár motorky a senzory. Později jsem vykuchal RC auto a loď a skončil u lidarů. Z pohledu SW stačí umět C nebo C++ a programovat “při zemi”.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Oooo 11. 08. 2018, 15:48:53
 Zacni jako normalni programator ve firme co dela i embeded a po case, kdyz ukazes sve schopnosti pozadej o presazeni do embeded skupiny.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: klondike12 11. 08. 2018, 15:52:35
Nic, moje znalosti skončili u blikání LEDky na Arduinu.  Mě hlavně zajímá jak se do tohle oboru člověk dostane, snad kromě předmětu na škole. Na PC je spousta možností skriptování do her nebo přispívat do projektů nebo cokoliv jiného kde člověk postupně nabere zkušenosti.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: klondike12 11. 08. 2018, 16:06:10
Experimenty doma, s Arduinem, RPi, Mindstorms s pár motorky a senzory. Později jsem vykuchal RC auto a loď a skončil u lidarů. Z pohledu SW stačí umět C nebo C++ a programovat “při zemi”.

To zní hezky, mám doma pár krámů které by šly rozebrat :D
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: RDa 11. 08. 2018, 16:10:56
Prestan hledat co bys delal a delej. Cokoliv. Pak budes mit zkusenosti. Embedded/micro je dosti siroky pojem a jiste mas neco co te zajima. Pokud te zajima jen budouci plat, tak se na to rovnou vykasli a jdi delat neco mene kvalifikovaneho.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: aabb 11. 08. 2018, 16:14:14
Na ZS sa spoluziaci hrali s loptou, ja som sa hral s pajkovackou, rozoberal kde sa co dalo, cital Prakticku elektroniku (nemal som este PC). V 4. rocniku na ZS som nakreslil vyleptal, zalpajkoval prvy plosak. Bol to elektronicky gong. Nerozumel som ako fungoval, ale fungoval. Postupne to bola vyroba zosilnovacov, svetelnych disko efektov... Na strednej mi rodicia kupili PC, tak som zacal objavovat aj cislicovu techniku, AVR procesory,programovanie v Ccku (arduino este nebolo).
Ostalo mi to vsak ako hobby, sem tam este spravim nieco zakazkovo. Web backend, frontend ma ovela viac moznosti na trhu prace a mam dojem ze sa da lahsie dostat k vacsim peniazom ako pri embedded.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: přílepak 11. 08. 2018, 17:54:38
u programovatelné kalkulačky (na úrovni assembleru(goto))
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: jmeno 11. 08. 2018, 21:05:31
Co v oblasti embedded chces delat?

Psani specifikace, analyzu specifikace, navrh a implementace architektury, navrh a implementaci modulu, testovani, integraci, kvalitu, vyvoj toolchainu?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jenda 11. 08. 2018, 22:53:33
Mě hlavně zajímá jak se do tohle oboru člověk dostane, snad kromě předmětu na škole.
To takhle jako malý chodí do kroužku elektroniky a bastlí doma, pak chvíli nic a pak přijde do brmlabu.

Na PC je spousta možností skriptování do her nebo přispívat do projektů nebo cokoliv jiného kde člověk postupně nabere zkušenosti.
Začneš lepením modulů z Adafruitu na Arduino (předtím bych možná doporučil ještě nějaký primer v oblasti základní neprocesorové techniky), pak zjistíš, že chceš to AVRko a čip z toho modulu dát na jednu desku, tak si vyrobíš a zapájíš desku, a pak takhle děláš čím dál tím složitější věci.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Fbi 11. 08. 2018, 23:06:11
Podle me neni dobry napad zacinat s Arduinem. To cloveka proste nuti pouzivat ne uplne low level "ovladace" periferii...
Koupit Megu8. K ni z ebay libovolny proramator... Nastavit fuses na spravnou frekvenci... A pak uz je to simple. Mega8 neni ARM, nakonfit UART je asi na 5 pristupu do registru... Pripojim prevodnik, mebo BT modul... A pak uz se da delat cokoliv.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jenda 12. 08. 2018, 00:18:42
Nevím, mně přijde rozumné používat Arduino, a když člověk potřebuje něco lowlevel (SPI slave, vlastní bootloader, kam se Arduino knihovny nevejdou, přístup k portům rychlejší než přes digitalWrite...), tak začít používat registry.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: mirek 13. 08. 2018, 10:40:09
Nevím, mně přijde rozumné používat Arduino, a když člověk potřebuje něco lowlevel (SPI slave, vlastní bootloader, kam se Arduino knihovny nevejdou, přístup k portům rychlejší než přes digitalWrite...), tak začít používat registry.

Arduino tím "debilizujícím" kabátkem nad embedded systémem začátečníky zbytečně chrání před důležitými detaily. Je vhodné buď pro naprosté začátečníky aby zažili to "wow" při rozhýbání prvního zapojení a nebo pro lidi, kteří už ví co a jak a potřebují něco jednoduchého rychle spíchnout. Pokud se člověk chce učit a opravdu posouvat dopředu, Arduino odloží a jde na "železo"...
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: mirek 13. 08. 2018, 10:43:33
Nic, moje znalosti skončili u blikání LEDky na Arduinu.  Mě hlavně zajímá jak se do tohle oboru člověk dostane, snad kromě předmětu na škole. Na PC je spousta možností skriptování do her nebo přispívat do projektů nebo cokoliv jiného kde člověk postupně nabere zkušenosti.
Doporučuji si nastudovat základy elektrotechnicky, číslicové elektroniky, architekturu mikroprocesorů, zvolit jednoduchou platformu (klidně to AVR), vzít datasheet a další dokumentaci a začít programovat na železe. Vyzkoušet si, jak se pracuje s různými typy vestavěných periférií (timery/countery, komunikační rozhraní, AD/DA převodníky, ...). A pak se třeba začít na něco specializovat.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: anon35 13. 08. 2018, 10:59:33
Mě vždycky přišlo, že v CZ se hw/embedded prakticky nedělá a když už tak naprostá rutina za pár šupů.
Opravte mě, jestli se pletu  ;D
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: anon35 13. 08. 2018, 11:08:49
Vývoj hardware a embedded je v ČR prakticky ukončen, dejte se čistě na software nebo se přestěhujte jinam.

V jiném vláknu to někdo pěkně vystihl.  :) Co znám za lidi s tímhle zaměřením z VŠ, tak většina šla dělat klasikuprogramátora. A práci si hledali hůře, protože v podstatě něco jiného..
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: daemon 13. 08. 2018, 11:25:10
když už tak naprostá rutina za pár šupů.

Čemu říkáš "naprostá rutina za pár šupů"?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 13. 08. 2018, 16:22:55
Čemu říkáš "naprostá rutina za pár šupů"?
V Cechach radove 35-70 (az nejake ty vyjimky). Navic je k tomu nutne znat spoustu veci mimo obor, minimalne jak cist schemata nebo vedet co je hard-real-time (a proc v nem napriklad vicemene ignorovat navrhove vzory jak se pouzivaji napriklad v Jave)
O par dobrych mistech bych vedel, ale zlaty dul je nutne hledat jinde.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Kiwi 14. 08. 2018, 08:50:02
Jak už tu bylo řečeno - u nás mizerně placená, ale přitom v porovnání třeba s Javou náročnější práce. Jinak stačé trochu umět C(++). Bohužel, u spousty projektů je vidět, že to opravdu uměli jen trochu.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Bukanyr 14. 08. 2018, 09:55:09
Zacni doma. Kup si kit s STM32 a neco na tom udelej. Staci jednodussi projekt. Tim se pak muzes pochlubit na pohovoru.

Ale jak bylo receno, je to spatne placena prace vyzadujici hodne znalosti. Na vic v korporatech jsou tak 15 let pozadu co se vyvojovych trendu tyce. Ja dostal nabidku po VS 29k (mimo Prahu). Proto jsem po roce presel na Python i kdyz me embedded bavilo vic.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Bukanyr 14. 08. 2018, 10:05:50
Mě vždycky přišlo, že v CZ se hw/embedded prakticky nedělá a když už tak naprostá rutina za pár šupů.
Opravte mě, jestli se pletu  ;D
Pletes se, tech firem je dost. Eaton, Valeo, Hella, Automotive Lighting, Workswell, Prusa, SatoshiLabs... Staci hledat.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Pytlik 14. 08. 2018, 10:10:38
Jak už tu bylo řečeno - u nás mizerně placená, ale přitom v porovnání třeba s Javou náročnější práce. Jinak stačé trochu umět C(++). Bohužel, u spousty projektů je vidět, že to opravdu uměli jen trochu.

Proč je mizerně placená?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: daemon 14. 08. 2018, 10:12:45
Čemu říkáš "naprostá rutina za pár šupů"?
V Cechach radove 35-70 (az nejake ty vyjimky). Navic je k tomu nutne znat spoustu veci mimo obor, minimalne jak cist schemata nebo vedet co je hard-real-time (a proc v nem napriklad vicemene ignorovat navrhove vzory jak se pouzivaji napriklad v Jave)
O par dobrych mistech bych vedel, ale zlaty dul je nutne hledat jinde.

No, ovšem, zlatý důl...

Tak na zbohatnutí to určitě není. Na to je lepší mastit Javu v korporaci, dělat SAP konzultanta nebo kouřit ču*áky.
Nemohu se zbavit dojmu, že u nás embedded je spíš doména nadšenců, kterým nejde až tak o peníze. Resp. uznávají i jiné formy bohatství, než peněžní.
A stran těch znalostí - embedded není IT, to je spíš elektronika.
V souvislosti s tím nemohu nezmínit, že když vidím, co se dnes v IT děje, tvrdím že lidi v IT jsou těžce přeplácní. Je to bublina, která se stále nafukuje. Počkejte hoši, až jednou praskne...
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: 0x1000 14. 08. 2018, 11:01:48
A stran těch znalostí - embedded není IT, to je spíš elektronika.
Elektronik nenaprogramuje složitější embedded aplikaci. Je potřeba přesah do sw inženýrství.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Kiwi 14. 08. 2018, 12:50:08
Jak už tu bylo řečeno - u nás mizerně placená, ale přitom v porovnání třeba s Javou náročnější práce. Jinak stačé trochu umět C(++). Bohužel, u spousty projektů je vidět, že to opravdu uměli jen trochu.

Proč je mizerně placená?
40-70% odměny, co se dává javistům - platí to všude, na HPP i na ŽL. Už jsem mockrát odmítal práci, když mi nabízeli danou částku argumentujíce průměrem a tím, že to bohužel není Java a proto mi nemohou dát víc.

Čemu říkáš "naprostá rutina za pár šupů"?
V Cechach radove 35-70 (az nejake ty vyjimky). Navic je k tomu nutne znat spoustu veci mimo obor, minimalne jak cist schemata nebo vedet co je hard-real-time (a proc v nem napriklad vicemene ignorovat navrhove vzory jak se pouzivaji napriklad v Jave)
O par dobrych mistech bych vedel, ale zlaty dul je nutne hledat jinde.

No, ovšem, zlatý důl...

Tak na zbohatnutí to určitě není. Na to je lepší mastit Javu v korporaci, dělat SAP konzultanta nebo kouřit ču*áky.
Nemohu se zbavit dojmu, že u nás embedded je spíš doména nadšenců, kterým nejde až tak o peníze. Resp. uznávají i jiné formy bohatství, než peněžní.
A stran těch znalostí - embedded není IT, to je spíš elektronika.
V souvislosti s tím nemohu nezmínit, že když vidím, co se dnes v IT děje, tvrdím že lidi v IT jsou těžce přeplácní. Je to bublina, která se stále nafukuje. Počkejte hoši, až jednou praskne...
No právě, a ti nadšenci kazí ceny. Jiné formy bohatství jsou sice hezké, ale tady je tou jinou formou bohatství "dobrý pocit" z toho, že na mně zaměstnavatel víc vydělá a že vás vyloženě baví se v tom zadarmo vrtat. A že ty chybky jsou často velice zákeřné! Nestačí jen chytit nějakou výjimku.

To přeplácení je jen vlastní hloupost těch zaměstnavatelů. Zaměstnávají neschopné lidi a diví se, že kvůli takovým se práce množí, a tak potřebují další a další, a protože jich je pořád málo, tak jsou přepláceni. Kdyby zaměstnali jednoho, dva schopné, samozřejmě za více peněz než ty ostatní, tak by 2/3 těch ostatních mohli propustit. U embedded to není tak markantní, z práce embedáře by měl průměrný javista osypky - prostě na to musí mít člověk koule a nestává se tak často, že by se na pozici hlásil někdo, kdo o tom neví vůbec nic, což se jinak třeba u té Javy běžně stává a nějakou dobu trvá, než se na to přijde.

A stran těch znalostí - embedded není IT, to je spíš elektronika.
Elektronik nenaprogramuje složitější embedded aplikaci. Je potřeba přesah do sw inženýrství.
Proto říkám, že to je náročnější práce než kódění v Javě. Člověk musí být jak elektronik, tak softwarář, izolovaně se to nedá dělat. U návrhu HW člověk musí přemýšlet, jak se to pak bude SW obsluhovat, programátor by měl chápat, proč je HW udělaný tak jak je a využívat toho. Běžnou součástí vybavení pracoviště embedded programátora je i mikropáječka, osciloskop a logická sonda, debugování je o dva řády složitější než v Javě a o řád než systémařina na PC. Často se dělá s čistě proprietárními věcmi, různorodost platforem je podstatně vyšší, je třeba sestudovat víc materiálů, než se do něčeho člověk pustí. Často je třeba uvažovat o omezeních, o kterých se na PC a vyšších platformách dávno neuvažuje, jako limitace pamětí, rychlostí procesoru apod.

Mně osobně to vyhovuje víc, není sice třeba znát monády a podobné výdobytky, ale člověk by měl mít cit pro to, jak se asi co přeloží do strojáku, kolik to zabere bajtů, kolik taktů atp. Ale embedář musí být buď softwarář, který se naučil i elektroniku, nebo elektrotechnik, který se naučil softwarařinu - jak kdo chce. Bez těch přesahů to zkrátka nejde.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 14. 08. 2018, 12:56:53
A stran těch znalostí - embedded není IT, to je spíš elektronika.
Elektronik nenaprogramuje složitější embedded aplikaci. Je potřeba přesah do sw inženýrství.
Souhlas. Embedded elektronika muze by cokoli od pidiprocesoru ridiciho "blikajici svetelko", pres IoT, kde uz jsou napriklad komunikacni protokoly dost vysoke urovne az po systemy ve kterych neni zabudovany Linux ani videt jak velike je to blokove schema. A jeste k tomu je tu uplatneni pro lidi, kteri dokazi napriklad propojit mobilni aplikaci pres cloud a na druhe strane zemekoule zablikat svetylkem (takze musi znat od vseho kousek)
Dnesni emmbeded to je klidne 1/2 mega radek kodu jen v tom embedded zarizeni.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 14. 08. 2018, 13:08:15
Proto říkám, že to je náročnější práce než kódění v Javě. Člověk musí být jak elektronik, tak softwarář, izolovaně se to nedá dělat. U návrhu HW člověk musí přemýšlet, jak se to pak bude SW obsluhovat, programátor by měl chápat, proč je HW udělaný tak jak je a využívat toho. Běžnou součástí vybavení pracoviště embedded programátora je i mikropáječka, osciloskop a logická sonda, debugování je o dva řády složitější než v Javě a o řád než systémařina na PC. Často se dělá s čistě proprietárními věcmi, různorodost platforem je podstatně vyšší, je třeba sestudovat víc materiálů, než se do něčeho člověk pustí. Často je třeba uvažovat o omezeních, o kterých se na PC a vyšších platformách dávno neuvažuje, jako limitace pamětí, rychlostí procesoru apod.

Mně osobně to vyhovuje víc, není sice třeba znát monády a podobné výdobytky, ale člověk by měl mít cit pro to, jak se asi co přeloží do strojáku, kolik to zabere bajtů, kolik taktů atp. Ale embedář musí být buď softwarář, který se naučil i elektroniku, nebo elektrotechnik, který se naučil softwarařinu - jak kdo chce. Bez těch přesahů to zkrátka nejde.
Proto me prekvapuje, ze to neni placene na urovni jinych IT specializaci. Realita 2018 je takova, ze lepici na foru od IoT resi jak do 6B dat nacpat napriklad 4 teplomery a mezitim stihnou probrat co je HEX kodovani. Bezny absolvent IT oboru netusi co je pointer, odkojeny Javou zna jen referenci. A chtit po nekom jaky dopad ma datova cache procesu, kdyz cerstve zapsana data musim prohnat DMA kanalem, to uz je uplne sci-fi.
A neni to jen u nas. V takovem Nemecku jsou platy o neco vys, ale relativne napriklad k Javarum je to podobne.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: daemon 14. 08. 2018, 13:35:02
Čemu říkáš "naprostá rutina za pár šupů"?
V Cechach radove 35-70 (az nejake ty vyjimky). Navic je k tomu nutne znat spoustu veci mimo obor, minimalne jak cist schemata nebo vedet co je hard-real-time (a proc v nem napriklad vicemene ignorovat navrhove vzory jak se pouzivaji napriklad v Jave)
O par dobrych mistech bych vedel, ale zlaty dul je nutne hledat jinde.

No, ovšem, zlatý důl...

Tak na zbohatnutí to určitě není. Na to je lepší mastit Javu v korporaci, dělat SAP konzultanta nebo kouřit ču*áky.
Nemohu se zbavit dojmu, že u nás embedded je spíš doména nadšenců, kterým nejde až tak o peníze. Resp. uznávají i jiné formy bohatství, než peněžní.
A stran těch znalostí - embedded není IT, to je spíš elektronika.
V souvislosti s tím nemohu nezmínit, že když vidím, co se dnes v IT děje, tvrdím že lidi v IT jsou těžce přeplácní. Je to bublina, která se stále nafukuje. Počkejte hoši, až jednou praskne...
No právě, a ti nadšenci kazí ceny. Jiné formy bohatství jsou sice hezké, ale tady je tou jinou formou bohatství "dobrý pocit" z toho, že na mně zaměstnavatel víc vydělá a že vás vyloženě baví se v tom zadarmo vrtat. A že ty chybky jsou často velice zákeřné! Nestačí jen chytit nějakou výjimku.
Jo, kazí to takoví ti fousatí chlápci v kostkovaných flanelových košilích a menšestrových kalhotách...  ;)
A mají dobrý pocit z toho, že se můžou v tom vrtat. Pocit štěstí. A pocit štěstí je to jediné oč tady kráčí, aby všechny bytosti byly šťastny.

A stran těch znalostí - embedded není IT, to je spíš elektronika.
Elektronik nenaprogramuje složitější embedded aplikaci. Je potřeba přesah do sw inženýrství.
Proto říkám, že to je náročnější práce než kódění v Javě. Člověk musí být jak elektronik, tak softwarář, izolovaně se to nedá dělat. U návrhu HW člověk musí přemýšlet, jak se to pak bude SW obsluhovat, programátor by měl chápat, proč je HW udělaný tak jak je a využívat toho. Běžnou součástí vybavení pracoviště embedded programátora je i mikropáječka, osciloskop a logická sonda, debugování je o dva řády složitější než v Javě a o řád než systémařina na PC. Často se dělá s čistě proprietárními věcmi, různorodost platforem je podstatně vyšší, je třeba sestudovat víc materiálů, než se do něčeho člověk pustí. Často je třeba uvažovat o omezeních, o kterých se na PC a vyšších platformách dávno neuvažuje, jako limitace pamětí, rychlostí procesoru apod.

Mně osobně to vyhovuje víc, není sice třeba znát monády a podobné výdobytky, ale člověk by měl mít cit pro to, jak se asi co přeloží do strojáku, kolik to zabere bajtů, kolik taktů atp. Ale embedář musí být buď softwarář, který se naučil i elektroniku, nebo elektrotechnik, který se naučil softwarařinu - jak kdo chce. Bez těch přesahů to zkrátka nejde.

No a řekni upřimně, není to krása? Chtěl bys radši mastit Javu v korporaci nebo řešit na 68HC11 chybu 33?  ;)

Ale s tím oborovým přesahem to je pravda. Já jsem to prve napsal nešikovně. Je to prostě multioborová disciplína.

Název: Re:Embedded systémy a microcontrollers
Přispěvatel: gll 14. 08. 2018, 14:00:14
debugování je o dva řády složitější než v Javě a o řád než systémařina na PC.

programy jsou o 10 řádů jednodušší.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Trader 14. 08. 2018, 14:34:53
A stran těch znalostí - embedded není IT, to je spíš elektronika.
Elektronik nenaprogramuje složitější embedded aplikaci. Je potřeba přesah do sw inženýrství.
Já bych to SW inženýrství zas tak nepřeceňoval...
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 14. 08. 2018, 14:50:52
programy jsou o 10 řádů jednodušší.
To uz davno ne. Stovky tisic radku jsou uplne bezne i na mikrokontrolerech (externi knihovny a standartni knihovny prekladace nepocitam, dokonce ani generovane datove soubory). Pro porovnani Linux jadro ma neco pres 25M radek a je jednim z nejvetsich samostatnych projektu na svete.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: f 14. 08. 2018, 16:25:20
programy jsou o 10 řádů jednodušší.
To uz davno ne. Stovky tisic radku jsou uplne bezne i na mikrokontrolerech (externi knihovny a standartni knihovny prekladace nepocitam, dokonce ani generovane datove soubory). Pro porovnani Linux jadro ma neco pres 25M radek a je jednim z nejvetsich samostatnych projektu na svete.

Embedded už dávno není jenom hraní s A/D převodníkem a dosahuje značné komplexity i abstrakce. Představte si třeba lokomotivu, nebo běžný osobní vůz disponující třeba 30 ECU. A ten RTOS taky musí někdo napsat...
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: tomík_z 14. 08. 2018, 17:50:01
S tím nízkým platem na tom něco bude. Ono sice embedded expertů moc není, ale firem co dělají embedded vývoj je IMHO ještě méně. Třeba já dělám od supportu pro vývoj HW (podílení se na návrhu a review schémat), přes FPGA (nic velkého, spíš glue logic), jednočipy (od 8-bit 8051 a AVR po 32-bit ARM), linux kernel development (hlavně drivery, ale psal jsem i silně specializovaný filesystém a dělal drobné hacky ve scheduleru, pár věcí jsem protlačil i do upstreamu), vlastní RTOS, linuxové systémové programování v C a v C++ až po nejvyšší vrstvy aplikační vrstvy nad Qt frameworkem vč. GUI. Vedle klávesnice na stole pájka a osciloskop (jak tu už někdo psal), oboje využívané velmi často. Platí mi 30k čistého a víc to už prý nepůjde. Ale práce je to opravdu zajímavá, což beru jako naprosto významný benefit, který mi ten nižší plat kompenzuje, jinak bych se na to vyprdnul a šel něco mastit do korporátu.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: askdlksdf 14. 08. 2018, 21:11:09
A ten RTOS taky musí někdo napsat...
Myslíš ten primitivní scheduler co přepíná tasky? To ti napíšu za odpoledne.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: lebowski 14. 08. 2018, 22:22:04
Naozaj embedded obsahuje viac oborov zároveň, a tiež ma to fascinuje.

Niekedy stretávam ľudí ktorí sú pôvodom elektronici, ale základy
SW architektury ako modularita, genericita, Demeterov zákon im nič nehovoria. Obecne výrazy ako: unit test, pekný kód, dokumentace sú zbytočnosti.
To potom dopadá tak že plošnák síce stihne navrhnúť za víkend, ale celý kód je v "main" metode,
namiesto header file všetko píše literálom a potom je kód plný vecí ako: 0xF4236759
ktorý zapíše do 10 fieldov registra zároveň a po dvoch týždňoch už to po sebe nevie ani prečítať...
Nehovoriac o tom že aj to schématko má celé na jednej strane velkosti A0 ktorá sa dá vytlačiť
akurát tak na nejakom plottri a je to na štýl tape-outu integrovaných obvodov v 70-80 rokoch...

Alebo iná perla je potom človek zo SW ktorý sa začal venovať embedded a netuší čo je to dioda,
register, že v tej FLASH pamäti ten kód neprepíšem bez toho že by som ju premazal, že existuje
DMA, TLB, Cache, alebo čo sú to SoC zbernice ani nehovorím... Do základov digitálneho designu, alebo nebodaj analogu radšej ani zabrusovať nebudem, to by som "nevybrousil".

Vzdávam hold luďom ktorý do aspoň trochu slušnej miery ovládajú oboje a tiež sa o to snažím.
Bohužial to nejde do posledných detailov.

K platom, nízke platy v tomto obore budú dokiaľ sa k tomu ľudia tak budú stavať. Pokiaľ vie človek
ukázať skúsenosti, je ochotný sa samovzdelávať (hold je toho samoučenia veľa keďže je to viac oborov ako sa už písalo), orientuje sa, tak si vie zjednať "dobrý" plat (Úvodzovky kvôli tomu že sme
stále lacná východoeurópska pracovná sila, v Nemecku, Rakúsku Embedded SW, HW, FPGA,
Digital Designer dostane na seniornej úrovni 60-80K Euro ročne)

Konkurencia až tak malá nie je, firiem je aj v ČR na embedded dosť. Iba pre info Eaton ponúkal až 80 na Senior Embedded HW inžiniera. Siemens na Senior Embedded SW vraj niečo okolo 70. Všetko v hrubom. Keď si z toho človek zoberie SHZ, tak sa to pomaly začne štverať na tých javistov čo makajú za 100K plus v korporátoch. Valeo bralo na podobné pozice tiež za 80 a prišli s tým prví
už 3-4 roky dozadu kedy brutálne preplácali konkurenciu aby im niekto išiel makať do "open space".

S tím nízkým platem na tom něco bude. Ono sice embedded expertů moc není, ale firem co dělají embedded vývoj je IMHO ještě méně. Třeba já dělám od supportu pro vývoj HW (podílení se na návrhu a review schémat), přes FPGA (nic velkého, spíš glue logic), jednočipy (od 8-bit 8051 a AVR po 32-bit ARM), linux kernel development (hlavně drivery, ale psal jsem i silně specializovaný filesystém a dělal drobné hacky ve scheduleru, pár věcí jsem protlačil i do upstreamu), vlastní RTOS, linuxové systémové programování v C a v C++ až po nejvyšší vrstvy aplikační vrstvy nad Qt frameworkem vč. GUI. Vedle klávesnice na stole pájka a osciloskop (jak tu už někdo psal), oboje využívané velmi často. Platí mi 30k čistého a víc to už prý nepůjde. Ale práce je to opravdu zajímavá, což beru jako naprosto významný benefit, který mi ten nižší plat kompenzuje, jinak bych se na to vyprdnul a šel něco mastit do korporátu.

30K v čistom vychádza niečo ako 41K v hrubom. Vodič tramvaje dostane v Prahe 35K v hrubom, príde mi absurdné aby človek ako ty dostal 41K. Mojou prioritou je tiež že chcem robiť niečo čo ma baví, preto sa nejdem učiť Javu do banky, ale predsa len by človek mal poznať svoju cenu.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: askdlksdf 15. 08. 2018, 02:59:58
Mojou prioritou je tiež že chcem robiť niečo čo ma baví, preto sa nejdem učiť Javu do banky, ale predsa len by človek mal poznať svoju cenu.
Tak hlavně to nezapomeň robiť ve své rodné krajině a neparazitovat jinde.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: lebowski 15. 08. 2018, 03:26:30
Mojou prioritou je tiež že chcem robiť niečo čo ma baví, preto sa nejdem učiť Javu do banky, ale predsa len by človek mal poznať svoju cenu.
Tak hlavně to nezapomeň robiť ve své rodné krajině a neparazitovat jinde.

systém mi to umožňuje, tak prečo to nevyužiť ;) tie zamindrákované typy ľudí, ktorí nie sú dosť dobrí na to aby na trhu práce zvíťazili nad jedným "čobolákom" ako ja, ma naozaj nezaujímajú.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Kiwi 15. 08. 2018, 08:33:59
debugování je o dva řády složitější než v Javě a o řád než systémařina na PC.

programy jsou o 10 řádů jednodušší.
Teď jde o to, jak posuzuješ jednoduchost/složitost. Počet LOC není měřítko složitosti projektu.

https://www.youtube.com/watch?v=ubaX1Smg6pY
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: mirek 15. 08. 2018, 12:49:52
A ten RTOS taky musí někdo napsat...
Myslíš ten primitivní scheduler co přepíná tasky? To ti napíšu za odpoledne.
Hmmm, pán je expert a už toho má ve skutečných embedded projektech evidentně hodně za sebou.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: pepa 15. 08. 2018, 15:51:03
Nastoupil jsem jako programator v pythonu, parkrat sem pomohl s necim na mikrokontrolerech, ze zacatku aplikacni veci no a ted delam uplne vsechno. Ale ten pyhton mi zustal, dokonce priskocili i veci v cloudu nebo na vps, to samozrejme neslo i prichod javascriptu a dalsich.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 15. 08. 2018, 16:20:00
A ten RTOS taky musí někdo napsat...
Myslíš ten primitivní scheduler co přepíná tasky? To ti napíšu za odpoledne.
Hmmm, pán je expert a už toho má ve skutečných embedded projektech evidentně hodně za sebou.
Presne. Napsat preemtivni prepinani tasku je sranda. Jenze pak nastoupi nutnost posilat mezi tasky data, nutnost znat presne maximalni delku vypnuti interruptu ve vnitrnich kritickych sekcich kvuli zaruceni doby odezvy a to je stale jen miminko a do dospeleho RTOS priserne daleko.
Jeden RTOS mam za sebou. Cca 1 den overeni konceptu. 14 dni aby bylo co predvest a obhajit proc je ten koncept lepsi nez reseni zvazovane k nakupu. A dukaz, ze to "dokazeme udelat" pred managementem. A pak 3 roky do prvniho nasazeni naosto v zarizeni s vlivem na bezpecnost.
Pro predstavu se doporucuji podivat na seL4 mikrojadro a tu matematiku kolem. Pak se podivat na matematiku dokazovani ze to procesor stihne v jinem, nez rate-monotonic planovaci (pro ten je to jednoduche viz dukaz Liu&Layland 1973) napriklad fesibility testy u earliest-deadline-first.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: MarSik 15. 08. 2018, 19:30:52
Pro predstavu se doporucuji podivat na seL4 mikrojadro a tu matematiku kolem. Pak se podivat na matematiku dokazovani ze to procesor stihne v jinem, nez rate-monotonic planovaci (pro ten je to jednoduche viz dukaz Liu&Layland 1973) napriklad fesibility testy u earliest-deadline-first.

Jsou i jiné přístupy. Run-to-completion je třeba o dost jednodušší na napsání (jen jeden stack a žádné mutexy ani semafory). Používá se třeba v Quantum Leaps (preemptivní run-to-completion "interpret" stavových automatů).

Max délku zákazu přerušení samozřejmě musíte u real-time počítat vždy. Obzvláště na těch malých jednojádrech, kde jiná synchronizační primitiva nejsou.

Embedded kód rozhodně není jednodušší oproti "velkému" PC. O co méně má řádků kódu, o to složitější tam jsou interakce a omezení.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: mln 15. 08. 2018, 20:16:32
Ako inžinier v menšej západoslovenskej firme zaoberajúcej vývojom a výrobou elektroniky a embedded programovaniu vidím najviac problém v nedostatku zákazníkov ochotných rozumne zaplatiť komplet vývoj.

Firma si účtuje niečo malo cez 30€ na hodinu (čo je na Slovensku sadzba bežného autoservisu), a na väčšinu cenových ponuk protistrana sa ani neuráči odpovedať alebo vyjednávať o cene (napr zjednodušenie výrobku s cieľom znížiť cenu). Väčšina zákaziek sú nejaké kusové drobnosti alebo subdodavky pre iné väčšie firmy  s cenou ktorá sotva pokryje náklady. Ani z bohatého nemeckeho korporatu nechcú zaplatit normálnu sumu za poloautomatické testovacie pripravky pre biorobotov v montovniach a vykrúcaju kde sa dá.

Je to prúser v prípade že niekto výplatu riešenu systémom skoro minimálna mzda +  odmena == podiel zo zisku zakazky. Takže človek sa musí hrať na vešticu a naceniť zakazku a dúfať že sa neobjavi nejaký skryty technický problém. Pokiaľ sa moj výrobok nedostane do seriovej produkcie, tak som na skoro minimalke. Za vyše 2 roky čo tam robim som šťastie na sériovo vyrábany výrobok nemal, len kusove zakazky.     

Ešte 2-3 roky počkam kym naberiem prax dúfajúc či sa neobjavi nejaký europsky Trump ktory by zaviedol clá/embargo na čínsku elektroniku, a ak nie tak dovi dopo dop*če Slovensko a skúsim šťastie inde.

Fakt netuším prečo kdejaká lopata čo lepí webstranky alebo eshopy sa v pohode dostane platovo cez 1000€ a ak by neboli firmy zaostale tak može pracovať z domu vačšinu pracovného času v pracovnom prostredí bez zvýšeného rizika (a neustaleho podvedomého strachu) zabitia elektrinou/požiaru/výbuchu výkonových polovodičov alebo akumulátorov/nebezpečných strojov a chemikalii a pod.

Rada všetkým študentom, vykašlite sa na embedded programovanie aj elektroniku, aj ked vas to bavi a zvládate to. Burani zakazníci vám za nič z oblasti programovanie C,  RTOS, návrh elektroniky, spracovanie/analýzu signalov, non PLC automatizáciu, yýkonovú elektroniku, EMC nikdy nič poriadne nezaplatia. 
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: JD 15. 08. 2018, 21:20:25
Jsou i jiné přístupy. Run-to-completion je třeba o dost jednodušší na napsání (jen jeden stack a žádné mutexy ani semafory). Používá se třeba v Quantum Leaps (preemptivní run-to-completion "interpret" stavových automatů).

Max délku zákazu přerušení samozřejmě musíte u real-time počítat vždy. Obzvláště na těch malých jednojádrech, kde jiná synchronizační primitiva nejsou.

Embedded kód rozhodně není jednodušší oproti "velkému" PC. O co méně má řádků kódu, o to složitější tam jsou interakce a omezení.
Jojo.
S tim zakazem preruseni je to ale bohuzel tak, ze je nutne jej pouzivat i tam kde jina synchronizacni primitiva jsou, ale nastesti vyjmecne. Mimochodem to me privadi na dalsi lahudku embedded programovani: assembler. Kolik lidi to dnes zvlada na slusne urovni? Bez assembleru napriklad vubec netusim, jak pouzit ARM LDREX/STREX nebo saturovanou matematiku v DSP algoritmech (ARM QADD8 a pod). A uplna lahudka u ktere jsem si vazne odpocinul bylo prepsat foat atan2 algoritmus do ASM tak, aby pro vsechny hodnoty vypocet trval vzdy priblizne stejne dlouho (ono u DSP algoritmu dost vadi, pokud je doba vypoctu ovlivnena vstupni hodnotou a muze se stat, ze v zavislosti na hodnote to CPU nestihne dopocitat vcas)
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Skier 16. 08. 2018, 08:37:30
Ako inžinier v menšej západoslovenskej firme zaoberajúcej vývojom a výrobou elektroniky a embedded programovaniu vidím najviac problém v nedostatku zákazníkov ochotných rozumne zaplatiť komplet vývoj.

Firma si účtuje niečo malo cez 30€ na hodinu (čo je na Slovensku sadzba bežného autoservisu), a na väčšinu cenových ponuk protistrana sa ani neuráči odpovedať alebo vyjednávať o cene (napr zjednodušenie výrobku s cieľom znížiť cenu). Väčšina zákaziek sú nejaké kusové drobnosti alebo subdodavky pre iné väčšie firmy  s cenou ktorá sotva pokryje náklady. Ani z bohatého nemeckeho korporatu nechcú zaplatit normálnu sumu za poloautomatické testovacie pripravky pre biorobotov v montovniach a vykrúcaju kde sa dá.

Je to prúser v prípade že niekto výplatu riešenu systémom skoro minimálna mzda +  odmena == podiel zo zisku zakazky. Takže človek sa musí hrať na vešticu a naceniť zakazku a dúfať že sa neobjavi nejaký skryty technický problém. Pokiaľ sa moj výrobok nedostane do seriovej produkcie, tak som na skoro minimalke. Za vyše 2 roky čo tam robim som šťastie na sériovo vyrábany výrobok nemal, len kusove zakazky.     

Ešte 2-3 roky počkam kym naberiem prax dúfajúc či sa neobjavi nejaký europsky Trump ktory by zaviedol clá/embargo na čínsku elektroniku, a ak nie tak dovi dopo dop*če Slovensko a skúsim šťastie inde.

Fakt netuším prečo kdejaká lopata čo lepí webstranky alebo eshopy sa v pohode dostane platovo cez 1000€ a ak by neboli firmy zaostale tak može pracovať z domu vačšinu pracovného času v pracovnom prostredí bez zvýšeného rizika (a neustaleho podvedomého strachu) zabitia elektrinou/požiaru/výbuchu výkonových polovodičov alebo akumulátorov/nebezpečných strojov a chemikalii a pod.

Rada všetkým študentom, vykašlite sa na embedded programovanie aj elektroniku, aj ked vas to bavi a zvládate to. Burani zakazníci vám za nič z oblasti programovanie C,  RTOS, návrh elektroniky, spracovanie/analýzu signalov, non PLC automatizáciu, yýkonovú elektroniku, EMC nikdy nič poriadne nezaplatia.
To je potíž embedded vývoje. Pro malou firmu bez vlastního produktu je to těžké. Investice a rizika jsou velká. Trh (rozuměj množství zákazníků) malé.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: borekz 16. 08. 2018, 09:58:26
Bez assembleru napriklad vubec netusim, jak pouzit ARM LDREX/STREX nebo saturovanou matematiku v DSP algoritmech (ARM QADD8 a pod).
Na PC už jsem assembler dlouho nepotřeboval, většina x86 instrukcí má nějaký intrinsic v GCC. Bez podobně vybaveného překladače pro ARM bych nedělal, ani kdyby mě platily zlatem. Mimochodem ta intrukce QADDB8 má intrinsic unsigned int __qadd8(unsigned int val1, unsigned int val2), viz http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491f/CHDECGJB.html . Stačil jeden dotaz do Google.
A uplna lahudka u ktere jsem si vazne odpocinul bylo prepsat foat atan2 algoritmus do ASM tak, aby pro vsechny hodnoty vypocet trval vzdy priblizne stejne dlouho (ono u DSP algoritmu dost vadi, pokud je doba vypoctu ovlivnena vstupni hodnotou a muze se stat, ze v zavislosti na hodnote to CPU nestihne dopocitat vcas)
Pokud aplikace potřebuje FP výpočty, ať to dělá CPU. Pokud business model neumožňujr CPU s FPU, tak bych se mohl na takovou lowcost práci vybodnout.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: DeSade 16. 08. 2018, 10:16:50
Existují firmy, který umí kvalitního embeďáka zaplatit, ale je třeba počítat s velkoměstem. Kvalitním embeďákem myslím tu už zmiňovaný skillset kolem RTOS, secure C, elektronika, DSP, hodně žádaný je FPGA.
Pokud vrcholem vašeho skillu je rozblikat ledku, poslat hello přes Arduino a při pohovoru na otázku "co je to pointer?" tvrdit, že všechno jde se naučit, tak se nedivte, že máte lopaťáckou výplatu. To jenom taková jízlivá poznámka k tomu, co teď vychází ze škol.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Bacsa 16. 08. 2018, 10:33:08
[...] při pohovoru na otázku "co je to pointer?" tvrdit, že všechno jde se naučit, tak se nedivte, že máte lopaťáckou výplatu. To jenom taková jízlivá poznámka k tomu, co teď vychází ze škol.
K čemu ty školy teda jsou?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: TVL 16. 08. 2018, 11:17:16
Existují firmy, který umí kvalitního embeďáka zaplatit, ale je třeba počítat s velkoměstem. Kvalitním embeďákem myslím tu už zmiňovaný skillset kolem RTOS, secure C, elektronika, DSP, hodně žádaný je FPGA.
Pokud vrcholem vašeho skillu je rozblikat ledku, poslat hello přes Arduino a při pohovoru na otázku "co je to pointer?" tvrdit, že všechno jde se naučit, tak se nedivte, že máte lopaťáckou výplatu. To jenom taková jízlivá poznámka k tomu, co teď vychází ze škol.

To je úplně zbytečné. Fakt je ten, že stejně kvalitní člověk s nějakým úměrným množstvím znalostí dostane za javu výrazně více než za embedded/MC. Nechci psát, že je to dvojnásobek, ale nebude to tomu daleko.
Tak je prostě trh nastaven. Je to tím, že v javě sei v Česku dělají velké projekty pro bohaté zákazníky a v embedded/mc se tady takové projekty nedělají. Nicméně to, že za vývoj blízko hardwaru se bere více, než za bankovní javu (ačkoliv na ten low-level musíte být větší machr, než na tu javu), to platí všude na světě.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Kiwi 16. 08. 2018, 11:18:22
Existují firmy, který umí kvalitního embeďáka zaplatit, ale je třeba počítat s velkoměstem. Kvalitním embeďákem myslím tu už zmiňovaný skillset kolem RTOS, secure C, elektronika, DSP, hodně žádaný je FPGA.
Pokud vrcholem vašeho skillu je rozblikat ledku, poslat hello přes Arduino a při pohovoru na otázku "co je to pointer?" tvrdit, že všechno jde se naučit, tak se nedivte, že máte lopaťáckou výplatu. To jenom taková jízlivá poznámka k tomu, co teď vychází ze škol.
A které třeba?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 16. 08. 2018, 11:20:47
Na PC už jsem assembler dlouho nepotřeboval, většina x86 instrukcí má nějaký intrinsic v GCC. Bez podobně vybaveného překladače pro ARM bych nedělal, ani kdyby mě platily zlatem. Mimochodem ta intrukce QADDB8 má intrinsic unsigned int __qadd8(unsigned int val1, unsigned int val2), viz http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491f/CHDECGJB.html . Stačil jeden dotaz do Google.
No dobre, QADD8 nebyl nejlepsi priklad. Lepsi je LDREX/STREX, kde uz to tak snadne neni. Nebo QADD, kdyz je zaroven nutne testovat vysledny Q flag stavoveho registru.

Pokud aplikace potřebuje FP výpočty, ať to dělá CPU. Pokud business model neumožňujr CPU s FPU, tak bych se mohl na takovou lowcost práci vybodnout.
Pouzity procesor ma FPU jednotku. Jenze tohle byl hotspot v kodu, knihovni funkce potrebuje pres 200 tiku, optimalizovana pro DSP zapsana v C 45-120 podle vstupnich dat a totez optimalizovane rucne v ASM 60-63 tiku. Takova tresnicka na dortu. Proste jsem si to vychutnal, tohle clovek nedela kazdy den, ale v real time aplikaci je nutne mit v tymu nekoho, kdo to dokaze, to byla ta pointa.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: TVL 16. 08. 2018, 11:29:52
Pokud aplikace potřebuje FP výpočty, ať to dělá CPU. Pokud business model neumožňujr CPU s FPU, tak bych se mohl na takovou lowcost práci vybodnout.

Ale to vůbec nemusí být lowcost. To může být skvěle zafinancovaný projekt, jenom je tam obrovské cílové množství výrobků, takže se logicky tlačí cena procesoru dolů o každý dolar (případně je to prototyp, na základně kterého se potom bude vyvíjet ta finální velkosériová verze).
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: v 16. 08. 2018, 11:44:02
A které třeba?
+1
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: DeSade 16. 08. 2018, 12:44:03
A které třeba?
NXP, Honeywell (i když tam to poslední roky šlo do neskutečných sraček)
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Skier 16. 08. 2018, 12:52:29
Pokud aplikace potřebuje FP výpočty, ať to dělá CPU. Pokud business model neumožňujr CPU s FPU, tak bych se mohl na takovou lowcost práci vybodnout.
Další zjednodušující pohled na svět... Zkus si to samé myšlenkové cvičení zopakovat pro jakýkoliv jiný algoritmus, který ale v FPU zadrátovaný není. Budeš trvat na dedikovaném FPGA, které problém vyřeší, a odmítat postupovat jinak, protože by to byla jen pitomá lowcost práce, na kterou se můžeš vybodnout?

Hodně štěstí. Na světě se najde spousta lidí, kteří se na ni nevybodnou a ty se nakonec třeba budeš divit, proč se tvé skvělé řešení neprodává.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: MarSik 16. 08. 2018, 14:19:43
Bez assembleru napriklad vubec netusim, jak pouzit ARM LDREX/STREX nebo saturovanou matematiku v DSP algoritmech (ARM QADD8 a pod).

CMSIS to umí (ale jmenuje se to stejně podle té instrukce :) https://www.keil.com/pack/doc/cmsis/Core/html/group__intrinsic__SIMD__gr.html

A DSP funkcí je taky spoustu připravených: https://www.keil.com/pack/doc/CMSIS/DSP/html/modules.html
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 16. 08. 2018, 14:40:09
CMSIS to umí (ale jmenuje se to stejně podle té instrukce :) https://www.keil.com/pack/doc/cmsis/Core/html/group__intrinsic__SIMD__gr.html

A DSP funkcí je taky spoustu připravených: https://www.keil.com/pack/doc/CMSIS/DSP/html/modules.html
Ten priklad s QADD8 byl nevhodny. Lepsi priklad je QADD s vyuzitim Q flagu ve status registru.
Mimochodem CMSIS funkci atan2 neobsahuje.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: MarSik 16. 08. 2018, 16:03:47
Máte samozřejmě pravdu, chtěl jsem jen ilustrovat, že ASM už není zase tak potřebný, pokud nejde o nějakou specialitu. Většina kódu může být napsaná ve vyšším jazyce a jen kritické části se občas optimalizují ručně. Dnešní překladače jsou kvalitní a vyrovnat se jim není v běžném případě vůbec lehké.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 16. 08. 2018, 16:17:40
Máte samozřejmě pravdu, chtěl jsem jen ilustrovat, že ASM už není zase tak potřebný, pokud nejde o nějakou specialitu. Většina kódu může být napsaná ve vyšším jazyce a jen kritické části se občas optimalizují ručně. Dnešní překladače jsou kvalitní a vyrovnat se jim není v běžném případě vůbec lehké.
Tak to souhlas. Rucni ASM ma vyznam jen na specielni pripady jenze ty se ve svete emmbeded vyskytuji v nenulovem poctu.
Assembler pro male procesory clovek jeste v pohode zvada. Ale to jde tak do urovne ARM Cortex-M. Jenze pak nastupuji jadra, krera maji dlouhou pipeline a schopnost vykonani vice intrukci najednou (ARM Cortex-R nebo Cortex-A a jine) a tam uz je pri rucnim kodovani tezke az nemozne vyhrat nad kompilatorem. Jeho schopnost seradit instrukce tak, ze dela vlastne nekolik veci najednou aby pokud mozno zadna instukce nemusela cekat na predchzejici vysledek to je kolikrat na palici i jen to precist.
Ale hlavni duvod vyssiho jazyka je stejne udrzovatelnost kodu. Takze za me rucni ASM jen kdyz je k tomu nejaky zatracene dobry duvod.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Embedák 16. 08. 2018, 16:36:46
Ad1) Tak ako v inych odboroch, tak aj embedded vyvojar ma specializaciu, a je ich urcite hodne... Pri dnesnej komplikovanosti procesorov (akejkolvek architektury), je takmer nemozne pokryt (casovo/vedomostne) vsetky mozne periferie/sposoby. Proste, niekto je zamerany viac na SW vyvoj v embedded, niekto viac na HW..

Ad2) Za 8 rokov praxe nepoznam nikoho kto by sam pokryl nejaky cpu.. mozno tak CortexM0/+ .. pozrite si M4 s DSP alebo M7.. to o A-ckovych/R-kovych ani nehovorim...

Ad3) V 99,5% percentach kodu ktore sme robili, sme pouzivali ciste C.. ma to vela vyhod, napr staticka analyza kodu, unit testy, dokaze sa robit review testu, kodu... zvysnich 0,5% kodu boli optimalizovane ASM sekcie, ale kazda sekcia sa testovala predtym nez sa pouzila... a ajtak sa nasli po rokoch chyby...
Dnes ma procesor bezne 128/256/512/1024/2048/4096 kb Flasky, alebo obsahuje SD/RAM controller... Tak naco stracat drahocenny cas optimalizaciou niecoho co vo vacsine pripadou nieje ani treba...

Ad3a) V jednej jedinej aplikacii som videl vacsie pouzitie asm.. a to pre automotive motor control.. aj to len pre safety a fastloop (niektore vypocty vo FRAC aritmetike).. inac 95% kodu bolo v C...

Ad4) Na "trhu" je mnozstvo RTOS (https://www.osrtos.com/) takze pisat si svoj vlastny RTOS je vhodny leda tak na prehlbenie znalosti, inac je to strata casu... FreeRTOS je de-facto standard pre male MCU, a to pre vhodnu licenciu, jednoduchu portaciu, pekny memory model a dobru dokumentacku.. a ked nieco nejde tak si firma kupit ten zaklad co predava... support...

Ad5) v CR/AT/DE je dost embedded firiem ktore vedia dobre zaplatit (sam v jednej robim :)). Praca ma bavi, je zaujimava a clovek niekedy dostava takmer infarkt ked debbuguje dosku, pri tom cita schemu, a ma otvoreny RM.
Je to nieco medzi sadizmom, pozitkom, flustraciou a vnutornou vyzvou.

Osobne, embedded svet je velmi zaujimavy, urcite nieje fadny a nudny, komplikovanost je ale velmi vysoka takze to neni pre kazdeho.. Ale zasa, niekedy sa clovek vie pekne vysantit :)
Drzim palce. ::)
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Skier 16. 08. 2018, 16:53:55
Ad4) Na "trhu" je mnozstvo RTOS (https://www.osrtos.com/) takze pisat si svoj vlastny RTOS je vhodny leda tak na prehlbenie znalosti, inac je to strata casu... FreeRTOS je de-facto standard pre male MCU, a to pre vhodnu licenciu, jednoduchu portaciu, pekny memory model a dobru dokumentacku.. a ked nieco nejde tak si firma kupit ten zaklad co predava... support...
Nejde jen o prohloubení znalostí. Někdy jde o specifické požadavky, které není jednoduché splnit off-the-shelf produktem. A je nutné nezapomínat i na vendor lock-in a další rizika.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 16. 08. 2018, 17:26:14
Ad1) Tak ako v inych odboroch, tak aj embedded vyvojar ma specializaciu, a je ich urcite hodne... Pri dnesnej komplikovanosti procesorov (akejkolvek architektury), je takmer nemozne pokryt (casovo/vedomostne) vsetky mozne periferie/sposoby. Proste, niekto je zamerany viac na SW vyvoj v embedded, niekto viac na HW..

Ad2) Za 8 rokov praxe nepoznam nikoho kto by sam pokryl nejaky cpu.. mozno tak CortexM0/+ .. pozrite si M4 s DSP alebo M7.. to o A-ckovych/R-kovych ani nehovorim...
MCU, ktery ted pouzivame ma pres 20tis stran dokumentace (appnotes nepocitam). Jen popis jadra je nekolik tisic, dalsi tisice periferie.
To vazne do hlavy uz nikdo nenacpe.
Ad3) V 99,5% percentach kodu ktore sme robili, sme pouzivali ciste C.. ma to vela vyhod, napr staticka analyza kodu, unit testy, dokaze sa robit review testu, kodu... zvysnich 0,5% kodu boli optimalizovane ASM sekcie, ale kazda sekcia sa testovala predtym nez sa pouzila... a ajtak sa nasli po rokoch chyby...
Dnes ma procesor bezne 128/256/512/1024/2048/4096 kb Flasky, alebo obsahuje SD/RAM controller... Tak naco stracat drahocenny cas optimalizaciou niecoho co vo vacsine pripadou nieje ani treba...

Ad3a) V jednej jedinej aplikacii som videl vacsie pouzitie asm.. a to pre automotive motor control.. aj to len pre safety a fastloop (niektore vypocty vo FRAC aritmetike).. inac 95% kodu bolo v C...
No prave. Vetsinou to neni treba. V nasem aktualnim projektu je to 99% C, 1% ASM. Vime jak je tezke ten drobek ASM testovat a udrzovat, ale prepsat do C to nejde.
Napriklad ten atan2 byl ve smycce 40us opakovani a nebyl tam sam. Naroky na rizeni se stale zvysuji jak roste rychlost vykonovych prvku kvuli tlaku na zmensovani, zvysovani efektivity atd.
Ad4) Na "trhu" je mnozstvo RTOS (https://www.osrtos.com/) takze pisat si svoj vlastny RTOS je vhodny leda tak na prehlbenie znalosti, inac je to strata casu... FreeRTOS je de-facto standard pre male MCU, a to pre vhodnu licenciu, jednoduchu portaciu, pekny memory model a dobru dokumentacku.. a ked nieco nejde tak si firma kupit ten zaklad co predava... support...
Pro napsani vlastniho RTOS byly technicke duvody, ktere nemuzu rozebirat (NDA). Z free veci nevyhovovalo nic, takze jsme meli vyrizeny nakup RTOS v radu milionu + dalsi milony rocniho maintainance. A pak stopka z technickych duvodu a resilo se jesli si nechat udelat upravu existujiciho reseni dodavatelem nebo jit vlastni cestou.
Ad5) v CR/AT/DE je dost embedded firiem ktore vedia dobre zaplatit (sam v jednej robim :)). Praca ma bavi, je zaujimava a clovek niekedy dostava takmer infarkt ked debbuguje dosku, pri tom cita schemu, a ma otvoreny RM.
Je to nieco medzi sadizmom, pozitkom, flustraciou a vnutornou vyzvou.

Osobne, embedded svet je velmi zaujimavy, urcite nieje fadny a nudny, komplikovanost je ale velmi vysoka takze to neni pre kazdeho.. Ale zasa, niekedy sa clovek vie pekne vysantit :)
Drzim palce. ::)
Na stole mam 3 velke monitory a ani tak se to na ne nechce vejit. :-) IDE, hromada otevrenych datasheetu a schemat a par dalsich veci jako logicky analyzator a hned jsou 3 monitory malo. :-)
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Kiwi 16. 08. 2018, 21:02:10
Dnešní překladače jsou kvalitní a vyrovnat se jim není v běžném případě vůbec lehké.
Ha ha ha! Doporučuji občas nahlédnout do listingu. Ještě jsem nenarazil na případ, kdy bych to nenapsal lépe snad i poslepu! (GCC @ ARM M3, Keil @ ARM7TDMI).
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: JD 16. 08. 2018, 22:25:56
Dnešní překladače jsou kvalitní a vyrovnat se jim není v běžném případě vůbec lehké.
Ha ha ha! Doporučuji občas nahlédnout do listingu. Ještě jsem nenarazil na případ, kdy bych to nenapsal lépe snad i poslepu! (GCC @ ARM M3, Keil @ ARM7TDMI).
No prave, ze do listingu koukam dost casto. Ten kod casto vypada divne, ale kdyz to clovek porovna s tim, kdy je ktery operand potreba a kdy je k dispozici vysledek, dava to lepsi smysl. Ale pravda koukam predevsim na Cortex-R (ruzne prekladace GCC, Keil, TI, ARM)
Zkusenost rika, ze se v ASM funkci vetsi nez male stovky radek clovek ztrati prehled a ten kod nic moc.
Priblizne stejne slozity matematicky vypocet pres 10-20 radek v C dokaze kompilator lepe. Napriklad proto, ze je schopen si udrzet strom zavislosti co k cemu potrebuje a optimalne na to vyuzit dostupne registry.
A to rikam z pohledu, kdy vim jak napsat "lepsi" kod nez kompilator. Ale zatracene vim kolik namahy to stoji a ze v 99% pripadu je lepsi se na to vykaslat. "Lepsi" kod je zamerne v uvozovkach, protoze je vzdy nutne vedet na co se optimalizuje. Na prumernou rychlost? Na worst-case rychlost? Vymenit rychlost za spotrebu pameti nebo obracene? Velikost kriticke sekce? Tech kriterii je mozne sestavit cely seznam.
Napriklad u ARMu uplna banalita. 32bit konstanta do registru. Pouzit MOVW+MOVT (a mam neco cim je prolozit aby procesor nevlozil wait?), nebo nejakou z variant PC-relative loadu (LDR, LDRD, ADR+LDM). Dost se to lisi, kdyz potrebuji 1 konstantu, kdyz jich potrebuju vic. Je to z nejake tabulky? Nevyplati se zarovnat na 64bit abych pro LRM nebo LDRD usetril buscyklus (nas MCU ma vnitrne 64bit sbernici)?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Kiwi 16. 08. 2018, 23:56:59
Dnešní překladače jsou kvalitní a vyrovnat se jim není v běžném případě vůbec lehké.
Ha ha ha! Doporučuji občas nahlédnout do listingu. Ještě jsem nenarazil na případ, kdy bych to nenapsal lépe snad i poslepu! (GCC @ ARM M3, Keil @ ARM7TDMI).
No prave, ze do listingu koukam dost casto. Ten kod casto vypada divne, ale kdyz to clovek porovna s tim, kdy je ktery operand potreba a kdy je k dispozici vysledek, dava to lepsi smysl. Ale pravda koukam predevsim na Cortex-R (ruzne prekladace GCC, Keil, TI, ARM)
Zkusenost rika, ze se v ASM funkci vetsi nez male stovky radek clovek ztrati prehled a ten kod nic moc.
Priblizne stejne slozity matematicky vypocet pres 10-20 radek v C dokaze kompilator lepe. Napriklad proto, ze je schopen si udrzet strom zavislosti co k cemu potrebuje a optimalne na to vyuzit dostupne registry.
A to rikam z pohledu, kdy vim jak napsat "lepsi" kod nez kompilator. Ale zatracene vim kolik namahy to stoji a ze v 99% pripadu je lepsi se na to vykaslat. "Lepsi" kod je zamerne v uvozovkach, protoze je vzdy nutne vedet na co se optimalizuje. Na prumernou rychlost? Na worst-case rychlost? Vymenit rychlost za spotrebu pameti nebo obracene? Velikost kriticke sekce? Tech kriterii je mozne sestavit cely seznam.
Napriklad u ARMu uplna banalita. 32bit konstanta do registru. Pouzit MOVW+MOVT (a mam neco cim je prolozit aby procesor nevlozil wait?), nebo nejakou z variant PC-relative loadu (LDR, LDRD, ADR+LDM). Dost se to lisi, kdyz potrebuji 1 konstantu, kdyz jich potrebuju vic. Je to z nejake tabulky? Nevyplati se zarovnat na 64bit abych pro LRM nebo LDRD usetril buscyklus (nas MCU ma vnitrne 64bit sbernici)?
Z dob mých studií si matně pamatuji z přednášek o kompilátorech, že alokace registrů je netriviální problém. Při pohledu na listingy mám pocit, že se v tomto ohledu od těch dob moc nepokročilo. Ten kód je nejen zbytečně dlouhý, ale i pomalý - naprosto nesmyslné rošády mezi registry, na něž někdy má a někdy nemá vliv tvrdé nastavení proměnné do určitého registru; opakované vytváření konstant, ačkoli registr, který ji obsahuje, není vůbec třeba měnit; proměnné na zásobníku, ačkoli by mohly být v registrech; neschopnost efektivně používat LDM; zbytečné uklízení hodnot, které již nebudou zapotřebí; zbytečné skoky na BX LR nebo obecně na jednoinstrukcové podprogramy místo inlinování... atp.

Také už neprogramuji v Assembleru, ale za dob osmibitů jsem si toho užil dosytosti, můj poslední 100% ASM projekt byl pro jeden 16bitový FXP DSP od Analogů někdy před 10 lety, a zásadně nesouhlasím s tvrzením, že v tom nejde napsat rozsáhlejší program pro nepřehlednost. Vyžaduje to cvik, trochu jiný způsob dekompozice, ale samozřejmě, že to jde. Že dnešní kompilátor dokáže vygenerovat kód srovnatelný s ručně psaným, či dokonce ještě lepší, je ale nebetyčný kec.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: hu 17. 08. 2018, 00:07:35
Dnešní překladače jsou kvalitní a vyrovnat se jim není v běžném případě vůbec lehké.
Ha ha ha! Doporučuji občas nahlédnout do listingu. Ještě jsem nenarazil na případ, kdy bych to nenapsal lépe snad i poslepu! (GCC @ ARM M3, Keil @ ARM7TDMI).
No prave, ze do listingu koukam dost casto. Ten kod casto vypada divne, ale kdyz to clovek porovna s tim, kdy je ktery operand potreba a kdy je k dispozici vysledek, dava to lepsi smysl. Ale pravda koukam predevsim na Cortex-R (ruzne prekladace GCC, Keil, TI, ARM)
Zkusenost rika, ze se v ASM funkci vetsi nez male stovky radek clovek ztrati prehled a ten kod nic moc.
Priblizne stejne slozity matematicky vypocet pres 10-20 radek v C dokaze kompilator lepe. Napriklad proto, ze je schopen si udrzet strom zavislosti co k cemu potrebuje a optimalne na to vyuzit dostupne registry.
A to rikam z pohledu, kdy vim jak napsat "lepsi" kod nez kompilator. Ale zatracene vim kolik namahy to stoji a ze v 99% pripadu je lepsi se na to vykaslat. "Lepsi" kod je zamerne v uvozovkach, protoze je vzdy nutne vedet na co se optimalizuje. Na prumernou rychlost? Na worst-case rychlost? Vymenit rychlost za spotrebu pameti nebo obracene? Velikost kriticke sekce? Tech kriterii je mozne sestavit cely seznam.
Napriklad u ARMu uplna banalita. 32bit konstanta do registru. Pouzit MOVW+MOVT (a mam neco cim je prolozit aby procesor nevlozil wait?), nebo nejakou z variant PC-relative loadu (LDR, LDRD, ADR+LDM). Dost se to lisi, kdyz potrebuji 1 konstantu, kdyz jich potrebuju vic. Je to z nejake tabulky? Nevyplati se zarovnat na 64bit abych pro LRM nebo LDRD usetril buscyklus (nas MCU ma vnitrne 64bit sbernici)?
Z dob mých studií si matně pamatuji z přednášek o kompilátorech, že alokace registrů je netriviální problém. Při pohledu na listingy mám pocit, že se v tomto ohledu od těch dob moc nepokročilo. Ten kód je nejen zbytečně dlouhý, ale i pomalý - naprosto nesmyslné rošády mezi registry, na něž někdy má a někdy nemá vliv tvrdé nastavení proměnné do určitého registru; opakované vytváření konstant, ačkoli registr, který ji obsahuje, není vůbec třeba měnit; proměnné na zásobníku, ačkoli by mohly být v registrech; neschopnost efektivně používat LDM; zbytečné uklízení hodnot, které již nebudou zapotřebí; zbytečné skoky na BX LR nebo obecně na jednoinstrukcové podprogramy místo inlinování... atp.

Také už neprogramuji v Assembleru, ale za dob osmibitů jsem si toho užil dosytosti, můj poslední 100% ASM projekt byl pro jeden 16bitový FXP DSP od Analogů někdy před 10 lety, a zásadně nesouhlasím s tvrzením, že v tom nejde napsat rozsáhlejší program pro nepřehlednost. Vyžaduje to cvik, trochu jiný způsob dekompozice, ale samozřejmě, že to jde. Že dnešní kompilátor dokáže vygenerovat kód srovnatelný s ručně psaným, či dokonce ještě lepší, je ale nebetyčný kec.

A to se radsi nebavme o chybach v prekladacich. Xilinx verze gcc, ktera byla distribuovana s jakousi verzi (jeste) ISE, prpro architekturu Microblaze generovala (pouze!) na -O3 pri sudych shiftech na konfiguracich bez barrel shifteru o shift navic. Takze >> 24 shiftlo o 25 bitu. Happy debugging.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: JD 17. 08. 2018, 01:11:01
Také už neprogramuji v Assembleru, ale za dob osmibitů jsem si toho užil dosytosti, můj poslední 100% ASM projekt byl pro jeden 16bitový FXP DSP od Analogů někdy před 10 lety, a zásadně nesouhlasím s tvrzením, že v tom nejde napsat rozsáhlejší program pro nepřehlednost. Vyžaduje to cvik, trochu jiný způsob dekompozice, ale samozřejmě, že to jde. Že dnešní kompilátor dokáže vygenerovat kód srovnatelný s ručně psaným, či dokonce ještě lepší, je ale nebetyčný kec.
Tady bych si dovolil nesouhlasit. 100% projekt v ASM uz jsem uz taky mel (aby se to do procesoru vubec veslo, i tak tam zbyvalo nekolik byte, vetsi procesor tehdy nebyl, ale to uz je 20 let zpatky)
Pronlem s ASM neni v tom, ze neexistuje absolutni moznost napsat lepsi kod. Potiz programovani je, ze jakmile SW zacne fungovat, tak se ukaze, jak by bylo neco lepsi udelat jinak. A menit vysoce optimalizovany kod v ASM aby zustal optimalizovany je jednim slovem peklo.
Druhy duvod je pipeline modernejsich procesoru, kdy je treba mit v hlave tabulky, kolik tiku musi byt pripraveny operand pro intrukci pred jejim vykonanim, ze je to jine podle intrukce i pro jednotlive operandy v instrukci, jake je zpozdeni vysledku, ktere instrukce nemohou byt zpracovany soucasne a i dalsi veci.
Takze to, ze je kompilatorem generovany kod prumerne lepsi nez rucne psany, za tim stojim. Moje zkusenosti jsou, ze prepsat neco do ASM z vykonovych duvodu je vyhodne az v momente, kdy na te casti kodu nehodlam "nikdy a nic menit" a zaroven je k tomu dobry duvod. Ale v kazdem pripade doba, kdy jsem dokazal prepsat dekompresni algoritmus LZO, aby byl skoro 2x rychlejsi nez ten z GCC kompilatoru byla aktualni pred 15lety a uz se nevrati a neni to tim, ze bych zblbnul (mimochodem bylo to pro zajimavy procesor jadro AM32).
Mimochodem, aby kompilator ze zapnutou optimalizaci napriklad uklizel hodnotu, kterou nebude potrebovat, nebo blbe nacital konstanty jsem v kodu za poslenich nekolik let videl zcela vyjmecne.
Kdyz uz jsem u tech nedostatku kompilatoru: vite o tom, ze kdyz optimalizator v GCC (myslim, ze i aktualni) vyhodnoti pointer z vyrazu jako konstantni NULL, pak misto nejakeho varovani nebo rovnou erroru pri kompilaci vlozi do kodu zamerne nevalidni instrukci? Prenecha tedy runtime chybu, kterou je mozne odhalit v dobe prekladu.
Alokace registru rozhodne je netrivialni problem, ktery stale neni doresen. Jenze clovek, ktery to pise rucne ma uplne stejny problem jako stroj.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 17. 08. 2018, 13:32:57
A jeste jednu vec ohledne moznosti psat ASM rucne jsem zapomel.
Se strojovym kompilatorem je mozne provadet kouzla typu Link Time Optimization (LTO). Totez dokazat rucne u vetsiho projektu je v podstate na hranici mozneho.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: 0x1000 17. 08. 2018, 15:37:14
Btw jaký používáte logický analyzátor? My jsme si velmi oblíbili Saleae Logic Pro 16.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: Jiri Dobry 17. 08. 2018, 16:20:09
Btw jaký používáte logický analyzátor? My jsme si velmi oblíbili Saleae Logic Pro 16.
DSLogic Plus (16bit a az 400MHz) jako nejcastejsi zakladni nastroj. Jinak na hrani doma 8bit saleae (ten prvni bez bufferu a kaslat na ten jejich SW, sigrok PulseView je lepsi)
A kdyz jde do tuheho, tak profi osciloskop s 4 analogy a 16 log kanaly, obcas je totiz problem v analogovych parametrech jako uroven, strmost, preslechy, je mozne zmerit diferencialni signal atd. Ten ma proti hrackam do USB radove vyssi samplerate.
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: askdlksdf 17. 08. 2018, 16:53:14
Btw jaký používáte logický analyzátor? My jsme si velmi oblíbili Saleae Logic Pro 16.
k čemu je to dobré? nestačí osciloskop?
Název: Re:Embedded systémy a microcontrollers
Přispěvatel: MarSik 20. 08. 2018, 15:12:47
Btw jaký používáte logický analyzátor? My jsme si velmi oblíbili Saleae Logic Pro 16.
k čemu je to dobré? nestačí osciloskop?

Nestačí.

Osciloskop: Málo vstupů, žádné složité triggery a obvykle nemá dekodér na protokoly. Ukáže i analogové vlastnosti.
Logický analyzátor: Hodně vstupů (16, 32), umí dekódovat protokoly, umí počkat na netriviální sekvenci. Ale neukáže problém s analogovou doménou.

Na bastlení používám obyč. Open Bench Logic Sniffer, teoreticky 200 Mhz a až 16/32 kanálů.
Název: Rušní asm versus kompilátor
Přispěvatel: Miloslav Ponkrác 08. 09. 2018, 00:17:03
Citace
Ha ha ha! Doporučuji občas nahlédnout do listingu. Ještě jsem nenarazil na případ, kdy bych to nenapsal lépe snad i poslepu! (GCC @ ARM M3, Keil @ ARM7TDMI).

Pro ARM není až tak těžké napsat kód lepší než vygeneruje kompilátor.

Pro x86/x64 už je to ale velký problém. Kompilátory generují tak dobrý kód, který bere v úvahu i vnitřní architekturu procesoru, celou pipeline, atd. - že jsou třeba obrovské znalosti k napsání lepšího kódu.

Výše uvedené platí platí pro optimalizaci na rychlost.
Název: Re:Rušní asm versus kompilátor
Přispěvatel: Kiwi 08. 09. 2018, 00:43:24
Citace
Ha ha ha! Doporučuji občas nahlédnout do listingu. Ještě jsem nenarazil na případ, kdy bych to nenapsal lépe snad i poslepu! (GCC @ ARM M3, Keil @ ARM7TDMI).

Pro ARM není až tak těžké napsat kód lepší než vygeneruje kompilátor.

Pro x86/x64 už je to ale velký problém. Kompilátory generují tak dobrý kód, který bere v úvahu i vnitřní architekturu procesoru, celou pipeline, atd. - že jsou třeba obrovské znalosti k napsání lepšího kódu.

Výše uvedené platí platí pro optimalizaci na rychlost.
No jo, ale v embedded a mikrokontrolérech člověk spíš narazí na ten ARM než na x86/x64.
Název: Re:Rušní asm versus kompilátor
Přispěvatel: Miloslav Ponkrác 08. 09. 2018, 07:58:38
Citace
No jo, ale v embedded a mikrokontrolérech člověk spíš narazí na ten ARM než na x86/x64.

Na tom bude něco pravdy. :-)

Napsat optimalizovaný ARM kompilátor je práce pro vraha. ARM instrukční sada má tak obrovské množství omezení. Nedokáži si dost dobře představit kompilátor, který by zkoušel 1000 x rozličně překopat kód aby našel optimální. Ani si nedokáži dost dobře představit, jak to vůbec matematicky postavit.

Napsat optimalizovaný x86/x64 kompilátor je úloha mnohem snažší. Ty procesory jsou sice architektonicky složitější a je tam více znalostí, ale mnoho problémů tam odpadá.

V ARMu už jen poskládání konstant a jejich hodnot. Poskládání datových struktur a dat co nejblíže místu použití. Pak trefení správné alokace registrů. V ARMu je vůbec těžké navrhnout i nějakou univerzální volací konvenci, aby to plus mínus bylo efektivní ve všech případech.
Název: Re:Rušní asm versus kompilátor
Přispěvatel: armabeton 08. 09. 2018, 10:00:25
Citace
No jo, ale v embedded a mikrokontrolérech člověk spíš narazí na ten ARM než na x86/x64.

Na tom bude něco pravdy. :-)

Napsat optimalizovaný ARM kompilátor je práce pro vraha. ARM instrukční sada má tak obrovské množství omezení. Nedokáži si dost dobře představit kompilátor, který by zkoušel 1000 x rozličně překopat kód aby našel optimální. Ani si nedokáži dost dobře představit, jak to vůbec matematicky postavit.

Napsat optimalizovaný x86/x64 kompilátor je úloha mnohem snažší. Ty procesory jsou sice architektonicky složitější a je tam více znalostí, ale mnoho problémů tam odpadá.

V ARMu už jen poskládání konstant a jejich hodnot. Poskládání datových struktur a dat co nejblíže místu použití. Pak trefení správné alokace registrů. V ARMu je vůbec těžké navrhnout i nějakou univerzální volací konvenci, aby to plus mínus bylo efektivní ve všech případech.

Bavíte se borci o porovnání ARMu a 80x86 nebo ARMu a x64? V tom druhém případě ale jděte do AArch64 a x64 :-)
Název: Re:Rušní asm versus kompilátor
Přispěvatel: Miloslav Ponkrác 08. 09. 2018, 17:55:11
Citace
Bavíte se borci o porovnání ARMu a 80x86 nebo ARMu a x64? V tom druhém případě ale jděte do AArch64 a x64 :-)

Bavíme se o tom, jak moc dobře optimalizuje člověk versus kompilátor na různých architekturách.
Název: Re:Rušní asm versus kompilátor
Přispěvatel: fortranista 08. 09. 2018, 19:00:31
Citace
Bavíte se borci o porovnání ARMu a 80x86 nebo ARMu a x64? V tom druhém případě ale jděte do AArch64 a x64 :-)

Bavíme se o tom, jak moc dobře optimalizuje člověk versus kompilátor na různých architekturách.

nojo potom čím logičtější architektura, tím to má překladač jednodušší a člověk nad ním nemá náskok. Takža na x86-64 a AArch64 už toho moc na ruční úpravy není. Starší architektury - tam je IMHO dost práce pro znalého programátora.