Embedded systémy a microcontrollers

[Skier]

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

[Reklama]

[borekz]

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.

[DeSade]

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.

[Bacsa]

[...] 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?

[TVL]

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

[Reklama]

[Kiwi]

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?

[Jiri Dobry]

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.

[TVL]

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

[v]

A které třeba?

+1

[DeSade]

A které třeba?

NXP, Honeywell (i když tam to poslední roky šlo do neskutečných sraček)

[Skier]

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

[MarSik]

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

[Jiri Dobry]

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.

[MarSik]

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

[Jiri Dobry]

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.