Arduino on Schallberts Blog

🎄 Steckbrett-Lagerfeuer

Schallbert — Mon, 01 Jan 0001

Projekt-Steckbrief

Schwierigkeit: Anfänger 1/5
Kosten: 8…25€
Zeit ~1h

Überblick

Dies ist ein schnelles und einfaches Projekt, das zeigt, wie man mit einem Microcontrollerboard und einigen LEDs eine warme und gemütliche Wohnzimmeratmosphäre schaffen kann. An eine Powerbank angeschlossen, wird diese kleine Bastelei den ganzen Abend leuchten und eine warme und gemütliche Atmosphäre schaffen. Ich habe Teile der Idee für dieses Projekt dem Buch “Tiny AVR for the evil Genius” entliehen, in dem ich viel gelesen habe, als ich vor Jahren mit dem Entwurf eingebetteter Software in C begann.

Die Projektkosten hängen von den gewählten Komponenten ab. Wenn ein original Arduino verwendet wird, liegen sie am oberen Ende des Bereichs. So kann man den hart arbeitenden Entwicklern und Ingenieuren von Arduino Anerkennung zollen, die Open-Source-Lösungen für uns alle schaffen 🥳.

Die Hardware

Natürlich kann man jedes Mikrocontroller-Board verwenden, das mindestens 8 digitale Ausgänge und 1 analogen Eingang unterstützt. In meinem Beispiel verwende ich ein Arduino Nano (Nachbau), das ich irgendwo herumfliegen hatte. Zeit für ein Upgrade auf das “Original”… Des Weiteren benötigt man ein Steckbrett, ein paar Drähte und acht LEDs. Ich empfehle, 5 warmweiße LEDs, 2 gelbe LEDs und 1 rote LED mit ähnlicher Helligkeit (Lumenzahl) zu verwenden, um Farben zu erhalten, die einem echten Feuer ähnlich sind.

Die Software

Die Software erzeugt einen flackernden Lichteffekt mit unterschiedlicher Geschwindigkeit.

Einrichtung

Beim Start definiere ich in setup() die Pins, an die die LEDs angeschlossen sind, als Ausgänge. Ich lasse einen offenen Analog-Pin einmal auslesen und nehme dessen (undefinierten) Wert als Seed für den später besprochenen Pseudo-Zufallszahlengenerator.

Schleife

In der Endlosschleife berechnet das Programm eine neue Zufallszahl und übergibt diese dann an die nachgeschalteten Funktionen. Hier erzeugt ein Zufallszahlengenerator einen Wert, der dann verwendet wird, um

zu bestimmen, welche der acht LEDs leuchten soll
die Zeit festzulegen, für die dieser LED-Status beibehalten werden soll.

Schließlich werden die LEDs entsprechend gesetzt und die Schleife wiederholt sich am Anfang.

Linear rückgekoppeltes Schieberegister

Der Zufallszahlengenerator ist als sogenanntes linear feedback shift register (LSFR) mit einer Länge von 32bit implementiert (wiederholt sein Muster nach max. 2^32 Schritten). Diese Implementierung verwendet den “Galois-Typ” von LFSRs.

Galois LFSR Implementierung

void loop() 
{
 iRandNum = (iRandNum >> 1) ^ (-(iRandNum & 1u) & 0xd0000001u);
 [...]
}

In dieser Codezeile passiert eine Menge, also schauen wir sie uns mal genauer an.

Wesentlich für diese Art von Zufallszahlengeneratoren ist die XOR-Operation, die durch ein ^ in der Mitte der Codezeile angezeigt wird. XOR" bedeutet “eXclusive OR”, das nur dann eine logische 1 ausgibt, wenn die logischen Eingänge A und B unterschiedlich sind. Wenn “A” und “B” beide “0” oder beide “1” sind, wird dieses Gatter “0” ausgeben.

Beispiel für binäres XOR:

 A B Ergebnis
0b00001111 ^ 0b00110011 = 00111100

Links vom XOR-Operator wird die aktuelle Zufallszahl um 1 nach rechts verschoben (>>). Dabei wird ihr gesamter Inhalt wird um ein Bit geschoben. In numerischer Hinsicht bedeutet dies, dass der Wert ganzzahlig durch zwei dividiert wird.

Beispiel für binäres SHIFT:

 A B Ergebnis Als Zahl:
