Azt ugye tudod, hogy egy mikrokontrolleren _NEM_ objektumorientált kód szokott futni?
A nyelv sem C#, de még csak C++ sem igazán, vagy, ha mégis, akkor is gyakorlatilag elfelejtve a magasabb szintű eszközeit.
Ez egy teljesen más világ, más problémákkal.
C vagy Assembly kódot képzelj el, ahol lehetőleg nem hívunk fölöslegesen n mélységű függvényeket (nem pazaroljuk a stack-et), nem másolgatunk fölöslegesen objektumokat (nem pazaroljuk a RAM-ot), sok esetben még a memóriafoglalás nagy része sem dinamikus.
Nem magas szintű a programozási nyelv és nem dob Exception-öket, vagy legalábbis nem úgy kell elképzelni.
Az objektumkezelés, exceptionök egy magasabb szintű eszköztár részei, aminek megvan a maga helye és logikája, segíti a programozó munkáját, de egyszerűen nem erre a területre való.
A tranziens jelenségek, versenyhelyzet olyan jelenség, amiket kezelni kell ezen a szinten, mert nincs, ami ezt elfedje.
Helyesebben van, de azt neked kell megcsinálni.
Ráadásul ezzel azt is kérdezed, hogy pl. az adott fejlesztő az Assembly makróinak viselkedését hogyan teszteli, amik segítségével az adott műveleteket elvégzik a regiszterekkel...
...ez is más világ.
Továbbá nagyon nem mindegy, milyen mikrokontrolleren kell futnia a kódnak, mert nagyon mások lehetnek a lehetőségek is a fentiekre.
Egy erősebb MCU-n akár kicsit szabadabban is lehet kezelni a dolgokat és elő lehet szedni olyan kérdéseket, amikről ti is írtok, de nem kizárt az sem, hogy okkal választ az ember erősebb (és drágább) MCU-t, ki akarja használni azt, hogy erősebb az eszköz, gyorsabb lesz a végrehajtás, és még mindig valamilyen szinten korlátos lesz.
A modernebb mikrokontrollerrel is el lehet végezni ugyanazt a feladatot, de, ha egy tizedannyiba kerülő kontroller szintjére esünk vissza a megnövekedett memóriaigény és erőforrásigény miatt, akkor nem biztos, hogy erre volt szükségünk... emellett a fogyasztást is célszerű kézben tartani, különösen, ha elemről / akkumulátorról üzemel az adott eszköz.
Tényleg mások a felmerülő problémák és szóba jöhető megoldások...