Embedded systémy a microcontrollers

[Embedák]

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.

[Reklama]

[Skier]

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.

[Jiri Dobry]

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. :-)

[Kiwi]

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

[JD]

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)?

[Reklama]

[Kiwi]

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.

[hu]

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.

[JD]

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.

[Jiri Dobry]

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.

[0x1000]

Btw jaký používáte logický analyzátor? My jsme si velmi oblíbili Saleae Logic Pro 16.

[Jiri Dobry]

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.

[askdlksdf]

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?

[MarSik]

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

[Miloslav Ponkrác]

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.

[Kiwi]

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.