Ein Angebot von

Thema: C++ in Embedded Systemen: Lessons Learned!

erstellt am: 30.08.2019 09:26

Antworten: 2

Diskussion zum Artikel



C++ in Embedded Systemen: Lessons Learned!


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.

zum Artikel


bearbeiten

Antworten

JcHartmut





dabei seit: 19.03.2019

Beiträge: 13

Kommentar zu: C++ in Embedded Systemen: Lessons Learned!
30.08.2019 09:26

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


bearbeiten

Antworten

JcHartmut





dabei seit: 19.03.2019

Beiträge: 13

RE: C++ in Embedded Systemen: Lessons Learned!
30.08.2019 23:47

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


bearbeiten

Antworten

Antwort schreiben

Titel:


Nachricht:

 



Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.

Thema abonnieren:

Email:
*Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung einverstanden.
Antwort abschicken