Dies ist eine alte Version des Dokuments!


  • Wenn Sie erst eine Woche vor der Abgabe mit dem Programmieren beginnen, wird es in der Regel eng. Besonders, wenn es Unklarheiten und Nachfragen gibt.
  • Versuchen Sie Spaß am Programmieren zu finden. Es ist wie Puzzeln, nur dass Sie selbst das Bild bestimmen!

In realen Projekten würden Sie zunächst ein Lastenheft erhalten, dass Sie in ein Pflichtenheft, Systembeschreibung, Hardware- und Software-Systembeschreibung herunterbrechen, wobei parallel dazu die Systemtests und Hardware-/Softwaresystemtests beschrieben werden.

Dieses Vorgehen ist für die Arbeiten in EST zu umfänglich und wird wie folgt reduziert. Die Angaben auf der Wikiseite Ihres Projekts, sowie die während der Projektgespräche dienen als Lastenheft. Daraus ist ein Pflichtenheft zu erstellen, welches die Projektziele in obligatorische („Muss“), gewünschte („Soll“) und fakultative („Kann“) Aufgaben untergliedert. Zusätzlich ist es auch möglich Projektziele explizit auszuschließen („Nicht benötigt“).

Um das Pflichtenheft gut zu strukturieren, bietet sich folgende Vorlage an:

Wiki-Format

(Alternativ finden Sie eine Vorlage für das Pflichtenheft in Excel hier: opl_ph.xlsx)

Als weitere Aufgabe sollen Sie eine Offene-Punkte-Liste (OPL) anlegen und führen. Darin sollten wichtige Informationen und Aufgaben (z.B. aus Projektgesprächen) zusammengefasst sein. Ziel ist dabei nicht zwangsläufig, dass am Ende Ihres Projekts alle Punkte abgearbeitet sind. Die OPL kann auch Punkte enthalten, welche zukünftig noch bearbeitet werden müssen oder Ideen, welche noch umgesetzt werden könnten. Sie soll auch dazu dienen, dass andere - wie z.B. Ihre Nachfolger - Ihre Entscheidungen verstehen können.

Die Offene Punkte Liste sollte bevorzugt über das Ticketsystem von Redmine geführt werden.

Für die Software ist ein Modulblockbild/Blockschaltbild beizufügen. Dies soll die Unterfunktionen und ihre gerichteten Schnittstellen zueinander (z.B. globale Variablen, Parameter) darstellen.

Ich würde Sie bitten aus Gründen der Wiederverwendbarkeit dafür die Vorlage in Ihrem Projekt im Wiki nutzen (hier). Dort ist dies unter Softwareübersicht zu finden. Auch wenn Sie keine State Machine verwenden, bietet es sich an in ähnlicher Weise die Zusammenhänge der einzelnen (Unter)funktionen zu beschreiben.

Ich würde Sie bitten aus Gründen der Wiederverwendbarkeit dafür die Homepage draw.io zu nutzen. Eine geeignete Vorlage finden Sie in den ILIAS Kursen (134142) Labor Elektronik bzw. (134274) Elektronische Systeme. Falls Sie die alte Darstellung bereits genutzt haben, können Sie auch diese einbinden.

  • Es empfiehlt sich für alle definierten und deklarierten Namen die Englische Sprache zu verwenden. Für Variablen, Funktionen und Kommentare darf die Deutsche Sprache genutzt werden.
  • Eine detailliertere Liste ist im Embedded System development Coding Reference guide zu finden.
  • Stellen Sie Ihrem Programm einen beschreibenden Kommentar voran.
  • Dieser sollte in der Form sein, wie die Beschreibung in den Übungsprogrammen.
  • Beschreiben Sie darin, ob
    • weitere c- oder h-files eingebunden müssen
    • Jumper gesetzt / geöffnet werden müssen
    • spezielle Hardware genutzt werden muss

