Best Practice Fünf Tipps zur Programmierung von Embedded-Software

Autor / Redakteur: Colin Walls * / Sebastian Gerstl

Die meisten Softwareentwickler verfügen über eine Art von Ausbildung oder Training, andere sind eher Autodidakten. Aber das wirkliche Lernen in der Programmierung erfolgt durch praktische Erfahrung - und den Austausch von Wissen. Hier sind einige bewährte Tipps, die Autor Colin Walls in langjähriger Erfahrung gesammelt hat.

Anbieter zum Thema

Wann ist eine Software wirklich fertig? Welche Tücken birgt rekursiver Code? Colin Walls gibt fünf Tipps zur Programmierung von Embedded Software, die Punkte adressieren, mit denen viele Entwickler in ihrer Laufbahn bereits Bekanntschaft gemacht haben.
Wann ist eine Software wirklich fertig? Welche Tücken birgt rekursiver Code? Colin Walls gibt fünf Tipps zur Programmierung von Embedded Software, die Punkte adressieren, mit denen viele Entwickler in ihrer Laufbahn bereits Bekanntschaft gemacht haben.
(Bild: gemeinfrei / CC0 )

Egal ob ausgebildet oder selbstgelernt: die meisten Softwareentwickler werden zustimmen wenn ich sage, dass das wirkliche Lernen zum Großteil in der Praxis erfolgt. Bei der Programmierung können sie auf nützliche Techniken stoßen oder sich während einer Code-Überprüfung von Kollegen beraten lassen. Selbst sehr erfahrene Programmierer erhalten von Zeit zu Zeit wertvolle Tipps. Deshalb ist es überaus wertvoll, seine eigenen Erfahren auch weiterzugeben.

In diesem Beitrag gebe ich Embedded-Software-Entwicklern fünf (hoffentlich!) nützliche Ratschläge:

Einen Zeiger nach Gebrauch auf NULL setzen

Zeiger sind sehr nützliche und mächtige Funktionen einer Sprache. Sie können aber zu Fehlern führen. Ein häufiger Fehler ist, dass Code einen Zeiger mit nicht mehr gültigem Wert verwendet. Zum Beispiel, wenn er auf einen Speicher verweist, der zwar dynamisch allokiert, aber inzwischen aufgegeben wurde. Der Einsatz eines ungültigen Zeigers kann negative Auswirkungen haben, die sich erst nach längerer Zeit bemerkbar machen und daher sehr schwer zu finden sind. Wenn Sie einen Zeiger nach Gebrauch routinemäßig auf NULL setzen, führt eine spätere irrtümliche Verwendung zu einem sofortigen Fehler, der leicht lokalisierbar ist.

Der bequeme Programmierer verwendet in C „int“ für vorzeichenlose Daten

In C ist der int-Datentyp fast schon Standard. Tatsächlich war er in der ursprünglichen Sprachdefinition der Standard-Rückgabe-Datentyp für eine Funktion (die eigentlich hätte ungültig sein müssen, aber das kam später). Die meisten C-Programmierer neigen dazu, int für eine Variable zu wählen, es sei denn, der Datentyp ist dafür eindeutig ungeeignet. Ich würde vorschlagen, dass sie sich wirklich für vorzeichenlos entscheiden sollten, da mehr Daten vorzeichenlos als vorzeichenbehaftet sind. Es ist am besten, den Wertebereich, den Sie speichern müssen, genau zu betrachten. Ist er vorzeichenlos oder vorzeichenbehaftet? Benötigen Sie 8, 16, 32 oder mehr Bit? Überraschenderweise sind Zeit-/Datumszähler häufig vorzeichenbehaftet, was zum Y2K-Fehler geführt hat.

Vorsicht vor schleichender Eleganz

Wann ist eine Software fertig? Die offensichtliche Antwort ist, wenn sie alle spezifizierten Funktionen ohne bekannte Fehler bereitstellt. Es gibt eine Reihe von Umständen, die die Fertigstellung gefährden: Viele Ingenieure sind Perfektionisten und sehen immer Dinge, die sie in ihrem Code „verbessern“ können. Ohne größtmögliche Sorgfalt und Überwachung kann in ihren Händen ein Projekt böse aus dem Ruder laufen. Eine andere, weniger offensichtliche Situation ist, wenn ein Code für einen bestimmten Zweck oder ein spezielles Projekt geschrieben wurde und dann an anderer Stelle wiederverwendet wird. Es ist sehr einfach, „auf Erfahrung aufzubauen“ und den Code vor der Wiederverwendung zu verbessern. Ohne die nötige Sorgfalt wird dies zum Alptraum der Versionsverwaltung. Ich habe dieses Problem schon vor vielen Jahren mit einem hausinternen RTOS erlebt.

Ein Event-Flag oder -Signal ist bei einem RTOS die effizienteste Möglichkeit zum Senden einfacher logischer Informationen

Ein modernes RTOS, wie unser eigenes Nucleus RTOS, beinhaltet eine Vielzahl von Funktionen. Da ein solches Betriebssystem skalierbar ist, kann der Entwickler die zu verwendende Funktion auswählen, ohne dass die ungenutzten Funktionen wegen ihrer Codegröße einbußen erhalten. In jedem Multi-Thread-Design ist Inter-Task-Kommunikation wichtig. Deshalb sollten verschiedene Funktionen zur Verfügung stehen und diese sorgfältig ausgewählt werden können. Wenn eine Task einfach nur ein Ereignis für eine andere Task markieren muss, ist die einfachste Kommunikationsmethode – Event-Flag oder -Signal – wahrscheinlich die effizienteste Option.

Rekursiver Code kann sehr elegant aussehen, ist aber gefährlich

Eine Reihe von mathematischen Verfahren lässt sich durch rekursive Funktionen beschreiben, das heißt, durch Funktionen, die sich direkt oder indirekt selbst aufrufen. Dies kann ein scheinbar eleganter Weg zur Lösung eines Problems sein, das minimalen Code verwendet. Hier ein einfaches Beispiel:

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

Ist klar, was dieser Code bewirkt? Die Antwort ist wahrscheinlich „nicht sofort“. Das ist auch einer der Gründe, warum man diese Technik vermeiden sollte. Klarheit über die Bedeutung eines Codes ist wesentlich für die weitere Softwarepflege. Zudem nutzen rekursive Funktionen den Stack sehr intensiv und dies kann ohne Sorgfalt außer Kontrolle geraten. Stack-Überläufe sind recht subtile Fehler, die es zu lokalisieren gilt.

Der Autor

Colin Walls, Embedded-Software-Technologist bei Mentor, a Siemens business.
Colin Walls, Embedded-Software-Technologist bei Mentor, a Siemens business.
(Bild: Caroline Mann)

* Colin Walls verfügt über fast 40 Jahre Erfahrung in der Elektronikindustrie, hauptsächlich im Bereich Embedded Software. Er ist Embedded-Software-Technologist bei Mentor, a Siemens business, mit Sitz in Großbritannien. Walls hält regelmäßig Vorträge auf Konferenzen und Seminaren. Zudem ist er Autor zahlreicher Fachartikel sowie zweier Bücher über Embedded Software.

(ID:45206278)