Máme procesory, na kterých běží linux za jednotky dolarů...
Osobně si myslím, že čím dál víc věcí v embedded půjde směrem, že tam bude někaký relativně hi-level os (Zephyr nebo linux) a vlastní aplikace se bude lepit nad tím v něčem, na co zrovna půjdou sehnat lidi...
Těch aplikací, které vyžadují bezpečnost/čas zase tolik nakonec není.
To bude dost náročné testovat, protože tím si dovnitř zanesete obrovské množství kódu, o němž ani přesně nevíte, co dělá, z 90 % je to pro danou aplikaci nepotřebné a představuje to jen potenciální zdroj chyb a cest pro různé exploity. Je to zbytečný nárůst komplexity. Aplikací vyžadujících bezpečnost je spousta, pokud se člověk pohybuje třeba v tom průmyslu. A není-li to přímo bezpečnost, tak riziko finanční škody. Dost velkou motivací pro dodavatele SW do průmyslu by bylo, kdyby ve smlouvách standardně bylo ujednání, že když vinou chyby v SW dojde ke vzniku škod, tak to dodavatel komplet nahradí.
Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices. Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo 
Univerzitu na to abys pohledal.
Zatím jsme se tu nijak odborně nebavili, jen tak obecně. Museli bychom se bavit o konkrétní věci. Žádnou vaši práci jsem neviděl, nejspíš jsem s vámi neměl tu čest v praxi se setkat. V čem píšete je celkem nicneříkající informace. Univerzitu na co? Pokud potřebujete univerzitu, aby vás tam naučili pracovat s vámi zmiňovanými jazyky, pak je něco špatně - to je přesně to, o čem jsem mluvil. Stačí znát obecné principy a postupy, které se více-méně od 60. let minulého století nemění. Snad všechno už tu od té doby v nějaké podobě bylo. S touto obecnou, vámi neuznávanou průpravou, zvládnete práci s nějakým konkrétním jazykem vcelku snadno. Pokud bychom oprášili ten zubařský příměr, tak je to jako práce s konkrétním materiálem nebo konkrétním nástrojem. Jenže ta podstata znalostí spočívá ve schopnosti posoudit vhodnost určitého materiálu, nástroje či postupu, umět správně diagnostikovat problém a v každém konkrétním případě umět stanovit vhodný další postup. Ne, protože jiný neznám, protože je s tím nejméně práce, nebo protože je to momentálně hype, ale protože je v daném případě optimální.
Opět z praxe - jestliže vás firma odbývá s tím, že na daném HW není možné určitou věc implementovat kvůli nedostatku paměti, a vy při nahlédnutí do programu zjistíte, že používají vnořená volání, místo aby to vyřešili pomocí stavového automatu, takže by stačila jedna stavová proměnná, jedno volání a hromada paměti by ještě zbyla, tak je asi něco špatně. Totéž jiný ekšpert - "nelze, pro daný úkol nedostatečný HW". Problém byl v tom, že místo aby kalibrační křivku implementoval pomocí interpolační tabulky a FXP aritmetiky, snažil se to realizovat přesně podle údajů z katalogu, tj. potřeboval FP knihovnu, aby mohl do programu prostě tupě opsat kalibrační vzorec. Nebo jiný "neřešitelný problém", tentokrát v assembleru - měřidlo dodává údaj ve formátu double, systém to potřebuje jako single... (btw - pomohlo by nějak dotyčným s řešením těchto problémů, kdyby používali Rust?)
A ne, řešením opravdu není použít silnější HW. Jednak to často nejde, průmyslový HW se nedá měnit jak ponožky, to jsou systémy, které mají spolehlivě a kontinuálně pracovat i desítky let a stojí to desítky, stovky milionů, a jednak neschopný vývojář vždycky dříve či později narazí na problém, na který mu daný HW nestačí, ale stačil by mu, kdyby nebyl neschopný.
Zobrazit příspěvky
