Tipps + Tricks

Inhaltsverzeichnis

IR-Auslöser für Pentax-Kameras

Akku-Ladekurve

Wir bauen uns eine Piepliothek!

Ein Automat ohne delay()

Pimp my Code!

Toner-Transfer-Quetsche
Tipps + Tricks


Tipps + Tricks

ANSI-Steuersequenzen

Wer ANSI-Steuersequenzen verwenden möchte, sollte zu einem sogenannten Terminalprogramm greifen, da der serielle Monitor der Arduino-IDE mit solchen Sequenzen nichts anfangen kann. Ich verwende minicom unter Debian GNU/Linux 7.

Wer nach einem Terminalprogramm sucht, sollte darauf achten, dass es VT100-kompatibel ist.

Beispiele:

Serial.print("\33[2J");   // Terminalfenster loeschen
Serial.print("\33[?25l"); // Cursor ausschalten
Serial.print("\33[0;0H"); // Cursor "home" (nach links oben)

Eine Liste aller Steuersequenzen befindet sich hier.

Zufallszahlen

Wer sich ein bisschen intensiver mit Computern oder dem Arduino beschäftigt, erfährt irgendwann, dass erzeugte Zufallszahlen nur „pseudo-zufällig“ sind und aus einem Pool mit begrenztem Vorrat stammen. Obendrein erhält man unter gleichen Startbedingungen immer die gleiche Folge von Zufallszahlen.

Wer tatsächlich zufällige Zufallszahlen benötigt, sollte den Zufallsgenerator mit dem Befehl randomSeed() initialisieren – zum Beispiel mit dem Wert von millis() beim ersten Tastendruck. Wenn es keine Taste gibt, nimmt man den Wert eines nicht beschalteten Analog-Eingangs.

Die Funktion randomSeed() bewirkt, dass der Startpunkt der Zufallszahlen-Folge an einer anderen Position liegt.

Im Code sieht das zum Beispiel so aus:

randomSeed(analogRead(0));

Am besten bringt man das im Setup-Teil eines Sketches unter.

Siehe auch den entsprechenden Abschnitt in der Referenz.

Auf Tastendruck warten

Soll ein Sketch erst dann mit seiner Arbeit beginnen, wenn man einen Taster drückt, baut man eine entsprechende Abfrage bzw. Warteschleife in setup() ein. Den Taster verbindet man so mit einem Pin, dass er ihn im gedrückten Zustand mit Masse/GND verbindet.

Wenn man den Pin vor der Warteschleife mit

pinMode(tasterPin, INPUT_PULLUP);

konfiguriert, genügt eine Zeile wie

while(digitalRead(tasterPin)==HIGH) {}

und der Arduino fährt erst dann fort, wenn der Taster betätigt wird.

INPUT_PULLUP bewirkt, dass der „Pull-up-Widerstand“ des Pins aktiviert wird. Auf diese Weise ist der Zustand des Pins bei nicht gedrücktem Taster immer HIGH.

Pin-Bezeichnungen und Logik entkoppeln

Wenn man mit einem neuen Sketch anfängt, verwendet man bei der Manipulation von Pins oft deren „Klarnamen“:

digitalWrite(13, HIGH);

Wenn man derlei Pin-Manipulationen später ändern möchte, weil sich zum Beispiel die Verdrahtung geändert hat, muss man das nicht selten an vielen Stellen des Codes tun.

Um sich die Arbeit zu erleichtern und Fehlern vorzubeugen, ist es sinnvoll, die Pin-Nummern am Anfang des Sketches in Variablen abzulegen und im weiteren Code nur noch diese Variablen zu verwenden. Wichtig ist, „sprechende“ Variablennamen zu verwenden:

const byte LEDPin=13;
...
digitalWrite(LEDPin, HIGH);

Wenn man später die Verdrahtung ändert, muss man diese Änderung nur an einer Stelle des Codes nachvollziehen.

Besonders vorteilhaft ist dieses Vorgehen, wenn man den Sketch anderen Leuten zeigt, denn ein Leser, der nicht „im Thema steckt“, muss sich nicht merken, was an einen Pin angeschlossen ist und kann sich besser auf das konzentrieren, was wichtig ist.

Weil man am Anfang nur selten weiß, wie umfangreich der Code wird, sollte man diese „Entkopplung“ vom Start weg vornehmen – auch wenn das mehr Tipperei bedeutet.

Notizen

Wenn man sich Notizen zu einem Sketch machen möchte, sollte man das in einem eigenen Tab tun, den man zum Beispiel „notizen.h“ nennt. Das hat mehrere Vorteile:

  • Die Notizen stehen jederzeit zur Verfügung, wenn man am Programm arbeitet, denn Headerdateien (*.h) werden automatisch geöffnet. Für Dateien, die auf .txt enden, gilt das nicht.
  • Die Notizen werden mitgesichert, wenn man den Sketch unter einem neuen Namen speichert. Auch das gilt nicht für txt-Dateien.

Wenn man die Notizen als Kommentar kennzeichnet, macht es nichts, wenn die Datei irgendwo eingebunden wird.

Beispiel:

/* <--- kennzeichnet den Anfang eines mehrzeiligen Kommentars

Hier stehen die Notizen

Hier endet der Kommentar ---> */

Versionierung

Ich habe Versionierung lange Zeit für Sesselpuperkram gehalten.

Das änderte sich schlagartig, als mir jemand sagte, dass Versionierung ein Merkmal ernsthafter Arbeit sei. Inzwischen habe ich mir angewöhnt, meine Programme mit Versionsnummer zu versehen und alte Versionen aufzuheben.

Es ist zum Beispiel unheimlich angenehm, auf eine funktionierende Version zurückgreifen zu können, wenn man sich beim Programmieren „verrannt“ hat und den Fehler, der verhindert, dass ein Sketch zum Arduino übertragen wird, nicht finden kann.

In so einem Fall kann man zur letzten funktionierenden Version zurückkehren und von dort aus weitermachen.

Da ein Punkt üblicherweise als Trennzeichen zwischen Dateinamen und -erweiterung bzw. -typ interpretiert wird, verwende ich stattdessen einen Unterstrich.

Beispiel: Gregors_Wunderlampe_0_22 bezeichnet Version 0.22 des Sketches „Gregors Wunderlampe“. Da ich mich bei Version 0.17 verprogrammiert hatte und nicht ermitteln konnte, wo der Fehler lag, bin ich zu Version 0.16 zurückgekehrt und habe diese zur Basis von Version 0.18 gemacht. Version 0.17 habe ich aufgehoben, weil es sein kann, dass ich dort Dinge versucht habe, die ich mir nicht notiert habe (siehe „Notizen“ weiter oben).

Ich habe mir außerdem angewöhnt, erst dann mit einer neuen Version zu beginnen, wenn die aktuelle Version zufriedenstellend funktioniert.

Bevor ich anfing, meine Arbeit zu versionieren, habe ich einen „zerprogrammierten“ Sketch oft frustriert aufgegeben und mit etwas Anderem angefangen. Seit ich meine Arbeit mit Versionsnummer versehe und alte Versionen aufhebe, komme ich sehr viel besser voran und der Frust hält sich in engen Grenzen.


Nach oben Inhaltsverzeichnis

Valid HTML 4.01 Transitional