Embedded-Software: So gelingt die Programmierung!

Embedded-Software: So gelingt die Programmierung! ✚ Zeiger ✔ Event-Flags ✔ Rekursiver Code ✔ Mehr erfahren über Embedded-Software-Systeme!

Embedded-Software: So gelingt die Programmierung!

Softwareentwickler kommen aus alle Richtungen zu ihrer Tätigkeit. Viele von ihnen haben sich die erforderlichen Kenntnisse graduell in Eigenregie angeeignet. Doch es gibt auch ausgebildete Spezialisten unterschiedlicher Fachrichtungen. Egal, welche theoretischen Grundlagen vorhanden sind, erst im Einsatz erhalten Softwareentwickler den letzten Schliff. Denn in der Praxis läuft längst nicht alles wie geplant. Der Vorteil dabei ist, dass man auf diese Weise ständig dazu lernt. Wann kann man eine Embedded-Software als fertig und sogar gelungen betrachten? Einige nützliche Tipps für die Praxis haben wir hier zusammengetragen.

Von anderen Programmierern lernen

Ganz gleich, ob ein Entwickler Autodidakt ist oder eine formale Ausbildung hinter sich hat, erst mit der praktischen Anwendung kommt der eigene Lernprozess so richtig in Gang. Die hier gemachten Erfahrungen sind sehr individuell, deshalb ist es äußerst fruchtbar, Kollegen zu konsultieren. Andere Programmierer und Entwickler sehen ein Thema vielfach aus einem anderen Blickwinkel und können wertvolle Anstöße liefern, wenn es um die Vorgehensweise geht – dazu gehören die genutzten Techniken, aber auch Anregungen zur Prüfung und Validierung von Code. Umgekehrt profitiert man langfristig davon, die eigenen Erfahrungen mit anderen zu teilen und sich auf diese Weise ein Netzwerk für den Austausch zu schaffen. Aus derartigen Netzwerk-Anregungen stammen die folgenden Tipps für die Programmierung von Embedded-Software.

Wichtig: Zeiger nach Gebrauch immer auf NULL setzen

Zu den wirklich nützlichen und häufig verwendeten Tools innerhalb einer Programmiersprache gehören die Zeiger. Gibt man nicht acht, können sie allerdings dafür sorgen, dass Fehler auftreten. Besonders häufig, vor allem bei noch wenig erfahrenen Programmieren, ist ein Verweis auf nicht mehr gültige Werte – beispielsweise, wenn der Zeiger sich auf einen dynamisch zugewiesenen Speicher bezieht, der mittlerweile längst aufgegeben worden ist. Unmittelbar bemerkbar macht sich das in den meisten Fällen nicht. Eher ist es so, dass diese Fehlerquelle erst nach einiger Zeit in Betracht gezogen wird und dann im Nachhinein sehr schwer auffindbar ist. Man kann gegensteuern, indem Zeiger unmittelbar nach ihrem Gebrauch automatisch und konsequent auf NULL gesetzt werden. Dann sind fehlerhafte Verwendungen nämlich relativ leicht und umgehend zu finden.

„int“-Daten in der Programmiersprache C

Die Programmiersprache C sieht in ihrer Sprachdefinition eigentlich den sogenannten int-Datentyp als Standard für Rückgaben vor. Viele Entwickler nutzen int allerdings nur für Variablen, außer es passt nicht zu der Art der Daten. Nicht wenige Programmierer haben die Erfahrung gemacht, dass int-Date wirklich verwendet werden sollten, um vorzeichenlose Wertebereiche zu speichern. Ein prüfender Blick auf den Wertebereich und die benötigten Bit kann rasch klären, was angebracht ist. Übrigens, wer sich noch an den Y2K-Bug erinnert: Datumszähler sind meist vorzeichenbehaftet, so auch dieser. Hier lässt sich das Fehlerpotenzial auf Anhieb erkennen.

Code-Recycling: Wiederverwendung nur mit Vorbehalt

Wie lange sollte man als Entwickler an einer Software arbeiten? Eine gern und oft gestellte und sehr differenziert beantwortete Frage. Streng genommen kann man die Arbeit abschließen, wenn eine Software die an sie gestellten Anforderungen reibungslos und ohne sichtbare Bugs erfüllen kann. Damit geben sich viele Programmierer allerdings nicht zufrieden. Denn man kann immer noch ein bisschen draufsetzen, Bereiche verbessern und das Gesamtbild möglichst perfektionieren. Das kann, wenn man übertreibt, im Chaos enden. Alternativ ist es eine verbreitete Fehlerquelle, guten Code umzufunktionieren und ihn anderswo einzusetzen – für Zwecke, für die er ursprünglich nicht geschrieben wurde. Auch hier gilt: Lieber zweimal hinschauen, den vor dem „Recycling“ sind meist einige Anpassungen nötig.

Mit Event-Flags logische Informationen versenden

Moderne Echtzeit-Betriebssysteme, kurz RTOS genannt, haben einen großen Leistungsumfang und sind in hohem Maß skalierbar entsprechend den Wünschen des Anwenders. Dazu können bestimmte Funktionen in den Vordergrund gerückt werden, allerdings sollten Funktionen, die zeitweise nicht genutzt sind, dadurch nicht in ihrem Leistungspotenzial geschmälert werden. Da bei komplexen Designs die Kommunikation zwischen den individuellen Tasks für die Funktionalität und Stabilität des Ganzen so wichtig ist, lassen sich Markierungen, die ein Task auf einen anderen überträgt, am simpelsten mit dem Event-Flag gewährleisten.

Rekursiver Code: die wichtigsten Risiken

Programmierer schätzen sogenannte rekursive Funktionen – hier handelt es sich um solche, die sich mehr oder weniger direkt selbst aufrufen können und mit dem geringsten möglichen Aufwand Probleme aus der Welt schaffen können. Derartiger Code kann so aussehen:

void printbase(int number, int base)

{
    if (number >= base)
    {
        printbase(number/base, base);
    }
    printf("%X", number%base);
}

Sieht gut aus, doch was damit erreicht werden soll, ist in vielen Fällen nicht sofort klar. Und genau deshalb sollte man im Zweifelsfall auf rekursiven Code verzichten. Später kommt es bei der Pflege der Software vor allem auf deren Klarheit und Verständlichkeit an. Dabei sind rekursive Funktionen eher hinderlich. Außerdem greifen sie intensiv auf den Stack zu und können dann schwer zu identifizierende Stack-Überläufe verursachen.

Embedded-Software-Systeme entwickeln mit Präzision und Klarheit

Wie die ausgewählten Tipps zeigen, ist bei der Programmierung von Embedded-Software weniger in vielen Fällen mehr. Sparsame Mittel, die aber am richtigen Platz, sorgen dafür, dass die beabsichtigten Funktionen auf die systemschonendste Weise ausgeführt werden und eliminieren spätere verdeckte Fehlerquellen. Es gäbe weitere Beispiele dieser Art, von denen so gut wie jeder Entwickler berichten kann – was den Austausch untereinander umso wertvoller macht.

Hinterlasse jetzt einen Kommentar

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


*