C++ in Embedded Systemen: Lessons Learned!
-
[url=/c-in-embedded-systemen-lessons-learned-a-653915/][b]C++ in Embedded Systemen: Lessons Learned![/b][/url] Zahlreiche Unternehmen steigen inzwischen für die Embedded-Firmware-Entwicklung von C auf C++ um. Mit C++ lässt sich Firmware entwickeln, die sicherer und expressiver ist. Doch einige Features können sich als zweischneidiges Schwert entpuppen. [url=/c-in-embedded-systemen-lessons-learned-a-653915/]zum Artikel[/url]
-
[url=/c-in-embedded-systemen-lessons-learned-a-653915/][b]C++ in Embedded Systemen: Lessons Learned![/b][/url] Zahlreiche Unternehmen steigen inzwischen für die Embedded-Firmware-Entwicklung von C auf C++ um. Mit C++ lässt sich Firmware entwickeln, die sicherer und expressiver ist. Doch einige Features können sich als zweischneidiges Schwert entpuppen. [url=/c-in-embedded-systemen-lessons-learned-a-653915/]zum Artikel[/url]
-
Die Fehlerbehandlung mit try-catch-throw Denkweise würde ich NICHT beiseite schieben. Mit Makros lässt sich ein abgestimmtes Verhalten zwischen Algorithmustest auf dem PC und embedded Controller erreichen: C++ auf PC mit originalem try-catch-throw, Zielsystem dann ggf. mit Rückfallvariante ohne Test, nur Log in eine Speicherzelle etc. Weil: Die Software ist getestet. Es gibt von mir dazu ein System und ein paar Videos: https://www.vishia.org/emcdocu/videos-de.html und https://www.vishia.org/emcdocu/html/ThCxt-ExcH_emC.html. Könnte interessant und hilfreich sein ...
-
Ein weiterer Hinweis, zu Literaturhinweise [1], dynamische Speicherallokation. C++ hat einen sehr breiten Einsatz, für PC-Desktop-Programme. Dort ist die Speicherallokierung meist kein Problem, genügend Speicher da und die Applikation läuft nur eine begrenzte Zeit. Fragmentierung und knapper Speicher kommt nicht vor. Ich unterstelle, die C++-PC-Programmier-Community macht sich darüber wenig Gedanken (oder fast keine).
Bei langlaufenden Applikationen (kein Neustart, jahrelang) mit nicht zu großem Speicher gibt es das Problem der Fragmentierung, wenn verschiedengroße Blöcke zu verschiedenen Zeiten allokiert und freigegeben werden. Das problem ist theoretisch und bei kurzer Laufzeit oft gar nicht zu merken. Schlussfolgernd: Dynamische Allokierung zur laufzeit war für solche Systeme, mit SIL-level, immer schon VERBOTEN. Aber die PC-getriebenen C++-Standards ignorieren dieses Problem, weil es dort nicht zutrifft. Daher ist Vorsicht geboten.
Hilfreich ist, Allokierung nur wenn nötig (auch für Eventhandling), aber dann in immer gleich großen Speicherblöcken, diese vermeiden Fragmentierung. Diese sind per Default nicht allzu groß. Das reicht aber für Events und ggf. throw. throw nur mit Vorsicht verwenden, nicht alle Möglichkeiten ausschöpfen. Einfache Fehlerobjekte reichen in der Praxis.
JcHartmut