{"id":3074,"date":"2026-01-30T00:00:00","date_gmt":"2026-01-29T23:00:00","guid":{"rendered":"https:\/\/kunden.weissblaumedia.de\/microconsult\/2017\/03\/23\/rs-c-embeddedc\/"},"modified":"2026-06-17T13:17:47","modified_gmt":"2026-06-17T11:17:47","slug":"rs-c-embeddedc","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/rs-c-embeddedc\/","title":{"rendered":"From C to Embedded-C: The goal determines the path"},"content":{"rendered":"

Nat\u00fcrlich ist Embedded-C auch C. Der Umstieg von C auf Embedded-C bedeutet aber, dass der Programmierer sich beim Einsatz an den Erfordernissen der jeweiligen Embedded-Anwendung orientieren muss. Dies sind beispielsweise Echtzeitf\u00e4higkeit, geringer Speicherbedarf oder hohe Betriebssicherheit. Gleichzeitig stellt die Wiederverwendbarkeit von Software auch in der Embedded-Welt ein wichtiges Qualit\u00e4tsmerkmal dar. Die richtige Anwendung der C-Schl\u00fcsselw\u00f6rter spielt dabei eine bedeutende Rolle.<\/strong><\/p>\n

<\/p>\n

Wer ein Haus bauen m\u00f6chte, hat eine Vorstellung auf welchem Grund es gebaut wird, welche Fl\u00e4che oder Raumeinteilung es haben sollte und vieles mehr. Aus den Vorgaben entsteht mit Hilfe des Architekten der Bauplan. Und danach wird \u2013 in einer vorher festgelegten Reihenfolge der Gewerke \u2013 das Haus gebaut.<\/p>\n

Wer ein Embedded-System bestehend aus Hardware und Software entwickelt, braucht auch einen Plan. F\u00fcr die Hardware besteht an dieser Notwendigkeit kein Zweifel, aber wie sieht es mit der nicht sichtbaren oder greifbaren Software aus?<\/p>\n

Ja, auch das muss geplant werden. Ein Vorgehensmodell (Prozessmodell) legt fest, wer wann wof\u00fcr<\/strong> zust\u00e4ndig ist.<\/p>\n

\"\"<\/p>\n

Bild 1: Das V-Modell wird im Umfeld von Embedded-Entwicklungen h\u00e4ufig als Vorgehensmodell eingesetzt. Der linke Schenkel zeigt von oben nach unten die Arbeitsschritte der Entwicklungsphase, der rechte Schenkel die verschiedenen Tests.<\/em><\/p>\n

Der Weg, den die Softwareentwickler von der Anforderungsanalyse \u00fcber Design und Implementierung bis hin zum Test gehen, wird durch die Aufgabenstellung vorgegeben. Und was hat das alles mit der Programmiersprache C oder Embedded-C zu tun?<\/p>\n

Nun, die Anforderungen m\u00fcssen vom Programmierer richtig umgesetzt werden, und dabei helfen unter anderem eine Reihe von C-Schl\u00fcsselw\u00f6rtern.<\/p>\n

Beginnen wir mit dem ersten Schritt, dem Festlegen der Anforderungen an die Software.<\/p>\n

Anforderungen an die Software<\/h4>\n

In der Software-Analysephase m\u00fcssen die unterschiedlichen Anforderungen an die Software – die funktionalen und die nicht-funktionalen Qualit\u00e4tsmerkmale – festgelegt werden.<\/p>\n

\"\"<\/p>\n

Bild 2: Tabelle der Software-Qualit\u00e4tsmerkmale nach ISO 9126<\/em><\/p>\n

Funktionale Anforderungen sind vergleichsweise einfach zu definieren: Was<\/strong> soll\/muss die Software leisten? Die Herausforderung sind bei Embedded-Systemen h\u00e4ufig die nicht-funktionalen Anforderungen. Sie beziehen sich oft auf die Randbedingungen (Vorschriften, Normen, Zeitvorgaben, etc.) eines Embedded-Systems.<\/p>\n

Ein Beispiel daf\u00fcr ist das Software-Qualit\u00e4tsmerkmal Effizienz. \u00dcber wie viel Programm- und Datenspeicher verf\u00fcgt das System? Muss bei der Programmierung \u201egespart\u201c werden, weil sehr wenig Speicher zur Verf\u00fcgung steht? Kann es Laufzeitprobleme geben, weil die Echtzeitanforderungen nur unter bestimmten Bedingungen einhaltbar sind? Stellen die Spannungsversorgung bzw. Stromaufnahme oder die W\u00e4rmeerzeugung ein Problem dar, das durch die Art der Programmierung beeinflusst werden kann oder muss?<\/p>\n

Wenn eine oder mehrere dieser Fragen mit JA beantwortet werden, dann muss<\/strong> das in den Anforderungen stehen. Der Programmierer setzt dann die Anforderungen mit geeigneten Ma\u00dfnahmen um, und der Tester muss sie testen.<\/p>\n

Diese Anpassungen an die spezifischen Erfordernisse der Systemoptimierung hat nicht nur Einfluss auf die Art der Programmierung sondern auch auf die Wiederverwendbarkeit der Software. Funktionsaufruf und -r\u00fcckkehr kosten zum Beispiel zus\u00e4tzlich Laufzeit, also gilt es, diese zu vermeiden. Darunter leidet die Modularisierung, die ihrerseits jedoch f\u00fcr gut wiederverwendbare Software wichtig ist.<\/p>\n

Auch die Zuordnung von Programmcode in den physikalisch vorhandenen Programmspeicher kann eine wichtige Rolle spielen. Verf\u00fcgt der Mikrocontroller \u00fcber Cache, muss schon im C-Quellcode daf\u00fcr gesorgt werden, dass im Linker\/Locator die Zuordnung der Funktionen zum cacheable und nicht-cacheable Speicher erfolgen kann. Gibt es unterschiedliche Zugriffszeiten auf verschiedene Arten von Programm- oder Datenspeicher, muss ebenfalls schon im C-Quellcode vorgesehen werden, dass im Linker\/Locator die Zuordnung richtig durchgef\u00fchrt werden kann.<\/p>\n

Hat eine CPU nichts zu tun, au\u00dfer zum Beispiel auf ein Ereignis zu warten, kann sie entweder in einer Warteschleife weiterarbeiten oder abgeschaltet werden. Nichtstun in einer Warteschleife kostet Strom, und Abschalten reduziert die Stromaufnahme erheblich, doch das Zuschalten kostet nat\u00fcrlich Zeit. Was ist wichtiger \u2013 Strom sparen oder die sehr schnelle Reaktion auf ein Ereignis? Die Antwort auf diese Frage hat bedeutende Auswirkungen darauf, wie die Software implementiert wird.<\/p>\n

Eine ebenfalls sehr wichtige Anforderung an viele Embedded-Systeme stellt die Betriebssicherheit (Safety) dar. Schauen wir uns als erstes an, was der Programmierer dazu beitragen kann.<\/p>\n

Betriebssicherheit \u2013 Safety<\/h4>\n

Die Ma\u00dfnahmen, um eine komplexe Steuerung f\u00fcr sicherheitskritische Aufgaben ausreichend betriebssicher zu machen, sind sehr umfangreich und betreffen das Konzept (Anforderungsanalyse, Design) sowie den gesamten Entwicklungs- und Testprozess.<\/p>\n

Die Programmiersprache C l\u00e4sst unterschiedliche Syntaxformen zu. Schl\u00fcsselw\u00f6rter k\u00f6nnen zum Teil ganz weggelassen werden, Datentypen sind nicht typsicher, Variable und Zeiger m\u00fcssen vor ihrer Nutzung nicht initialisiert werden. All das kann zu Missverst\u00e4ndnissen, Fehlinterpretation oder sogar schwerwiegenden Fehlern f\u00fchren (beispielsweise nicht initialisierte Zeiger). Eines von vielen Beispielen daf\u00fcr ist die Nutzung eines booleschen Ausdrucks in verschiedenen C-Kontrollstrukturen (if, while, \u2026).<\/p>\n

int32_t i = 5;\r\n\r\nstatic int32_t a;\u00a0\u00a0 \/\/ Variable a ist nicht initialisiert\r\n\r\n\r\n\r\n\r\nif (a = i)\r\n\r\n{\r\n\r\na = STARTVALUE;\r\n\r\n}<\/pre>\n
Bild 3: Die if-Anweisung pr\u00fcft einen booleschen Ausdruck auf TRUE oder FALSE, hier wird aber eine Zuweisung (Variable <\/em>a<\/em> wird mit dem Inhalt von Variable <\/em>i<\/em> beschrieben) ausgef\u00fchrt und anschlie\u00dfend das Ergebnis der Zuweisung (ein ganzzahliger 32-Bit Wert) auf TRUE\/FALSE gepr\u00fcft; au\u00dferdem fehlt hier der <\/em>else<\/em>-Zweig.<\/em><\/p>\n
Solche unsicheren Syntaxformen sind unbedingt zu vermeiden, da sie leicht zu Folgefehlern f\u00fchren k\u00f6nnen. Hier empfiehlt sich der Einsatz von Programmierregeln. Fertige Programmier-Regelwerke f\u00fcr C-Programmierer gibt es zum Beispiel in Form der MISRA[1]<\/sup> C-Regeln.<\/p>\n
Bekannterma\u00dfen sind Regeln jedoch nur gut, wenn sie auch eingehalten werden. Deshalb ist die Einhaltung der Programmierregeln zu \u00fcberwachen, z.B. durch unterschiedliche Arten von Tests. Eine M\u00f6glichkeit sind Reviews, eine andere, sehr effiziente (und unbestechliche), sind statische Testtools, wie sie von verschiedenen Toolherstellern angeboten werden. Teilweise sind sie schon in den C-Compiler integriert.<\/p>\n
Die Anwendung von Regelwerken, Standards und Normen hilft auf der einen Seite, qualitativ bessere Softwaresysteme zu bauen, f\u00fchrt aber andererseits zu einem Mehraufwand in allen Entwicklungsphasen und Beeintr\u00e4chtigungen der Effizienz. Das f\u00fchrt uns zur Frage, wie bedeutend das Software-Qualit\u00e4tsmerkmal Effizienz tats\u00e4chlich ist.<\/p>\n
Effizienz<\/h4>\n
Die Embedded-C-Compiler oder der dazugeh\u00f6rige C-Pr\u00e4prozessor verf\u00fcgen \u00fcber besondere Schl\u00fcsselw\u00f6rter (zum Beispiel __attributes__ bzw. #pragma), um die gezielte Zuordnung zu bestimmten Adressbereichen durch den Linker\/Locator zu unterst\u00fctzen.<\/p>\n
Mit dem Compiler-Schl\u00fcsselwort inline k\u00f6nnen C-Funktionen wie Makros direkt an der Aufrufstelle eingef\u00fcgt werden. Bei sehr kleinen Funktionen mit wenigen Assemblerbefehlen kann das viel Laufzeit sparen, kostet bei h\u00e4ufigen Aufrufen aber auch mehr Speicherplatz.<\/p>\n
Ein weiteres Problem stellt bei vielen Mikrocontrollern die Nutzung von Floating-Point-Arithmetik dar, weil die einfache ALU (arithmetisch-logische Einheit der CPU) keine geeignete Logik f\u00fcr die schnelle Abarbeitung von Floating-Point-Operationen bietet. Die Verwendung von C-Bibliotheksfunktionen kostet sehr viel Laufzeit. Hat ein Mikrocontroller eine Floating-Point-Unit FPU in Hardware implementiert, beherrscht diese oft nur einfache Genauigkeit. In diesem Fall sollten alle Operationen nur in einfacher Genauigkeit ausgef\u00fchrt werden, damit die Hardware-FPU auch genutzt wird. Diese Einschr\u00e4nkungen m\u00fcssen f\u00fcr Floating-Point-Variable, Floating-Point-Konstanten und Floating-Point-Berechnungen angegeben werden.<\/p>\n
Neben dem Steuerparameter des Compilers f\u00fcr das Abschalten der Berechnungen mit doppelter Genauigkeit gibt es in der Programmiersprache C auch noch die M\u00f6glichkeit, Floating-Point-Konstanten (standardm\u00e4\u00dfig doppelte Genauigkeit) mit dem Buchstaben f f\u00fcr float (einfache Genauigkeit) zu kennzeichnen.<\/p>\n
\/\/ Single-Precision Floating Point\r\n\r\nstatic float f = 2.3f;\r\n\r\n\r\n\r\n\r\nf = f + 1.2f;<\/pre>\n
Bild 4: Beispielcode f\u00fcr die Kennzeichnung von Floating-Point-Konstanten in C<\/em><\/p>\n
Aber nicht nur der Programmierer kann etwas zur Effizienz beitragen. Moderne C-Compiler optimieren den zu erzeugenden Maschinencode. Typisch gibt es mehrere Optimierungsstufen (-O0\/-O1\/-O2\/-O3), die vom Zusammenfassen von Konstanten-Ausdr\u00fccken bis hin zum Umstellen der Assembler-Befehlsreihenfolge unterschiedliche Stufen von Code-Optimierung durchf\u00fchren. Viele Embedded-C-Compiler bieten dar\u00fcber hinaus Speed- und Size-Optimierung an. Wie gut C-Compiler wirklich optimieren, h\u00e4ngt allerdings ma\u00dfgeblich vom Compiler-Hersteller ab.<\/p>\n
C-Compiler versuchen unter anderem auch, Zugriffe auf Speicherzellen oder Steuer-\/Status-\/ Arbeitsregister von Peripheriemodulen zu optimieren.<\/p>\n
Ein Beispiel: <\/strong><\/p>\n
Der Mikrocontroller enth\u00e4lt eine serielle Schnittstelle. In einer Software-Warteschleife soll gewartet werden, bis \u00fcber diese serielle Schnittstelle ein Zeichen vollst\u00e4ndig empfangen wurde. Der C-Compiler \u00fcbersetzt diese Warteschleife in der Regel als folgende Befehlsfolge:<\/p>\n
    \n
  1. Lies einmal das Statusregister der seriellen Schnittstelle in ein CPU-Arbeitsregister ein.<\/li>\n
  2. Frage im Arbeitsregister der CPU, ob sich das entsprechende Statusbit ver\u00e4ndert.<\/li>\n<\/ol>\n
    Das Statusbit \u00e4ndert sich allerdings nur im Statusregister, nicht aber im CPU-Arbeitsregister. Die Schleife wird aufgrund der Compiler-Optimierung zu einer unendlichen Warteschleife.<\/p>\n
    Abhilfe schafft hier das C-Schl\u00fcsselwort volatile. Es sorgt daf\u00fcr, dass immer die Original-Speicherzelle gelesen\/beschrieben wird. Sobald sich das Statusbit \u00e4ndert, wird der ver\u00e4nderte Wert im Arbeitsregister der CPU zu sehen sein. Die Schleife wird verlassen.<\/p>\n
    static volatile int32_t status = STARTVALUE;\r\n\r\n\r\n\r\n\r\nvoid waitForEvent(void)\r\n\r\n{\r\n\r\nwhile (status == STARTVALUE)\u00a0\u00a0\u00a0 \/\/ wait for status change\r\n\r\n;\r\n\r\n}<\/pre>\n
    Bild 5: Die Variable status wird asynchron, zum Beispiel in einer Interrupt-Service-Routine, ver\u00e4ndert und muss deshalb volatile sein. So ist sichergestellt, dass bei jedem Durchlauf der Warteschleife die Originalspeicherzelle gelesen wird.<\/em><\/p>\n
    Mithilfe eines weiteren C-Schl\u00fcsselwortes, n\u00e4mlich inline (das im \u00dcbrigen von C++ \u00fcbernommen wurde), kann der C-Programmierer einen Beitrag zur Code- und\/oder Laufzeit-Optimierung leisten. Bei C-Funktionen mit kompaktem Code kann inline zu wesentlichen Laufzeitverk\u00fcrzungen f\u00fchren. Der Compiler f\u00fcgt dann an der Aufrufstelle der Funktion direkt den kompletten Funktionscode ein. Das geht nat\u00fcrlich nur, wenn der Compiler den C-Quellcode kennt. Deshalb m\u00fcssen inline-Funktionen im Headerfile implementiert und als inline gekennzeichnet werden. Allerdings h\u00e4ngt die Umsetzung des Schl\u00fcsselwortes inline von der Compiler-Optimierung ab. Infolgedessen hat es der Programmierer wieder nicht selbst in der Hand, wie optimiert wird.<\/p>\n
    Viele Compiler-Hersteller haben das Problem erkannt und mittlerweile Abhilfe geschaffen. Sie bieten zus\u00e4tzliche Optimierungseinstellungen (zum Beispiel in Form von Pragma-Direktiven) an, mit deren Hilfe der Compiler gezwungen wird, inline-Funktionen unabh\u00e4ngig von der eingestellten Optimierung immer als solche zu \u00fcbersetzen.<\/p>\n
    inline-Funktionen k\u00f6nnen auch als C-Makros programmiert werden. Der Vorteil besteht darin, dass sich der Aufruf der Funktionen nicht vom Aufruf \u201erichtiger\u201c Funktionen unterscheidet. Deshalb kann jederzeit ohne gro\u00dfen Aufwand zwischen inline und nicht-inline umgestellt werden.<\/p>\n
    Aber Vorsicht! Das Debuggen \u00e4ndert sich durch inline-Funktionen. Es gibt keinen Breakpoint in der Funktion, da der Funktionsk\u00f6rper ja nicht mehr nur an einer Stelle, sondern an vielen Stellen existiert. Der Breakpoint muss demnach an der Aufrufstelle gesetzt werden.<\/p>\n
    #ifndef<\/strong> TESTEMBC_H_\r\n\r\n#define<\/strong> TESTEMBC_H_\r\n\r\n\r\n\r\n\r\n#include<\/strong> <stdint.h>\r\n\r\n\r\n\r\n\r\ntypedef<\/strong> struct<\/strong>\r\n\r\n{\r\n\r\nuint32_t state;\r\n\r\n} STATE_t;\r\n\r\n\r\n\r\n\r\ninline<\/strong> void<\/strong> setState<\/strong>(STATE_t* const<\/strong> pSTATE_t, uint32_t value)\r\n\r\n{\r\n\r\nif<\/strong> (value > 0 && value <= 100)\r\n\r\n{\r\n\r\npSTATE_t->state = value;\r\n\r\n}\r\n\r\n}\r\n\r\n\r\n\r\n\r\ninline<\/strong> int32_t getState<\/strong>(const<\/strong> STATE_t* const<\/strong> pSTATE_t)\r\n\r\n{\r\n\r\nreturn<\/strong> pSTATE_t->state;\r\n\r\n}\r\n\r\n\r\n\r\n\r\n#endif<\/strong> \/* TESTEMBC_H_ *\/<\/pre>\n
    Bild 6: Einfache Schreiboperationen wie <\/em>setState()<\/em> oder Leseoperationen wie <\/em>getState()<\/em> bieten sich<\/em> als<\/em> inline<\/em>–<\/em>Funktionen an.<\/em><\/p>\n
    #include<\/strong> \"TestEmbC.h\"\r\n\r\n\r\n\r\n\r\nint<\/strong> main<\/strong>(void)\r\n\r\n{\r\n\r\nuint32_t temp;\r\n\r\nstatic<\/strong> STATE_t locObj;\r\n\r\nsetState(&locObj, 20);\r\n\r\ntemp = getState(&locObj);\r\n\r\n\r\n\r\n\r\nreturn<\/strong> temp;\r\n\r\n}<\/pre>\n
    Bild 7: inline-Funktionen werden wie \u201enormale\u201c Funktionen aufgerufen; nur am \u00fcbersetzten Code ist erkennbar, ob es sich um inline-Funktionen handelt.<\/em><\/p>\n
    Sichtbarkeit und G\u00fcltigkeit von Variablen<\/h4>\n
    C-Programmierer neigen dazu, viele \u2013 oder alle \u2013 Variable als globale Variable anzulegen. So sind sie f\u00fcr alle Funktionen von au\u00dfen sichtbar. Verf\u00fcgt ein Softwaresystem \u00fcber viele solcher globalen Variablen, stellt jede \u00c4nderung oder Erweiterung ein Risiko dar. Es ist bei komplexer Software schwer zu durchschauen, wer wann und warum auf welche Variable lesend oder schreibend zugreift. Der einzelne Entwickler verliert dabei den \u00dcberblick, da er selten alle Systemzusammenh\u00e4nge kennt.<\/p>\n
    Deshalb muss der Programmierer sorgf\u00e4ltig bedenken, was global sein muss bzw. lokal bleiben sollte. Die Programmiersprache C stellt daf\u00fcr das Schl\u00fcsselwort static zur Verf\u00fcgung. Damit k\u00f6nnen Variable von \u201ef\u00fcr jeden sichtbar\u201c auf \u201enur im Modul sichtbar\u201c eingeschr\u00e4nkt werden, oder lokale Variable innerhalb von Funktionen k\u00f6nnen von dynamisch auf statisch umgestellt werden.<\/p>\n
    Dynamisch bedeutet, dass die Variable im Stack (oder einem Arbeitsregister der CPU) abgelegt wird und bei Beenden des Blocks wieder freigegeben wird. Statisch bedeutet, dass die Variable eine feste RAM-Adresse bekommt und die Speicherzelle \u00fcber das Blockende hinaus belegt bleibt.<\/p>\n
    Lokale statische Variable haben Vor- und Nachteile. Der Vorteil ist, dass der Inhalt erhalten bleibt und beim n\u00e4chsten Eintritt in den Block wiederverwendet werden kann. Der Nachteil ist, dass RAM-Speicher belegt wird (und bleibt), auch wenn auf den Inhalt nicht zugegriffen werden kann.<\/p>\n
    int32_t globalVar = STARTVALUE;\u00a0 \/\/ Application-global visibility,\r\n \/\/ global validity\r\n\r\nstatic int32_t localVar = 0;\u00a0\u00a0\u00a0\u00a0 \/\/ Module-local visibility,\r\n\r\n\/\/ global validity\r\n\r\n\r\n\r\n\r\nint main(void)\r\n\r\n{\r\n\r\nint32_t i;\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ Function-local visibility, local validity\r\n\r\nstatic int32_t a;\u00a0\u00a0 \/\/ Function-local visibility, global validity\r\n\r\n\r\n\r\n\r\nreturn 0;\r\n\r\n}<\/pre>\n
    Bild 8: Globale und lokale Variable k\u00f6nnen mit <\/em>static<\/em> deklariert werden, um die Sichtbarkeit und G\u00fcltigkeit zu ver\u00e4ndern.<\/em><\/p>\n
    Auch Variable, die von mehreren Funktionen genutzt werden, k\u00f6nnen lokal bleiben, wenn die Funktionen, die auf sie zugreifen, in dasselbe Modul gepackt werden. Falls das nicht m\u00f6glich ist, muss \u00fcber globale Variable (oder \u00fcber Zeiger) nachgedacht werden.<\/p>\n
    Eine Programmierregel sollte festlegen, dass globale Variable gut dokumentiert werden m\u00fcssen:<\/p>\n