Beschreibung

  • Es empfiehlt sich die Code-Kommentierung zeilenweise durchzuführen. Schreiben Sie dabei nicht, was im Code bereits steht, sondern was Sie mit dem Code bezwecken.

Beispiel für Code-Kommentierung

  • Während der Entwicklungsphase kann es sich anbieten Code testweise auszukommentieren. Für die finale Version sollten die Kommentare aber „sauber“ sein.
  • Falls es alternative Werte gibt, welche optional sinnvoll sind, können diese und deren Konsequenzen in ein Kommentar gepackt werden.

Beispiel für auskommentierten Code

  • Nutzen Sie für die Manipulation von Bits die vorgegebenen Makros.
  • Beim Erstellen von eigenen Makros sollte auf Querwirkungen geachtet werden, da ein Makro eine Codeersetzung vor dem Compiler durchführt.

Beispiel für die vordefinierten Makros

  • Konstanten per #define sollten z.B. für die feste Größe von Arrays verwendet werden. Sie können (bzw. werden) auch für hardwarenahe Werte, wie Portnummern, genutzt werden.
  • Für andere Konstanten empfiehlt es sich const Variablen zu nutzen. Dadurch werden auch die Typisierung überwacht.
  • Konstanten per #define werden komplett in Großbuchstaben geschrieben.
  • Falls Sie aus mehreren Wörtern zusammengefügt sind, sollten Sie mit Unterstrich getrennt werden.

Beispiel für Konstanten

  • Wenn sich Werte im Programm zur Laufzeit ändern, so sollten diese als Variable angelegt werden.
  • Nutzen Sie soweit es geht const Variablen für alle Werte im Programm, welche zur Laufzeit nicht mehr geändert werden. Wichtig: Das gilt z.B. für Grenzen von Schleifen ( for(int i=0; i<iMax;i=i+1)) oder für Sonderzeichen. Bei größeren Programmen biete es sich an die const Variablen mit in einem separaten header zu pflegen.
  • Variablen beginnen mit Kleinbuchstaben.
  • Falls Sie aus mehreren Wörtern zusammengefügt sind, so werden die folgenden Wörter ohne Unterstrich direkt angefügt, aber groß geschrieben. Dies wird auch als „BinnenMajuskel“ oder „camelCase“ bezeichnet.
  • Vermeiden Sie zu allgemeine Namen, wie anzahl, uebergabewert oder string. Sinnvoller sind Namen, wie anzahlBuchstaben, stunden, ausgabeString. Durch die Autovervollständigung (Vorschläge unter dem eingegebenen Text) sind auch längere Namen schnell einzugeben, bzw mit Cursortasten und TAB auswählbar.
  • Nutzen sie auch bei Zählvariablen aussagekräftige Namen.
  • Auch kann eine zu allgemeine Deklaration kann zu Problemen führen. Schlecht ist z.B. „int a;“.
  • Es bietet sich an bei der Definition bereits zu initialisieren. Gut ist also „bool a=1;“.