0b00001111 >> 1 = 0b00000111 15 >> 1 = 7

OK, analysieren wir die obige Zeile Code weiter. Direkt neben dem XOR-Operator findet eine weitere Operation statt: Ein logisches AND (&) zwischen unserer aktuellen Zufallszahl und 1u, was “unsigned 1” bedeutet. Dabei werden alle höheren Bits des Zufallszahlengenerators maskiert. Das Ergebnis dieser Aktion ist eine einfache “0”, wenn die Zahl eine “0” als niedrigstwertiges Bit hat usw.

Beispiel für binäres UND:

 A B Ergebnis 
0b00001111 & 1 = 0b00000001

Die Negation am Anfang dieses Terms bedeutet, dass, wenn das Ergebnis des vorherigen & 0 war, der gesamte Term wieder 0b00000000... sein wird. Wenn das Ergebnis -1 lautet, sieht der 2er-Komplement-Binärcode stattdessen wie folgt aus: 0b1111111....

Dies ist eine einfache Möglichkeit, einen einzelnen booleschen Wert auf einen beliebigen längeren Datentyp anzuwenden, ohne eine Verzweigungslogik wie bei einer if()-Klausel zu verwenden.

Und schließlich gibt es ein weiteres logisches AND zwischen diesem Begriff und einer festen Bitmaske 0xd0000001u. Letztere sind die “Anzapfungen” des LFSR, d.h. welche Bits des aktuellen Wertes in das System zurückgeführt werden. Die Aufschlüsselung dieses Hex-Wertes in Boolesche Werte zeigt: 0xd = 0b1101", d.h. die Bits 32, 31, 29 und 1 werden mit der aktuellen Zufallszahl maskiert, so dass nur ihre Werte unberührt bleiben, während alle anderen auf “0” gesetzt werden.

Galois LFSR Zusammenfassung

Puh, das war eine Menge. Es ist Zeit für ein paar Minuten Pause.

Gut, fassen wir die Codezeile oben nochmal zusammen:

iRandNum = (iRandNum >> 1) ^ (-(iRandNum & 1u) & 0xd0000001u);

Bedeutung: “Wenn das niedrigstwertige Bit der aktuellen Zufallszahl Null ist, dann verschiebe die Zufallszahl einfach nach rechts. Andernfalls XOR anwenden mit den abgegriffenen Bits der aktuellen Zufallszahl.”

