SimpleProg

Natürlich kann es nicht Sinn der Webseite sein, das komplette Programm zu erläutern. Schwerpunkt wird also die kurze(!) Beschreibung der Klassen sein (damit man diese für eigene Projekte in ähnlicher und abgewandelter Form wiederverwenden kann) und eine Auflistung möglicher Änderungen am Programm.

Stateprog und SimpleProg arbeiten ähnlich und teilen soch einen großen Teil des Sourcecodes. Hierbei handelt es sich aber (noch) um Duplikate, nicht um Bibliotheken.

Die Klassen

Sowohl Stateprog als auch SimpleProg haben gemeinsame Klassen und sind auch sonst unter der Oberfläche ähnlich aufgebaut.

Die Hauptprogramme

Später.

Die Oberflächen-Klassen

Die Oberfläche besteht aus einem Bildschirm und Oberflächenelementen. Der Bildschirm kümmert sich auch um die Signale. Für eigene neue Projekte rate ich von der Verwendung ab. ControlP5 z.B. ist sehr ausgereift und “android-fest”.

Der Kommunikator

Der Kommunikator kümmert sich um die Verbindung, das Senden und Empfangen. Sowohl unter USB als auch unter Bluetooth kann man mit habeDaten() und leseBytes() die Schlange der empfangenen Bytes auslesen. Lediglich muss das Füllen (also das Abfragen) unter USB per Hand im Hauptprogramm erfolgen. Unter USB macht das die Funktion onBluetoothDataEvent, welche man am besten im Hauptprogramm definiert. Bis auf die Initialisierung (Bluetooth oder USB) sind dann alle weiteren hardwarespezifischen Dinge gekapselt. Diese Klasse ist am ehesten in anderen Projekten verwendbar.

Der Befehlsmanager

Der Befehlsmanager verwaltet die Befehle, also alles das, was ein Programm an den Arduino schicken kann. Diese Klasse ist interessant, wenn man bestehende Programme erweitern will (z.B. neue Befehle oder neue Hardware). Das Hauptprogramm zeigt nur die Befehle an, die der Befehlsmanager anbietet. Dies ist abhängig von der eingestellten Hardware.

ProgSlot

Der ProgSlot enthält einen Befehl. Somit braucht SimpleProg ein Array mit 12 ProgSlots, um das Programm für sich selbst zu speichern.

Befehlsparameter ändern

Ist man beispielsweise mit den Wartezeiten der beiden Wartebefehle unzufrieden, kann man die voreingestellten Parameter leicht ändern. In der Befehlsliste findet man die Befehle unter ihrem Namen. Man muss nur aufpassen, dass man die richtige Hardware erwischt. Soll beispielsweise die Wartezeit für “Warte kurz” auf 200ms sinken, muss statt der drei eine zwei eingetragen werden.

Einen neuen Befehl hinzufügen

Möchte man nach dem im Kapitel über die Firmware beschriebenen Muster einen Befehl hinzufügen, so muss einfach nur in der Liste aller möglichen Befehle ein weiterer Eintrag hinzugefügt werden. Dazu öffne man die Klasse Befehlsmanager. Drei Hardware-Varianten sind vorbereitet: Männel (Männchen), ArduinoUno und die ArduinoBox. Soll der Befehl nur bei der Box verwendet werden, wird bei arduboxBefehle einfach eine weitere Zeile eigefügt. Damit kommt ein neues Objekt der Klasse Befehl in die Liste (also in den Vector).

Die Attribute der Klasse Befehl, welche im Konstruktor übergeben werden, sind in folgender Liste aufgeführt und mit einem Beispiel (Lampe 1 schalten) garniert.

Attribut Bedeutung Beispiel
name Der Name des Befehls, wird im Programm angezeigt. Lampe 1
hatEingabe Muss ein Eingabefeld in der Oberfläche angezeigt werden? true
befehl Die Nummer des befehls laut Arduino-Firmware, hier CMD_SETZE_WERT 37
para1 Der erste Parameter, das Pin der Ausgabe. 5
istFix1 Ist dieser Wert nicht veränderbar? true
para2 Der zweite Parameter, hier der Wert, der auf dem Pin ausgegeben wird. Ist egal, da der Wert nicht fix ist. Am besten 0 (gute Voreinstellung) angeben. 0
istFix2 Ist dieser Wert nicht veränderbar? false

Neue Hardware hinzufügen

Zu einer Hardware gehören Ein- und Ausgabe-Pins inklusive der Befehle. Es müssen also drei Listen angelegt werden:

In der Klasse BefehlsManager sind bereits drei Hardware-Plattformen realisiert. Es ist ein schlichtes Copy/Paste. Die Umgebung selbst wird mit setzeUmgebung festgelegt. Da momentan drei Umgebungen existieren, sind die Parameter 0 bis 2 möglich.

Das Hauptprogramm sollte dann auch konsequent mit dem Befehlsmanager arbeiten, also Namen für Befehle etc. nicht doppelt vorhalten.