Beispiel für Variablen

  • Teilen Sie Ihr Projekt in sinnvolle Unterstrukturen. Diese sind meist Funktionen. Die Unterstrukturen sollten nicht zu groß werden, um die Übersichtlichkeit zu bewahren.
  • Bei größeren Programmen ist auch die Aufteilung in mehrere Dateien sinnvoll, also z.b. main.c, LED.c, motorDriver.c. Dabei sollte darauf geachtet werden, dass globalen Variablen und Konstanten jeweils nur im Kontext der einzelnen Dateien genutzt werden und, dass header-Dateien angelegt werden. Das ermöglicht ein separates Testen der unterschiedlichen Dateien (z.B. mit einer Datei testLED.c, welche LED.h inlcude't).
  • Nutzen Sie den Zeileneinschub den AtmelStudio automatisch anbietet.
  • Vermeiden Sie zu viele Leerzeilen.
  • Für die Benennung von Funktionen bietet sich - wie bei Variablen - camelCase an. Zum leichteren Verständnis sollten die Funktionsnamen aus Objekt(e) und ggf. Verb zusammengesetzt werden (z.B. bool istGesendet() oder void I2CBotschaftSenden()).
  • Stellen Sie auch jeder Funktion eine kurze Beschreibung voran. Aus dieser sollte hervorgehen, was Sinn und Zweck der Funktion ist.

Beispiel für Anweisungsblöcke

  • Ziel ist ein leicht lesbarer und wartbarer Code. Halten Sie deswegen alle Funktionen schlank - auch void main(). Als Faustformel wären 100 Zeilen für eine Funktion zu groß, 20…50 Zeilen gut.
  • Versuchen Sie sinnvolle Unterfunktionen zu programmieren. Trennen Sie Eingabe, Verarbeitung und Ausgabe.
  • Überlegen Sie sich immer wenn Sie im Code Copy-Paste nutzen, warum dies nicht als Unterfunktion lösbar ist.

Beispiel für ähnliche Zeilen

  • Prüfen Sie, ob aufeinanderfolgende, ähnliche if-Anweisungen sich nicht direkt über Arrays lösen lassen (Beispiel Verzweigungen 1). Wählen Sie bei Verzweigungen statt vielen if-Anweisungen mit ähnlichen Bedingungen Switch-Case-Anweisungen (Beispiel Verzweigungen 2). Falls diese nicht möglich sind, eine For-Schleife und Arrays (Beispiel Verzweigungen 3).

Beispiel für Verzweigungen 1 - Umwandlung in Array

Beispiel für Verzweigungen 2 - Umwandlung in Switch-Case

Beispiel für Verzweigungen 3 - Umwandlung in For-Next

  • Falls Sie if-Ausdrücke nutzen, für welche vorherige Fälle nicht gelten, so überprüfen Sie folgende Punkte. Wenn die if-Ausdrücke ausschließlich gegenseitig ausschließende Bedingungen beinhalten, so nutzen Sie „else if“ (Beispiel Verzweigungen 4). Falls unabhängig von den Bedingungen Anfangs- oder Endanweisungen immer ausgeführt werden, so sollten diese nicht im if-Ausdruck stehen (Beispiel Verzweigungen 5).

Beispiel für Verzweigungen 4 - Verwenden von Else if

Beispiel für Verzweigungen 5 - Reduzieren der Anweisungen

  • Nutzen Sie im main() immer eine Endlosschleife, um an den Anfang zurückzukehren. Bitte verwenden Sie dazu nicht den Aufruf von main() in main()! Der Mikrocontroller legt dabei jedesmal neu Rücksprungadresse und Variablenzustände im Speicher ab und füllt diesen so auf. Korrekt wäre die Verwendung einer Endlosschleife.
  • Verwenden Sie nie den Goto-Befehl. Wird durch diesen eine Schleifenende u.ä. übersprungen, so werden die Speicherbereiche für die nur dort verwendeten Variable nicht freigegeben.
  • Wenn Sie aus verschachtelten Schleifen zurückkehren wollen, sollten Sie break und ein Flag nutzen.

Beispiel für Schleifen 1 - main()

Beispiel für Schleifen 2 - Abbrechen von verschachtelten Schleifen

  • _delay_ms() und _delay_us() sind zu 99% nicht notwendig. Verwenden Sie stattdessen Interrupts, bzw. Timer. Es können z.B. durch Interrupts Takte angelegt werden: takt10ms, takt100ms, takt1s. Diese können dann im main() Verzweigungen in einer Zustandsmaschine auslösen.
  • Wenn Sie Zahlen in Variablen speichern und diese auch mathematisch weiterverwenden, so wandeln Sie diese Variable erst bei der Ausgabe in das ASCII-Format um.

Beispiel für Variablen mit Ausgabe

Bewertung

Zur Bewertung lege ich diese Checkliste (xls-File ) als Maßstab an.