LFSRs sind weit verbreitet in der drahtlosen Kommunikationstechnik, sie sind interessant für Prüfsummenberechnungen, [Kryptographen](https://medium. com/@czapfel/an-introduction-to-lfsrs-for-cryptography-bf2602640e91) und können sogar bei Programmierspielen nützlich sein, z.B. bei der Erstellung prozeduraler Karten. LFSRs sind einfach zu implementieren (wie man oben sieht, benötigen sie im Extremfall sogar nur eine einzige Codezeile!) und verbrauchen nicht viele Ressourcen. Hier ist ein hervorragender Blogpost, der sich eingehend mit LFSRs beschäftigt, wenn Sie eher der visuelle Typ sind (und weniger der logische). Nachteilig ist, dass ihre “Zufallsqualität” schlecht ist, weil sie deterministisch sind.

Alles in allem fand ich das Thema so interessant, dass ich mich entschlossen habe, hier einen LFSR manuell zu implementieren, anstatt die Arduino-Funktion random() zu verwenden.

Pitfall! Spielszene: prozedurales Leveldesign mittels LFSR ^[1]

Ein Problem bleibt

Nun, wenn Sie die Codezeile vollständig verstanden haben, sehen Sie, was passiert, wenn die Zufallszahl nur Nullen enthält.

Er wird nie wieder aus diesem Zustand herauskommen 💀.

Deshalb sollte man diese Art von LFSR niemals mit “0” initialisieren.

Ansteuerung der LEDs

Der Rest der Software hat viel mehr Zeilen, macht aber auch viel mehr langweilige Sachen. Sie nimmt den generierten 32-Bit-Zufallswert und lässt ihn an den 8 LED-Ausgängen vorbeilaufen, d.h. jede LED “sieht” jedes Bit des Wertes. Zwischen jeder dieser Iterationen wird eine zufällige Verzögerung verwendet, so dass die Flackergeschwindigkeit auf eine Änderungsrate begrenzt ist, die wir Menschen noch wahrnehmen können.

Die Hardware

Zum Glück ist die Hardware einfacher zu erklären als die Software:

Ein Arduino Nano-Board ist mit einem Prototyping-Board verbunden.
Anoden der acht LEDs (+) sind mit den digitalen Ausgängen D2...D9 verbunden.
Ihre Kathoden werden mit Jumpern gebrückt und mit dem “GND” des Arduino verbunden.

Dies ist die einfachste Konstruktion, die mir für diese Aufgabe einfiel.

Verbesserungen

Jede LED sollte einen Vorwiderstand bekommen.
- In meinem Design ist der Strom nur durch den maximalen Strom begrenzt, den der Arduino Pin treiben kann.
- Entweder kann die LED deutlich mehr als 40mA Spitzenstrom verkraften oder sie wird unweigerlich irgendwann durchbrennen.
- Bei der Berechnung des Widerstands sollte man sich an das Datenblatt der LED halten, da verschiedene LED-Farben unterschiedliche Spannungen haben.
- Beispiel für eine Widerstandsberechnung bei einer Versorgungsspannung von 5V für eine Warmweiße LED: 20mA @ 3.1V --> R = U/I = (Usup-Uled) / I = 1.9 / 0.02 = 95Ohm. Nächster Widerstand aus der E6-Reihe 100Ohm.
Jede LED könnte einen Parallelkondensator erhalten.
- Dies würde den Flackereffekt glätten.
- Man könnte Videos aufnehmen, in denen die Kamera nicht durch das Flackern der LEDs gestört wird. Das wäre doch schön.
- Beispiel Kondensatorberechnung: Durchschnittlicher Strom im ausgeschalteten Zustand 20mA, erlaubter Spannungsabfall 0.6V innerhalb von 1ms. Vorgeschlagene Kapazität ist dann 20mA * 1ms / 0.6V = 33uF

Zeit für eine DIY-Replik?

Bitteschön!

Steckbrett-Lagerfeuer DIY Anleitung

ClickEncoder

Schallbert — Mon, 01 Jan 0001

Projekt-Steckbrief

Schwierigkeitsgrad: Mittel 3/5
Kosten: 0€
Zeitaufwand: ~6h

Überblick

Bibliothek für das Arduino Framework, geschrieben in C++.

Der Quellcode selbst besteht nur aus ein paar hundert Zeilen. Er ist leichtgewichtig und leistungsfähig, da der verbesserte Algorithmus weniger Berechnungen benötigt und gleichzeitig eine bessere Zustandsinterpretation bietet als das ursprüngliche Projekt, von dem sie abgezweigt ist. Die Bibliothek ist offiziell auf PlatformIO IDE veröffentlicht und wird auf Github gehostet und gepflegt. Sie enthält Beispiele sowohl für Arduino- als auch für PlatformIO-IDEs und bietet Unittests, die nach der Anpassung an die spezifische Anwendung ausgeführt werden können.

Motivation

Ich habe zunächst die von 0xPIT veröffentlichte Originalbibliothek verwendet, aber diese verursachte bei mir einige Compiler-Warnungen, außerdem waren die Messwerte des Encoders nicht einwandfrei und manchmal gab es Jitter oder zurückspringende Werte, was ich nicht akzeptieren wollte.

Lösung

Da das Archiv ungepflegt aussah und meine Anfrage für Verbesserungen nicht beantwortet wurde, beschloss ich, diese Probleme selbst zu beheben. Ich habe also behutsam einen Teil des Codes umgeschrieben. Für mein damaliges Projekt benötigte ich auch ein “Wiederholungssignal”, wenn eine Taste kontinuierlich gedrückt wird, also fügte ich auch dies hinzu. Schließlich trennte ich den Encoder-Algorithmus von der Tastenbehandlung und stellte separate Klassen bereit, so dass nun bei Bedarf jede beliebige Kombination aus Taste und Encoder verwendet werden kann, jeweils mit konfigurierbarem Verhalten.

Encoder Algorithmus erklärt

API

Die API von ClickEncoder ist einfach und leicht zu verstehen: service() führt die Geschäftslogik aus und die Zustandsinterpretation durch. Diese Methode muss regelmäßig ausgeführt werden, um zu überprüfen, ob der Encoder seit seinem letzten Aufruf bewegt wurde, in welche Richtung, wie viele Schritte, und diese Werte dann in einer Akkumulatorvariablen speichern. getIncrement() gibt die Schrittänderungen des Encoders seit dem letzten Aufruf zurück. getAccumulate() gibt die Summe der Inkremente seit dem Start zurück. getButton() gibt den aktuellen Button-Status zurück.

void service();
int16_t getIncrement();
int16_t getAccumulate();
Button::eButtonStates getButton();

Encoder-Status

Der Encoder verwendet einen Gray Code zur Kodierung der Schritte. getBitCode() wandelt diesen Code, der über die Hardware-Pins A und B des Encoders übertragen wird, in eine “0…3”-Rasten-Interpretation um, wobei die Zahlen bei einer Rechtsdrehung ansteigen und bei einer Linksdrehung abfallen. Dies geschieht effizient ohne Verwendung von if() oder anderer Verzweigungslogik.

uint8_t Encoder::getBitCode()
{
 // GrayCode convert
 // !A && !B --> 0
 // !A && B --> 1
 // A && B --> 2
 // A && !B --> 3
 uint8_t currentEncoderRead = digitalRead(pinA);
 currentEncoderRead |= (currentEncoderRead << 1);
 
 // bit0 of result to be inverted if set
 currentEncoderRead ^= digitalRead(pinB);
 return currentEncoderRead;
}

Ich habe hier mit einem Trick gearbeitet, sodass man sich den Code-Schnipsel oben möglicherweise mehrfach ansehen muss. Der Zustand von PinA wird auf Bit1 von currentEncoderRead geschrieben, indem ich es mit der <<-Operation nach links schiebe. Gleichzeitig bleibt der Status des 0. Bits durch |= aber erhalten. Würde ich jetzt PinB einfach logisch &= anbinden, dann würde ich den Gray-Code verletzen, nachdem A&&B=2 sein sollte und nicht 3.

Sind A und B also beide nicht gesetzt, bleibt das Ergebnis 0, denn 00^00=00=0. Ist nur A gesetzt, B aber nicht, so lautet das Ergebnis 11^00=11=3. Wenn B gesetzt ist, A aber nicht, ergibt sich 00^01=01=1. Sind beide gesetzt, schließlich 11^01=10=2.

Für weitere Informationen zum Thema logische Binäroperationen siehe mein Steckbrett-Lagerfeuer Projekt

Zustandsinterpretation

Nachdem der Bitcode gelesen wurde, wird die Variable rawMovement gesetzt, die uns sagt, wie weit der Encoder zwischen zwei Durchläufen der service() Routine gedreht wurde. Hier sieht man, dass dieser Schritt zeitkritisch ist: Es kommt zu Aliasing-Fehlern, wenn der Geber schneller einmal alle Positionen wechselt, als dass service() erneut aufgerufen wird. In diesem Falle würden Schritte verloren gehen.

void Encoder::handleEncoder()
{
 uint8_t encoderRead = getBitCode();
 // bit0 set = status changed, bit1 set = "overflow 3" where it goes 0->3 or 3->0
 uint8_t rawMovement = encoderRead - lastEncoderRead;
 lastEncoderRead = encoderRead;
 // This is the uint->int magic, converts raw to: -1 counterclockwise, 0 no turn, 1 clockwise
 int8_t signedMovement = ((rawMovement & 1) - (rawMovement & 2));

 encoderAccumulate += signedMovement;
 encoderAccumulate += handleAcceleration(signedMovement);
}

Hier ein weiterer Trick: signedMovement wird berechnet, indem die Bewegung in eine vorzeichenbehaftete Ganzzahl umgewandelt wird, die 0 als “nicht gedreht”, -1 als “links gedreht” und 1 als “rechts gedreht” darstellt. Dabei wird das Verhalten bei Integer-Überlauf ausgenutzt, in Kombination mit der Interpretation von “signedness”.

Abschließend wird die Akkumulation durchgeführt und die Beschleunigung, sofern konfiguriert, dem Akkumulator hinzugefügt, je nachdem, wie schnell der Geber gedreht wird.

Um diese beiden Methoden ohne Verzweigungen zu programmieren, habe ich mehrere Abende Grübelei und praktisch einen halben Block kariertes Papier benötigt. Offen gesagt haben mich diese paar Zeilen Code an den Rande der Leistungsfähigkeit meines Hirns gebracht. Ich habe das Programmieren eben nicht von der Pike auf gelernt 😅

Die Methode getAccumulate()

Sie ist wirklich einfach. Sie gibt nur den internen akkumulierten Wert zurück, der der Konfiguration des Encoders entspricht, wie viele Ticks einen Schritt ausmachen.

int16_t Encoder::getAccumulate()
{
 return (encoderAccumulate / stepsPerNotch);
}

Die Methode getIncrement()

Gibt zurück um wie viele Ticks sich der Encoder seit dem letzten Aufruf dieser Methode bewegt hat.

int16_t Encoder::getIncrement()
{
 int16_t accu = getAccumulate();
 int16_t encoderIncrements = accu - lastEncoderAccumulate;
 lastEncoderAccumulate = accu;
 return (encoderIncrements);
}

Ermittlung des Tasterzustands

Die Methode handleButton()

Alle Tasterzustände leiten sich von zwei Basiszuständen ab: gedrückt oder nicht gedrückt. Dies spiegelt sich in der Logik wider:

void Button::handleButton()
{
 if (lastGetButtonCount < ENC_BUTTONINTERVAL)
 {
 return;
 }
 lastGetButtonCount = 0;

 if (digitalRead(pinBTN) == pinActiveState)
 {
 handleButtonPressed();
 }
 else
 {
 handleButtonReleased();
 }

 if (doubleClickTicks > 0)
 {
 --doubleClickTicks;
 }
}

Der Taster kann so konfiguriert werden, dass er seltener ausgelesen wird als der Encoder. Wenn dies der Fall ist, bleibt diese Methode zwischenzeitlich ohne Aktion.

Taste gedrückt:

handleButtonPressed() kann entweder Closed, Held oder LongPressRepeat zurückgeben, je nachdem wie der Taster konfiguriert ist und wie lange er bereits gedrückt wurde.

Taste nicht gedrückt:

handleButtonReleased() kann entweder Clicked, Released oder Doubleclicked zurückgeben, abhängig von der Konfiguration des Tasters und der Anzahl der Klicks innerhalb einer bestimmten Zeit.

Konfiguration der Bibliothek

Das Verhalten der Encoder/Tastenerkennung kann in der Datei encoder.h mit Hilfe der unten aufgeführten Konstanten geändert werden. Die Werte wurden bereits optimiert und fühlen sich, zumindest für mich, natürlich an. Sie sollten geändert werden, wenn Sie ein anderes Serviceintervall als 1ms verwenden möchten, da diese Werte alle dieses Intervall als Referenz nehmen.

// ----------------------------------------------------------------------------
// Acceleration configuration (for 1ms calls to ::service())
//
constexpr uint8_t ENC_ACCEL_START = 150; // The smaller this value, the quicker you must turn to activate acceleration.
constexpr uint8_t ENC_ACCEL_SLOPE = 75; // the smaller this value, the stronger the acceleration will manipulate values.

// Button configuration (values for 1ms timer service calls)
//
constexpr uint8_t ENC_BUTTONINTERVAL = 20; // check button every x ms, also debouce time
constexpr uint16_t ENC_DOUBLECLICKTIME = 400; // second click within x ms
constexpr uint16_t ENC_LONGPRESSREPEATINTERVAL = 200; // reports repeating-held every x ms
constexpr uint16_t ENC_HOLDTIME = 1200; // report held button after x ms
// ----------------------------------------------------------------------------

Verwenden Sie sie in Ihrem Projekt!

Die Bibliothek ist eine Open-Source-Software, die unter der MIT-Lizenz steht.
PlatformIO-Benutzer? Ganz einfach, suchen Sie sie in der Ansicht ‘Bibliotheken’, die Tags sind Arduino, Encoder, Schallbert. Dann ist es nur noch ein Klick, um sie zu Ihrer Lösung hinzuzufügen.
Alternativ können Sie auch das repository klonen oder forken und die Header/Cpp-Datei nach eigenem Ermessen verwenden.
Sie möchten etwas beitragen? Vielleicht haben Sie eine effizientere Zustandsberechnung für die Taster? Ich würde mich freuen, Ihren Pull Request in meinem Posteingang zu finden.