Folker hat im ersten Beitrag schon gezeigt, was man aus LED Matrizen und einem passenden LED Controller realisieren kann. Im folgenden Beitrag geht es um den Unterbau, von dem das Display letztendlich angesteuert wird.

Die Idee hinter dem Projekt war ein System, welches ein paar Spiele (Tetris primär) bietet und die LED-Matrix als Display verwenden kann. Bei der LED-Hardware und Ansteuerung war das ganze von Anfang an klar, bei der Ansteuerung des Ganzen haben wir uns dann für einen Raspberry Pi entschieden. Die Boards sind günstig und einfach zu beschaffen. Zudem gibt es eine riesige Community und guten Software Support. Das Ganze war ein Freizeitprojekt, daher gibt es an vielen Stellen sicherlich noch Ver­bes­se­rungs­po­ten­zi­al.

Hardware

Entwickelt und getestet wurde mit einem Raspberry Pi B. Die beiden USB Ports haben gerade gereicht um ein USB-WLAN Modul und den Diamex Matrix-Player anzuschließen.
Als WLAN Modul wurde TP-WN725N verwendet, welches auf dem rtl8188eu Chip basiert, und nach dem Start den RPi in ein Access Point mit dem Netz „GAMES“ verwandelt. Da hier ein sehr minimalistisches Linux System verwendet wird, reicht auch eine kleine SD Karte aus. Im Prinzip könnte alles auf eine 512 MB Karte passen.

Software

Als Betriebssystem kommt Linux zum Einsatz und zwar ein minimalistisches, zugeschnitten auf eigene Bedürfnisse. Buildroot passt für diesen Zweck sehr gut. Zusätzliche Anpassungen wurden dann an der Konfiguration gemacht, damit das WLAN aufgespannt wird und die „Game engine“ nach dem Boot automatisch gestartet wird. Dabei gibt es auch ein paar Hürden: der eingesetzte rtl8188eu Chip funktioniert nicht auf Anhieb mit dem Standard Linux hostapd Deamon im Access Point Modus, daher musste dafür eine angepasste Version von hostapd gebaut werden. Bei anderen Chips, entfällt dieser Schritt und hostapd.conf muss dann entsprechend angepasst werden.

Als Software für die Spiele und die Display Ansteuerung wurde ein C++ Programm geschrieben. Nach der Erfahrung mit der Poco Bibliothek bei der Portierung von hyperion  für OpenWRT habe ich mich gleich dafür entschieden. Die Spiele sollten nicht fest kodiert werden und nach Möglichkeit erweiterbar, daher fiel die Wahl auf LUA – eine Programmiersprache, die oft im Embedded Bereich verwendet wird, eine C Anbindung, keine komplexe Abhängigkeiten hat und je nach Konfiguration auch klein ist. Ich habe versucht, die Software modular umzusetzen, sodass künftige Erweiterungen möglich sind. Erweiterung der LED-Ansteuerung um ein neues Protokoll sollte mit wenig Aufwand möglich sein – in der Hinsicht habe ich mich ebenfalls an hyperion gehalten. Hart kodiert ist aktuell die Displaygröße von 16×32 Pixel, das muss auf jeden Fall flexibler gemacht werden.

Die Hintergrundfarbe wird grün, wenn eine Verbindung mit der Engine besteht.

Die Spiele-Steuerung ist aktuell nach der Anmeldung im WLAN über die lokale Adresse des Systems (192.168.0.1) im Browser möglich. Ein auf dem RPi laufender HTTP-Server stellt eine kleine Seite zur Verfügung, die über WebSockets mit der Spiele-Engine kommuniziert und die Button-Klicks an das LUA Spiel weiterleitet. Auf diese Weise kann man die Spiele mit eigenem Handy als Gamepad ausprobieren, ohne Zugang zum Aufbau zu haben und ohne zusätzliche Software installieren zu müssen, wie es bei Bluetooth z.B. der Fall wäre. Aktuell bin ich noch an der Unterstützung der USB-Gamepads dran.

Kompilieren

Die ganzen Projektdateien habe ich auf GitHub abgelegt: led-matrix-games

Zum Kompilieren wurde eine Debian Jessie x64 Installation verwendet. GCC Compiler und andere build tools wie git müssen evtl. über apt-get nachinstalliert werden.

git clone https://github.com/Gamadril/led-matrix-games.git
cd led-matrix-games
./build.sh

Der Buildprozess dauert sehr lange und generiert dabei einen Cross-Compiler, den Linux Kernel und das Root Dateisystem.

sudo ./create-image.sh

generiert dann einen SD Karten Image, welches mit den üblichen Tools auf die SD Karte installiert werden kann. Unter Linux wäre es

dd if=build/sdcard.img of=/dev/sdX

Im Elektor Heft 2016/Januar/Februar ist nun unser aktuelles Projekt Jinx!-Matrixplayer erschienen.  Ein TPM2-Player, der auf sehr spartanische (Hardware) Weise ermöglicht, eine live am PC erstellte Choreografie auf verschiedenen LED-Panels, Stripes oder eigenen Kreationen abzuspielen. In Kombination mit dem Matrix-Player kann man mit einem Billigst-Tablet, wir haben das TrekStor SurfTab® wintron 7.0 dafür getestet (Reichelt Elektronik für unglaubliche 50 Euro), benutzen und es funktioniert!!! Windows 10 kann man möglicherweise als Quantensprung bezeichnen, zumindest im unteren Low-cost-Bereich. Wer hätte vor einem Jahr vermutet, dass man noch in 2015 für einen Fuffi (das ist echt irre) einen kompletten Win10-PC (ich nenne das Tablet jetzt einfach mal so – weil es ja Tatsache so ist) erhält, der völlig einfach auch Jinx! installiert und ausführt, wunschgemäß alles ausgibt, was auch von einem PC erwartet wird. Das ist für mich persönlich der Technik-Hammer des Jahres 2015.

Leider kein Licht ohne Schatten. Warum in aller Welt sich die Entwickler dieser Tablets nicht durchringen konnten, mehr als eine USB-Schnittstelle zu integrieren, besser gesagt, warum man an USB-Schnittstellen sparen musste, ist nicht nachvollziehbar. Mehr noch, genau dieser Umstand wird das Einsatzgebiet dieser kleinen Kampfzwerge enorm begrenzen. Offenbar schlägt die Hardwareoptimierung an dieser Stelle irre Kapriolen – für etwa 6-8 Dollarcent Sparpotential hat man den allermeisten Win 10 Tablets eine zweite USB-Buchse versagt. Folge ist, dass man die Revolution in Embedded-Anwendungen vollkommen versemmelt hat. Ich brauche die USB-Buchse als Ladebuchse bzw. als permanente Stromversorgung. Nehme ich die USB-Buchse als Ladebuchse bzw. als permanente Stromversorgung, dann geht kein USB mehr. Nehme ich USB als USB, dann läuft alles auf Akku – aber eben nicht ewig – eher nur kurz.

Sicher kann man Umschaltemöglichkeiten nutzen, nichts ist bisher etabliert oder gängig. Keine funktionierenden Adapter in Sicht. Alles nur Bastelkrams und halbgewalkter Murks. Das schöne Gehäuse aufbrechen oder anbohren will auch niemand.

Mein Fazit: dreimal abgeschnitten und immer noch zu kurz – bei solidem high-tech Material besonders ärgerlich…

Was wäre wenn? …man mitgedacht hätte: Ein Raspberry kostet komplett nackig um 30 Euro, das Touchdisplay nochmals etwa 70 Euro. Dazu kommen Netzteil und Gehäuse. Betriebssystem gibts gratis. Win10 ist aber eher ein Spaß für den Raspi, als eine funktionale Oberfläche. Mit dem Tablett habe ich eine rundum fertige Lösung. Microkontroller mit USB sind super ansteuerbar. Der Raspi wäre für mich ab sofort nur, weit abgeschlagen, die Nummer Zwei. Schade eigentlich.

Bei mir steht ein TP-Link TL-WR1043N (v1) WLAN Router im Wohnzimmer neben dem Fernseher. Er hat einen USB Port und läuft mit OpenWRT – beide waren die Kaufkriterien vor ein paar Jahren für mich und werden wohl auch für künftige Router sein. Am USB Port ist eine 2,5 Zoll Festplatte angeschlossen, welche problemlos vom Router mit Strom versorgt wird und als Netzlaufwerk dient. Seitdem ich mich mit hyperion beschäftigt habe, kam mir immer wieder die Idee in den Sinn, dass der Router auch die Ansteuerung der LEDs übernehmen kann und für Raumbeleuchtung sorgen kann – ist ja sowieso immer an. So ist das Projekt zur Portierung von hyperion auf OpenWRT entstanden…

Das Problem…

Die Schwierigkeit hyperion auf anderen Systemen laufen zu lassen, liegt in seiner Implementierung. Die Software baut auf der Bibliothek Qt4 auf und macht die Umsetzung einiger Paradigmen (wie Beobachter Entwurfsmuster mittels Signal-Slot) denkbar einfach. Qt4 kann jedoch einiges mehr, vor allem im Bereich der User-Interaktion und grafischer Darstellung – hyperion benötigt das alles aber nicht. Durch diese enge Abhängigkeit kommt es dann auch zum anderen Problem: Qt4 ist nicht überall verfügbar (z.B. OpenELEC) und muss dann kompliziert über Installationsskripte in der richtigen Version nachinstalliert werden. Ein weiteres Problem ist die Effekt-Engine, die auf Python Bindings setzt. Die Engine erlaubt es zwar, die Effekte sehr einfach in Python zu schreiben, setzt aber auch die komplette Python Laufzeitumgebung auf dem Zielsystem voraus.

Der Lösungsansatz

Also war mein Ansatz: Benutze das, was überall da ist, kompiliere mit hyperion und liefere aus alles andere zusammen. Der zweite wichtige Punkt: Alle Plattform-Versionen müssen primär Cross-kompilierbar sein. Ich habe mir einige C++ Frameworks  angeschaut, die das Signal-Slot Prinzip ersetzen könnten und gleichzeitig die Umsetzung der Netzwerkkommunikation vereinfachen würden. Aus unterschiedlichen Gründen bin ich bei der Poco C++ Library gelandet und habe LUA als Ersatz für Python genommen. So ausgerüstet habe ich angefangen, hyperion zu portieren.

Letztendlich habe ich einige Teile von hyperion komplett umgeschrieben, sodass diese Version nicht mehr mit dem Original kompatibel ist. Auch die Konfigurationsdatei kann nicht mit dem HyperCon Tool generiert werden – langfristig habe ich ein eigenes Config Tool geplant, welches komplett im Browser läuft,  aber wie immer scheitert es meistens an der fehlenden Zeit für die Umsetzung. Momentan muss also per Hand editiert werden. Was komplett aus einer HyperCon generierten Datei übernommen werden kann ist die LED Konfiguration – da hat sich momentan noch nichts geändert. Der JSON Server unterstützt nur WebSocket Kommunikation, was auch dazu führt, dass so gut wie alle hyperion-remote Anwendungen damit nicht funktionieren, bis auf meine eigene

Der Code ist auf GitHub abgelegt, als separater Branch. Binaries sind nicht im Repository enthalten – sie haben im eigentlichen Code Repository auch nichts zu suchen und werden evtl. künftig auf der GitHub Projekt-Web-Seite zum Download angeboten. Ich empfehle jedoch die Binaries für eigenen Zusammenbau selbst zu bauen, da in meiner Version jedes LED Gerät und jeder Grabber optional ist und im Basisbuild nur Test-Ausgabegerät enthalten ist. Zu bedenken ist, dass der Code hoch experimentell ist und weit von der kompletten Portierung entfernt ist. Die meisten Screen Grabber wurden getestet, externe V4L2 Grabber dagegen gar nicht mangels passender Hardware. Protobuf wurde vorerst komplett entfernt.

Für meinen erwähnten Router mit OpenWRT gab es dann diese Eckpunkte für die Umsetzung mit hyperion:

• LED Player S – lässt sich einfach an den vorhandenen USB Port anschließen
• kein Screen Grabber notwendig, da nur zu Beleuchtungszwecken
• JSON Server zur Steuerung über hyperion-remote
• Effekt Engine

hyperion Bauen

Das Bauen von hyperion ist relativ einfach und auch recht simpel erweiterbar um zusätzliche Plattformen.

Gebaut wird im Falle von meinem Router auf Debian Jessie x64 – aus einfachem Grund, weil es dafür eine fertige Cross-Compile Toolchain gibt, und diese eben ein 64-bit Linux voraussetzt. Falls eine eigene Toolchain bereits auf dem System vorhanden ist, kann auch diese verwendet werden. Dazu muss die Umgebungsvariable TOOLCHAIN_DIR mit dem Pfad zu der Toolchain gesetzt werden.

git clone https://github.com/Gamadril/hyperion.git
cd hyperion
./build.sh openwrt_ar71xx -DENABLE_LED_SERIAL_TPM2=ON -DENABLE_EFFECT_ENGINE=ON -DENABLE_SERVER_JSON=ON

Der erste Parameter openwrt_ar71xx legt die Plattform fest, für welche hyperion gebaut werden soll. Für jede Plattform muss unter platforms ein gleichnamiger Ordner liegen mit zwei cmake Dateien (s. openwrt_ar71xx als Referenz). Alle nachfolgenden Parameter werden zur Konfiguration des hyperion Builds weitergeleitet. In diesem Fall wird die Unterstützung der seriellen Geräte mit TPM2 Protokoll aktiviert. Desweiteren die Effekt Engine und der JSON Server für die Fernbedienung.

Sollte alles gut gehen, wird im build Unterordner die hyperion.zip Datei liegen. Diese muss nun auf den Router  kopiert werden und dort installiert/entpackt werden. Das hat bei mir nicht geklappt, da trotz der kleineren Größe der Platz im Flash nicht ausreicht. Also wurde die Datei auf der USB Festplatte abgelegt (gemountet unter /media) und entpackt. Da sie bei mir mit FAT32 formatiert ist, ist die Erstellung der Links fehlgeschlagen, was beim ersten Start zu einer Fehlermeldung geführt hat. Als Lösung habe ich die Datei einfach umbenannt und dann gestartet.

mv hyperion/lib/libPocoFoundation.so.1.6.1 hyperion/lib/libPocoFoundation.so.31
cd hyperion
LD_LIBRARY_PATH=/media/hyperion/lib ./hyperiond

Normalerweise sollte beim Kompilieren der Suchpfad der Libraries als „./lib“ in hyperiond enthalten sein. Das hat beim Cross-kompilieren hier aus irgendeinem Grund nicht geklappt und ich hatte noch keine Zeit die Ursache dafür zu suchen. Evtl. sind in CMake die entsprechenden Parameter falsch vorgegeben. Deswegen wird beim Start der Ordner für die Bibliotheken per LD_LIBRARY_PATH mit angegeben.

Der Dienst sollte idealerweise beim Start automatisch starten und eine Konfigurationsseite in LuCI wäre auch sehr hilfreich. Darum habe ich mich aber auch nicht gekümmert. Ich starte hyperion von der Konsole und es läuft dann im Hintergrund.

LD_LIBRARY_PATH=/media/hyperion/lib start-stop-daemon -S -b -x /media/hyperion/hyperiond

Feedback und Vorschläge hier oder auf der GitHub Projektseite posten.

P.S. Der Player S gibt sich als ACM (USB Modem) Gerät aus und wird von OpenWRT wahrscheinlich nicht auf Anhieb erkannt (/dev/ttyACM0 fehlt). Abhilfe schafft die Installation vom kmod-usb-acm Kernel Modul über die Web-Oberfläche oder die Kommandozeile.

Eine Kurzanleitung zum Thema LED-Strip und das richtige Netzeil:

Ich rechne mal für einen Strip 240 LED:
Da LEDs ja mit Niederspannung betrieben werden ist der Strom entsprechend höher zu dimensionieren.
Eine Grundeigenschaft der WS2812 ist 1mA Ruhestrom für den PWM-Chip. Da WS2812 mit 5V (idealerweise) betrieben werden und 240 LED sind das also 240mA < also P=U*I > schon 1,2 Watt ohne dass überhaupt eine LED leuchtet. Schaltet man nun alle drei Systeme auf volle Helligkeit, dann kann man mit 60mA pro LED rechnen, also 14,4 A.
Zwischen diesen beiden Extremen liegt die Wahrheit. Durch Niederspannung und damit verbundenem hohen Strom nimmt der Innenwiderstand der Leitungen auf dem Strip eine nennenswerte Größe ein. Der Spannungsabfall bei Volllast über die Striplänge kann schon 2V betragen. Folge ist am Anfang sind die LEDs hell (5V) und am Ende deutlich dunkler (3V). Man hilft sich indem man am Ende des Strips die Spannung einspeist und so das Problem umgeht – man hat also vorn und hinten 5V – der Spannungsabfall dürfte rein empirisch bei diesem Beispiel in der Mitte des Strips etwa 1V betragen. Das ist so gut wie nicht sichtbar. Nachteil – zuerst einmal für Laien etwas schwer verständlich, dann der erhöhte Verkabelungsaufwand, es muss für hohen Strom dickes Kabel verlegt werden (1,5m2).
Die Wattzahl ist dabei LED-üblich recht niedrig – für diesen Strip 72W – im Vergleich zur Glühlampe sparsam.
Nimmt man an, dass die WS2812 als Effektbeleuchtung verwendet werden, dann kann man getrost die Extreme vernachlässigen. Für Weißlicht braucht es alle drei Systeme – Rot, Blau und Grün. Für Einzelfarben reicht also ein Drittel der Leistung, Für Mischfarben die Hälfte oder zwei Drittel. Aber das auch nur bei „volle Pulle“ und über den gesamten Strip.
In der Realität ist man mit der Hälfte des Maximalwertes gut im Rennen – also dürften pro 240LEDs ein 8A/5V Netzteil funktionieren.
Schaltet man zwei Strips hintereinander, dann muss man auch zwei solcherart dimensionierte Netzteile verwenden (für jeden Strip eines – Parallelschaltungen sind zu vermeiden). Dann sollte auch ein ordentliches Ergebnis erreicht werden.

…könnte man das Teil nennen. Norbert (nofri) hat uns da auf die Spur gebracht. Die Fernost Gerätchen nutzen den prähistorischen 89C51 Controller – und „zaubern“ per Bitbanging Effekte auf einen RGB oder RGBW Strip. Die kosten zwar nur 6-8 Dollar, dafür können sie aber auch nix. Immer volle Pulle und superbunt (ich schrieb schon darüber).

Die rudimentäre Tastenabfrage des China-Teils ist natürlich der schmalen Prozessorleistung geschuldet, auch die überschaubaren Effekte, die schwer nachvollziehbar irgendwie einstellbar sind (Geduld und viel Taste drücken).

Naja ok, wir nehmen einen 32bitter – Cortex M0 von STM – der hat Megapower, Megaspeicher und ist dennoch bezahlbar. Im Stickgehäuse aus ABS – das Chinastreifchen kommt im Gegensatz mit Schrumpfschlauch daher.

Klare Bedienbarkeit, sauber via Klemme anschließbare Stromversorgung und Anschluss der Strips plus drei Tasten-Bedienung. Visualisiert über zwei LEDs – fertig.

Wird Ende März (2016) verfügbar sein, steuert 384 LEDs, RGB oder RGBW einstellbar. Drei-Tasten-Bedienung. Viele Effekte on Board. Also doch mehr als ein Tester 

Kostet 7,90 Euro

Bilder des Prototypen:

Es ist soweit! Ab sofort kann man die beliebten WS2812 (und kompatible) mit dem Arduino oder Raspbery (oder mit einem beliebigen, anderen System) ansteuern.

Ja und? Das ging ja vorher auch – Adafruit Library und Arduino -> kein Problem!

Ahhhh ja, ganz soooo einfach ist die Welt ja auch nicht: Der Arduino, die Jünger mögen es mir nachsehen, ist ja nur ein AVR-Prozessörchen Mega328, klingt groß – ist aber leider nischt! Der macht schon Spaß beim Programmieren – zugegeben. Nur ist der AVR-Controller mit der Ansteuerung der Digi-Dots (Neo-Pixel) völlig ausgelastet. Liegt am schnellen Protokoll und an der Art und Weise der Erzeugng desselben mit einem AVR -> Bitbanging. Das Strip-Protokoll kann man nicht komfortabel per DMA erzeugen, dazu ist der AVR einfach zu rechenschwach. Steuert man Digi-Dots an, dann wars das, alle anderen Dinge, die der Arduino tun könnte, Tastatur- oder Sensorenabfrage, Behandlung von Ereignissen – schlicht die Prozesssteuerung ansich ist bei LED-Ansteuerung nicht mehr sinnvoll möglich. Ok, nimmt man einen zweiten Arbuino – halt Stop! Hier wirds doch oppulent, oder?

Besser man nimmt eine kleine Platine, genannt Digi-Dot-BOOSTER, denn Digi-Dot-BOOSTER kümmert sich komplett um die WS2812 Protokolle. Man sagt Digi-Dot-BOOSTER einfach was ausgegeben werden soll, Regenbogen, Abläufe oder statische Farben, von LED bis LED, rückwärts oder vorwärts, abgestuft, schnell langsam usw.
Das geht mittels Script ganz simpel und ultraschnell. Von 94% Prozessorlast auf 0,04% herab! Der Arduino kann nun das tun, wofür er gedacht ist – Ablaufsteuerung!
Die vorher so aufwändige Signalisierung übernimmt der Digi-Dot-BOOSTER alleine. Und der kann das viel, viel besser.

Beim Raspberry liegt die Situation etwas anders. Leistung ist satt da, jedoch ist das Echtzeitbetriebssystem des Raspi nicht unbedingt für die Ausgabe der WS2812-Protokolls geeignet, weil es hier auf exakt-zyklische Erzeugung der Signale ankommt. Auch hier hilft der Digi-Dot-BOOSTER weiter. Mit Phyton beispielsweise ist das eine Kleinigkeit tolle Effekte zu zaubern. Die beliebte Scriptsprache ist dafür einfach perfekt geeignet.

Digi-Dot-BOOSTER kostet ab 5 Euro (10er Pack) und macht genau das, was ihr auf Digi-Dots ausgeben wollt.
Signale, Effekte, Illumination oder Beleuchtung.

Egal welches System benutzt wird.

Anleitung

Beispiel für Arduino

Folker hat gerade den Digi-Dot-Booster angekündigt und ich hatte die Möglichkeit, mich  schon im Vorfeld  etwas damit zu beschäftigen. Zur Ansteuerung kamen bei den Tests unterschiedliche Boards, die ich in meiner Bastler-Kister habe. Am Interessantesten neben Arduino ist sicherlich Raspberry Pi und darum geht es auch im folgenden Beitrag.

Zum Testen habe ich den schon etwas älteren Rapberry Pi B genommen, als Betriebssystem kommt Raspbian zum Einsatz. Bei mir habe ich die grafische Oberfläche deaktiviert, weil ich hauptsächlich damit ohne Maus und Tatstatur per SSH arbeite.

Zum Programmieren habe ich mich für Python entschieden – die Sprache ist weit verbreitet und viele hatten schon mal damit zu tun gehabt. Man muss sich außerdem keine Gedanken um low-level APIs von C und das Kompilieren machen. Rasbian bringt auch eine Entwicklungsumgebung (IDE) für Python mit (https://www.raspberrypi.org/documentation/usage/python/) – man kann also auch direkt auf dem RPi komfortabel programmieren und direkt aus der IDE seine Programme laufen lassen und debuggen.

Der Digi-Dot-Booster wird entsprechend an die SPI Port Pins des GPIO Headers angeschlossen. Da der Digi-Dot-Booster keine Daten zurück schickt, wird nur die MOSI Leitung fürs Senden angeschlossen. RESET Pin kann optional angeschlossen werden, um den Reset des Moduls vom RPi aus im Code steuern zu können.

Damit man mit Python auf die Hardware des Raspberry Pi zugreifen kann, müssen zusätzliche Bibliotheken installiert werden:

sudo apt-get update
sudo apt-get install python-dev python-rpi.gpio python-spidev

In Rapsbian ist SPI standardmäßig deaktiviert, das Aktivieren geht am einfachsten über das eigene Config-Tool:

sudo raspi-config -> 8 Advanced Options -> A5 SPI

Nach einem Reboot des RPi sollten dann /dev/spidev0.0 und /dev/spidev0.1 im System auftauchen.

Nun steht der Arbeit mit dem Digi-Dot-Booster nichts mehr im Wege. Hier ist ein Beispiel zur Ansteuerung von 30 ws2812 LEDs über den Digi-Dot-Booster:

# rainbow.py
import spidev
import time

DELAY = 0.04
LED_COUNT = 30

spi = spidev.SpiDev()

def initSPI():
    # open /dev/spidev0.1 (CS1 Pin wird verwendet)
    spi.open(0, 1)  
    spi.mode = 0b00
    return

def initLEDs():
    # BOOSTER_INIT mit der Anzahl der LEDs und 24 bits pro LED (WS2812)
    spi.writebytes([0xB1, LED_COUNT, 24])
    time.sleep(DELAY)
    return


def clear():
    # BOOSTER_SETRGB 0x000000, BOOSTER_SETALL, BOOSTER_SHOW
    spi.writebytes([0xA1, 0, 0, 0, 0xA5, 0xB2])
    time.sleep(DELAY)
    return

i = 0
initSPI()
initLEDs()

try:
    while True:
        i += 5
        i = i % 360
        # BOOSTER_SETRAINBOW HUE (2 Bytes), SATURATION, VALUE, von der ersten (0) bis
        # zur letzten LED in 10-er Schritten, BOOSTER_SHOW
        spi.writebytes([0xA7, i & 0xFF, i >> 8, 255, 100, 0, LED_COUNT - 1, 10, 0xB2])  
        time.sleep(DELAY)
except KeyboardInterrupt:
    clear()
    spi.close()

Zum Starten von der Konsole aus python rainbow.py eingeben.

Update: Durch die Konfiguration des richtigen SPI Modes per spi.mode = 0b00  ist keine Steuerung des CS im Code notwendig.

Nachdem ich den Digi-Dot-Booster ziemlich schnell auf dem Raspberry Pi mit Python zum Laufen gebracht habe, stellte sich mir die Frage, mit welchem Aufwand SPI in anderen Sprachen verwendet werden kann. Als Versuchsobjekt kam wieder der Digi-Dot-Booster zum Einsatz.
Bei der Auswahl der Sprachen stand die Verfügbarkeit der Bibliotheken zur einfachen Ansteuerung des SPI Buses im Vordergrund. Nach Python habe ich mir Lua angeschaut.

Lua ist eine leichtgewichtige und besonders in embedded Umfeld weit verbreitete Skriptsprache. Die aktuelle Version ist 5.3 und hat unter anderem ganz nützliche Erweiterungen bekommen wie z.B. die Bitweis Operatoren. Bei den Tests habe ich jedoch festgestellt, dass zum Einen die Version 5.3 unter Raspbian jessie nicht über den apt-Paktemanager zur Verfügung steht und zum Anderen der lua Paaketmanager luarocks aus dem jessie Repository gar auf Lua 5.1 aufbaut. Mit dem Wissen musste ich Lua 5.1 verwenden und einfache Operationen mit Hilfsmitteln umsetzen.

Installation:

sudo apt-get update
sudo apt-get install lua5.1

Es gibt einen Paketmanager für Lua namens luarocks – dieser erlaubt die Installation von  zusätzlichen Komponenten (rocks) auf einfache Weise, vor allem wenn diese noch weitere Abhängigkeiten haben. Unter anderem kann damit die Bibliothek lua-periphery für die SPI Steuerung installiert werden – man soll sich das Leben ja nicht unnötig schwer machen.

sudo apt-get luarocks
sudo luarocks install lua-periphery

Es gibt in Lua keinen Befehl wie sleep für eine blockierende Pause und es gibt auch keinen einfachen Weg eine Pause im Millisekunden-Bereich mit Sprachmitteln zu implementieren. Freundlicherweise stellt die lua-periphery Bilbliothek die nützlichen Funktionen sleep, sleep_ms und sleep_us zur Verfügung.

-- rainbow.lua
periphery = require("periphery")

local LED_COUNT = 30
local DELAY = 40 -- ms

-- open /dev/spidev0.1 (CS1 Pin wird verwendet), SPI mode 0, max 1 MHz
local spi = periphery.SPI("/dev/spidev0.1", 0, 1e6)

-- BOOSTER_INIT mit der Anzahl der LEDs und 24 bits pro LED (WS2812)
spi:transfer({0xB1, LED_COUNT, 24})
periphery.sleep_ms(DELAY)

function clear()
	-- BOOSTER_SETRGB 0x000000, BOOSTER_SETALL, BOOSTER_SHOW
    spi:transfer({0xA1, 0, 0, 0, 0xA5, 0xB2})
    periphery.sleep_ms(DELAY)
end

local i = 0
local runs = 200
while runs > 0 do
	i = i + 5
    i = i % 360
    -- BOOSTER_SETRAINBOW HUE (2 Bytes), SATURATION, VALUE, von der ersten (0) bis
    -- zur letzten LED in 10-er Schritten, BOOSTER_SHOW
    spi:transfer({0xA7, i % 0x100, math.floor(i / 0x100), 255, 100, 0, LED_COUNT - 1, 10, 0xB2})
    periphery.sleep_ms(DELAY)
    runs = runs - 1
end

clear()
spi:close()

Was man auch hier im Vergleich zu der Python Version sehen kann: Lua kann nativ keine KeyEvents verarbeiten. Evtl. gibt es auch dafür eine Bibliothek, ich habe mich jedoch hier einfach auf eine feste Anzahl von Durchläufen beschränkt.
Wie schon erwähnt kann Lua 5.1 keine Bitwise Operatoren – daher wurden die Operationen i & 0xFF und i >> 8, um den Hue Wert auf 2 Bytes zu verteilen als i % 0x100 und math.floor(i / 0x100) umgesetzt.

Zum Starten von der Konsole aus lua rainbow.lua eingeben.

Fazit: wie man sieht, ist es auch mit Lua ziemlich einfach SPI zu nutzen. Die lua-periphery Bibliothek kann auch noch einiges mehr ansteuern: GPIO, SPI, I2C, MMIO, Serial. Es gibt sogar Python und C-Versionen davon, die ich mir evtl. auch noch anschauen werde.

Nach Python und Lua hat mich die Neugier gepackt und ich habe mir die Frage gestellt, wie der SPI Bus mit JavaScript gesteuert werden kann. Auch hier war die Voraussetzung, dass es bereits eine passende Bibliothek dafür geben muss. Von JavaScript sollte schon mal jeder im Zusammenhang mit seinem Browser auf dem Rechner gehört haben. JavaScript eignet sich aber nicht nur zum Erstellen hochdynamischer interaktiver Webseiten, sondern auch für den Einsatz im Backend auf der Serverseite und muss sich bei Performance-Messungen nicht hinter den nativen Implementierungen verstecken. Auch für die Hardwaresteuerungen existiert eine Vielzahl an Modulen.

Als Laufzeitumgebung kommt Node.js zum Einsatz. Es hat bereits einen integrierten Paketmanager und erlaubt die Suche und Installation von zusätzlichen Modulen auf einfache Weise. So ergab auch die Suche nach dem passenden Modul für die SPI Steuerung mehrere Treffer. Das Projekt node-rpio verspricht dabei 1000x schneller als seine Alternativen zu sein, weil es kein einfacher Wrapper für die Zugriffe auf die jeweiligen Treiber ist, sondern direkt mit den GPIO Schnittstelle arbeitet. Außerdem kann sie auch GPIO, PWM und i2c. Das klang vielversprechend, also habe ich mir die Bibliothek angeschaut. Dabei kam heraus, dass eben wegen ihrer „Direktheit“ die Programme Root Rechten benötigen und die Ansteuerung vom ChipSelect manuell durchgeführt werden muss. Im Normalfall übernimmt das der Linux SPI-Treiber selbst. Ich wollte die Einfachheit des Codes der anderen Beispiele beibehalten und habe mir dann noch pi-spi und node-spi angeschaut, die als Wrapper um /dev/spidev implementiert sind. Beide haben eine ähnliche API, wobei pi-spi asynchron und node-spi blockierend funktioniert. Mit beiden konnte ich den Digi-Dot-Booster steuern, für das Beispiel habe ich mich für node-spi entschieden, weil die write Funktion keine Callback Funktion erwartet.

Installation:

Die Installation unter Raspbian ist etwas umfangreicher als bei Python und Lua. Das hängt damit zusammen, dass die Debian Pakete teilweise veraltet sind und es später zu Problemen bei der Installation der SPI Bibliothek kommt.

sudo apt-get update
sudo apt-get install nodejs npm nodejs-legacy
sudo npm -g install npm

Nachdem Node.js und sein Paketmanager installiert sind, wird über npm als Erstes npm selbst auf den aktuellen Stand gebracht. Das Paket nodejs-legacy in der Liste oben erstellt einen symbolischen Link für nodejs, damit es per node aufgerufen werden kann. Ohne den Link hatte ich Fehler bei der Installation von Node.js Modulen.

Mit dem Paketmanager werden nun die Bibliothek node-spi zur SPI Ansteuerung und das sleep Modul für das blockierende Warten mittels sleep und usleep installiert. node-spi wird in der Version 0.1.2 installiert, da das installierte Node.js aus dem Raspbian Repository in der Version 0.10.29 vorliegt,  node-spi in der aktuellen Version jedoch erst ab 0.12.x funktioniert. Die Module werden bewusst lokal und nicht global installiert – da gab es im Laufe der Tests auch etliche Probleme.

npm install spi@0.1.2
npm install sleep

Nachdem die Vorbereitungen nun endlich abgeschlossen sind, kommt der Spaß am Programmieren – der obligatorische Regenbogen…

var SPI = require('spi');
var sleep = require('sleep');

var LED_COUNT = 30
var DELAY = 40 * 1000 // in microseconds

var spi = new SPI.Spi("/dev/spidev0.1");
spi.maxSpeed(1e6);
spi.open();

function initLEDs () {
	var cmd = new Buffer([0xB1, LED_COUNT, 24]);
	spi.write(cmd);
	sleep.usleep(DELAY);
}

function clear() {
	var cmd = new Buffer([0xA1, 0, 0, 0, 0xA5, 0xB2]);
	spi.write(cmd);
	sleep.usleep(DELAY);
}

initLEDs();

var i = 0;
var runs = 200;
var cmd = new Buffer([0xA7, 0, 0, 255, 100, 0, LED_COUNT - 1, 10, 0xB2]);
while (runs > 0) {
    i += 5;
    i = i % 360;
	cmd[1] = i & 0xFF;
	cmd[2] = i >> 8;
	spi.write(cmd);
	sleep.usleep(DELAY);
    runs = runs - 1;
}

clear();
spi.close();

Fazit: Als ich mit Lua nach den Erfahrungen mit Python bereits innerhalb weniger Stunden ein Erfolgserlebnis hatte, hatte ich bei JavaScript keine größeren Probleme erwartet. Es hat sich jedoch gezeigt, dass allein die Einrichtung von Node.js unter Raspbian viele Stunden kosten kann. Die Suche und Tests der geeigneten SPI Bibliothek hat ebenfalls einige Zeit in Anspruch genommen. Der Code selbst hat mir dagegen keine großen Probleme bereitet.

Nach erfolgreichen Versuchen mit dem Digi-Dot-Booster am Raspberry Pi, habe ich mich nach weiteren Plattformen umgeschaut, die mit wenig Aufwand zu schnellen Ergebnissen führen würden. Nach kurzem Durchwühlen der Bastelkiste kam ein STM32 Nucleo Board zum Vorschein. Das interessante bei diesem Board ist, dass es bereits für die ARM mbed Plattform vorbereitet ist. Die Webseite stellt einen Online Code Editor mit C/C++ Compiler  inklusive zahlreicher Bibliotheken für den Zugriff auf die Schnittstellen zur Verfügung – optimal für einen schnellen Test ohne eine komplette Entwicklungsumgebung aufsetzen zu müssen. Also kam das Board aus der Kiste auf den Arbeitstisch zum Experimentieren…

Ich habe hier das Nucleo F303RE Board für die Anleitung verwendet, es sollte aber grundsätzlich auch mit anderen Plattformen mit mbed Unterstützung funktionieren. Der Programmcode kann im Prinzip in jedem aktuellen Browser auf jedem Betriebssystem geschrieben werden. Nach dem Kompilieren wird das Binary einfach zum Download angeboten – die Datei legt man dann auf dem Wechsellaufwerk ab, welches nach dem Anschluss des Nucleo Boards am Rechner erscheint. Das Board erkennt die neue Datei, der Flash wird damit automatisch programmiert und das Programm dann ausgeführt.

Angeschlossen wird der DD-Booster an die Arduino Pins. Erfreulicherweise sind diese direkt auf der Platine beschriftet, beim DD Booster ist ein Blick in die Dokumentation notwendig (Beschriftung auf dem Board würde dem BB-Booster auch gut tun. Update: laut Folker kommt die Beschriftung auch).

Für die Nutzung des Online Compilers ist die kostenlose Registrierung erforderlich. Nachdem das erledigt ist, kann man sich dort anmelden und bekommt einen leeren Codeeditor zu sehen.

Leerer Code Editor

Bevor man mit dem Programmieren anfangen kann, muss eine Plattform ausgewählt werden. Das geht über die Schaltfläche „No device selected“ rechts oben.

Eigene ausgewählte Plattformen

Nach der Erstanmeldung wird die Liste zuerst leer sein, später werden dort alle eigenen mbed Plattformen erscheinen, zwischen den man einfach umschalten kann. Zuerst soll das Nucleo Board hinzugefügt werden. Dazu klickt man auf den Button „Add Platform“ unten links. Man wird daraufhin auf die Seite mit den unterstützten Boards weitergeleitet.

Die Liste der Boards mit mbed Unterstützung ist recht groß. STM32 Nucleo Boards sind auch dabei.

Nach der Auswahl des Boards kommt man zunächst auf die Seite des Boards mit umfangreichen Informationen und Hinweisen.

Mit dem Klick auf den Button „Add to your mbed Compiler“ wird diese Plattform zu der Liste hinzugefügt. Übrigens: falls man später eine Plattform aus der eigenen Liste entfernen möchte, muss man das ebenfalls über diese Seite tun und nicht im Compiler selbst.

Zurück im Compiler wird direkt ein neues Projekt erzeugt und zur Auswahl werden unterschiedliche Templates angeboten. Wir fangen mit einem leeren Projekt („Empty Program“) an und vergeben einen aussagekräftigen Namen für das Projekt.

Neu hinzugefügte Plattform wird für das erste Projekt verwendet.

Wir legen nun eine neue Datei über den Rechtsklick auf den Projektordner im Workspace auf der linken Seite an.

Das leere Projekt enthält wie erwartet keine Dateien.

Die Datei bekommt ebenfalls einen Namen – rainbow.cpp in diesem Fall.

Für der Regenbogen habe ich diesen Code geschrieben, der direkt im Editor eingefügt werden kann. Der Code ist an die bisherigen Beispiele angelehnt mit dem Unterschied, dass die ChipSelect Leitung nun manuell getriggert werden muss.

#include "mbed.h"

SPI device(SPI_MOSI, SPI_MISO, SPI_SCK);
DigitalOut cs(SPI_CS);

#define LEDS 30

void initSPI()
{
    cs = 1;
    device.format(8,0);
    device.frequency(10000000);
}

void initLEDs()
{
    cs = 0;
    device.write(0xB1);
    device.write(LEDS);
    device.write(24);
    cs = 1;
    wait_ms(40);
}

int main()
{
    uint16_t i = 0;
    initSPI();
    initLEDs();
    while(1) {
        i += 5;
        i = i % 360;
        cs = 0;
        device.write(0xA7);
        device.write(i & 0xFF);
        device.write(i >> 8);
        device.write(255);
        device.write(100);
        device.write(0);
        device.write(LEDS - 1);
        device.write(10);
        device.write(0xB2);
        cs = 1;
        wait_ms(40);
    }
}

Obligatorisches Rainbow Beispiel.

Beim Click auf „Compilieren“ bekommt man einen Fehler. Der Grund ist klar – es wird eine Header Datei mbed.h importiert, weil wir die Funktionen der mbed Bibliothek für den Zugriff auf die SPI Schnittstelle verwenden wollen, im Projekt ist jedoch nicht definiert, wo diese zu suchen ist. Praktischerweise gibt es neben der Fehlermeldung den „Fix it“ Button.

Es fehlt noch etwas…

Beim Klick darauf, versucht die Entwicklungsumgebung die fehlende Bibliothek selbst zu finden – mit Erfolg wie man sieht.

Die richtige mbed Bibliothek wird gefunden.

Der erste Treffer ist der richtige – auswählen und mit OK bestätigen. Daraufhin erscheint eine Referenz im Projekt darauf und das Kompilieren geht nun ohne Probleme. Die Datei speichert man direkt auf dem vom Nucleo Board im System erstellten Wechseldatenträger ab.

Erfolgreich kompiliert und zum Download angeboten.

Das war’s! Das Nucleo Board übernimmt das Programm, macht einen kurzen Reset und lässt die LEDs in Regenbogen-Farben leuchten.

FAZIT: Mit dem „mbed Compiler“ kann man ebenfalls recht schnell Erfolge haben. Man kann dabei nicht nur auf die offizielle mbed Bibliothek zugreifen, sondern auf viele andere, die aus der mbed Community kommen. Der Nachteil ist der fehlende Debugger – möchte man Schritt für Schritt den Code analysieren und die Werte der Variablen prüfen, muss man auf die lokale Entwicklungsumgebung umsteigen.

Nach all den Experimenten mit  dem Digi-Dot-Booster am Raspberry Pi und dem STM32 Nucleo Board war irgendwann klar, dass auch an Arduino kein Weg vorbei führt. Auf der Produktseite vom Digi-Dot-Booster gibt es schon viele Beispiele für die Arduino Plattform, mit der man schnell verschiedene Effekte zauben kann. Dann habe ich einen genauen Blick auf den Code geworfen und sah da Ver­bes­se­rungs­po­ten­zi­al. So ist die Arduino DD-Booster-Library entstanden.

Die Arduino Plattform soll vor allem Neulingen die Programmierung von Mikrocontrollern erleichtern. Die Arduino Programme (Sketches) haben eine einfache Struktur: die Funktion setup() dient der Initialisierung beim Start und die Funktion loop() ist der Körper des Programms – eine Schleife, die periodisch aufgerufen wird.

So sollen im Sketch nach Möglichkeit auch nur die wichtigsten Ausdrücke stehen, die den Ablauf des Programms bestimmen, und alles andere kann in eine Bibliothek ausgelagert werden. Genau das wird mir der DD-Booster-Library erreicht.
Die Bibliothek kapselt die ganze SPI Bus Kommunikation inkl. dem Datenprotokoll mit dem Digi-Dot-Booster und stellt für die Steuerung einfache Funktionen zur Verfügung.

Der Anschluss ist bereits im Datasheet vom Digi-Dot-Booster dokumentiert und sollte daher keine Probleme bereiten.

Die Bibliothek kann direkt über den eingebauten Library Manager installiert werden.

Der Library Manager ist über Sketch/Include Library/Manage Libraries… erreichbar

Im Sucheingabefeld dd-booster eintippen, in der Liste den Eintrag auswählen und per „Install“ Button die Installation einleiten.

Der Code der Bibliothek liegt auf GitHub. Dort ist ebenfalls die Dokumentation abgelegt. Verbesserungen, neue Beispiele oder sonstige Anmerkungen sind wie immer willkommen.

Neben der Kapselung der Befehle, die der DD-Booster unterstützt, enthält die Bibliothek weitere nützliche Funktionen. Die oft gebrauchten Funktionen clearLed() und clearAll schalten eine LED bzw. alle LEDs aus, in dem sie die Farbe auf RGB(0,0,0) setzen. Die Funktion setGradient() berechnet und setzt einen Farbverlauf zwischen zwei LEDs von einer Farbe in die andere. Mit dieser Funktion ist das Beispiel WaterDrop umgesetzt.

Die Verwendung der Library ist recht einfach und gut dokumentiert, hier folgt auch eine kurze Anleitung dazu anhand des Blinker-Beispiels. Das TurnSignal Beispiel kann nach der Installation der Bibliothek direkt aufgerufen werden.

Für die Steuerung des Digi-Dot-Boosters wird zunächst ein Objekt der Klasse DDBooster erzeugt. Dabei wird die SPI Schnittstelle initialisiert und auf 12 MHz, MSB first, mode 0 eingestellt. 12 MhHz ist der maximal mögliche Wert und je nach Arduino Version wird von der Plattform automatisch entschieden, ob dieser Wert erreicht werden kann. Ansonsten wird der jeweils mögliche niedrigerer Wert gewählt.

#include <DDBooster.h>

// create booster object
DDBooster booster;

void setup() {
}

void loop() {
}

Standardmäßig verwendet die Bibliothek den SS Pin der SPI Schnittstelle für die Steuerung der ChipSelect Leitung. Falls jemand einen anderen digitalen Pin dazu verwenden möchte, kann mit der Funktion configurePins() die Bibliothek entsprechend konfigurieren. Der erste Parameter legt dabei den neuen ChipSelect Pin fest, der zweite definiert welcher Pin für einen Hardware Reset des DD-Bosoters mittels der Funktion reset() verwendet wird. Dazu muss der entsprechende digitale Pin mit dem RESET Pin des DD-Boosters verbunden werden. Ohne explizite Zuweisung des Pins für den Reset hat der Aufruf von reset() keine Auswirkung.

Als Nächstes muss dem DD-Booster mitgeteilt werden, wie viele LEDs er ansteuern soll – gültig Werte sind von 0 bis 256. Das wird mit der Funktion init() gemacht. Für das Beispiel werden 20 LEDs auf einem ws2812 Stripe festgelegt. Zuvor werden global noch zusätzliche Variablen definiert: led_count für die Anzahl der LEDs, index für die aktuelle Position der angesteuerten LED und color definiert die zu verwendende Farbe. Nach dem init() Aufruf werden alle LEDs ausgeschaltet, um einen „sauberen“ Stand zu haben. Das wird mit den Funktionen clearAll()und show() erreicht. Die Methode show()spielt eine große Rolle, denn erst nach ihrem Aufruf werden alle vorherigen Änderungen auch übernommen und die LEDs letztendlich angesteuert. Letzte Zeile in der setup() Funktion setzt für die nachfolgenden Aufrufe die zu verwendende Farbe der LEDs.

#include <DDBooster.h>

// create booster object
DDBooster booster;
// we have 20 leds
int led_count = 20;
// we start with the first led
int index = 0;
// this color will be used for the turn lights
byte color[] = {0xFF, 0xBB, 0};

void setup() {
  // tell the booster about the number of leds
  booster.init(led_count);
  // turn all leds off to have a clear state
  booster.clearAll();
  booster.show();
  // save the color we want to use in the color buffer
  booster.setRGB(color[0], color[1], color[2]);
}

void loop() {
}

Die ganze „Magie“ passiert nun in der loop() Funktion. Bei jedem Aufruf wird jeweils für eine LED an der aktuellen Position die Farbe gesetzt und per show() zur Anzeige gebracht. Danach wird untersucht, ob die aktuelle Position der letzten Stelle in der LED-Reihe entspricht. Bei 20 LEDs wäre das 19, da die Zählung immer mit 0 beginnt. Falls das der Fall ist, wird der Index wieder auf 0 (die erste LED) zurückgesetzt und alle LEDs ausgeschaltet. Zusätzlich wird eine Pause von 500 Millisekunden zwischen der Durchläufen eingelegt. Da die Funktion clearAll() intern die Farbe auf RGB(0,0,0) setzt, um alle LEDs auszuschalten, muss das Farbregister des DD-Boosters erneut mit der richtigen Farbe befüllt werden. [An der Stelle wäre es wahrscheinlich sinnvoll, wenn die Bibliothek das Wiederherstellen des Farbregisters nach dem Aufruf der clear-Methoden automatisch selbst macht. Das wird für die nächste Version angepasst.]
Und falls die aktuelle Position das Ende nicht erreicht hat, wird sie einfach um eins erhöht, damit beim erneuten loop-Durchlauf die nächste LED gesetzt wird. Eine Pause von 10ms am Ende legt fest wie schnell der Blinker blinkt.

#include <DDBooster.h>

// create booster object
DDBooster booster;
// we have 20 leds
int led_count = 20;
// we start with the first led
int index = 0;
// this color will be used for the turn lights
byte color[] = {0xFF, 0xBB, 0};

void setup() {
  // tell the booster about the number of leds
  booster.init(led_count);
  // turn all leds off to have a clear state
  booster.clearAll();
  booster.show();
  // save the color we want to use in the color buffer
  booster.setRGB(color[0], color[1], color[2]);
}

void loop() {
  // we always set one led per loop run
  booster.setLED(index);
  booster.show();

  // if we arrive the last led, reset all and wait a little bit
  // if not increment index to go set next led on next loop run
  if (index == led_count - 1) {
    index = 0;
    booster.clearAll();
    booster.show();
    delay(500);
    // set the color back
    booster.setRGB(color[0], color[1], color[2]);
  } else {
    index++;
  }

  // control the speed of the turn light
  delay(10);
}

Mit der Bibliothek werden zwei Beispiele mitgeliefert: WaterDrop und das gerade besprochene TurnSignal. Künftig sind weitere Beispiele und evtl. auch Funktionen geplant. Die Aktualisierung geschieht dann einfach über den Library Manager der Arduino Entwicklungsumgebung.

Zum Schluss noch die beiden Beispiele als Videos.

Es war einmal im Dezember 2014, also lange, lange her, da kam mir die Idee, sechs unserer frisch produzierten WS2812 8x8HD-Panels zu einem Leuchtwürfel zusammenzusetzen. Gedacht getan – mit Plexiglas so eine Art Unterbau konstruiert und dann mittels gemeiner Abstandshalter untereinander verstrebt. Einen LiPo-Akku 850Ah, einen CMOS-Switch und einen LED-Player-S genommen, zusammengeschaltet fertig war die Hardware. Mit Jinx! habe ich noch ein paar schöne Effekte zusammengestellt und auf SD-Card gespeichert. Die Diamex-Panels eigen sich für einen solchen Aufbau sehr gut, weil aufgrund der rhombenartigen Anordnung der LEDs (um 45 Grad gedreht) Zwischenräume für M3 Befestigungen möglich sind. Kein anderes LED-Panel hat diese äußerst nützliche Eigenschaft. Man kann also ohne Gehäuse arbeiten, was einen ganz besonderen, reizvollen Effekt ergibt. Das Teil habe ich herumgezeigt und nach einer ganzen Zeit Betrieb fragte Jemand „mit was für einer Energiequelle läuft das Ding?“. Mir rutschte in diesem Moment heraus „Atomkraft – Polonium!“.  Seither ist das der Polonium-Cube.

 

Der Cube misst 70x70x70mm. Es existiert schon ein viermal so großer Prototyp (140x140x140) – derzeit als Disco-Würfel eingesetzt. An einem kleinen Exemplar (50x50x50) arbeite ich gerade. Gerne würde ich mal einen Cube mit 6x 256er Panels bauen, da gibts aber noch ein paar kleine Hürden, das wären 1536 LEDs, die sind nativ nicht ansteuerbar. Der neue Player-S wird 1024 LEDs können oder man nimmt einen Player-M (2048 LEDs). Dann noch die Stromversorgung (ggf. ein Bleiakku) und die Wärmeentwicklung. Aber da ist ja noch Zeit…

Also, lange hats gedauert, bis ich mich durchringen konnte mal eine Doku und eine Bauanleitung zu filmen, fotografieren und darüber zu schreiben. Aber nun zur Sache:

Das Teil hat vier 8x8HD-Panels, also insgesamt 384 LEDs. Ansteuerbar alle hintereinander oder drei Panels signal-parallel. Meine Installation hat vier Seiten hintereinander (256 LEDs) und die Stirnseiten parallel & hintereinander zum Signaleingang. Für den Aufbau braucht man 1-2 Stunden, ggf. auch etwas mehr.
Der Strombedarf liegt bei etwa 650 mA, das ist datenabhängig – gemessen mit den Demodaten. Man kann eh nur mit 20% Helligkeit fahren, sonst ist das Teil gleißend hell und kein Hingucker mehr. Der Akku (850mAh) reicht dann etwa 25-30 Minuten. Schaltet man zwei der gleichen Sorte(!!!) parallel, dann kann man etwa anderthalb Stunden erreichen. Grund ist, dass ein Akku ab einer bestimmten Spannungsswelle abschaltet, dann hat der aber noch recht viel Energie. Bei mehreren Akkus bleibt diese Basis gleich wärend sich die Energie verdoppelt. Es kann also mehr Energie genutzt werden.

Den kompletten Bausatz gibt es hier. Der Komplettpreis ist deutlich billiger als die Einzelkomponenten und man hat alle benötigten Bauteile passend und komplett. Zugegeben, immer noch ein teurer Spaß, aber absolut außergewöhnlich und für die Umwelt frappierend. Wenn man genug davon hat, kann man das Teil auseinanderschrauben und die Panels und den Player ja andersweitug verwenden…
Also ausprobieren!

Benötigt werden

• 6 x 8×8-HD-Panels
• 1 x LED-Player-S + Micro-SD-Card
• 1 x CMOS-Switch
• 1 x LiPo-Akku 850mAh (für die dreifache Standzeit  zwei Stück)
• 24 x Anschlusssatz, bestehend aus Schraube M3x6, M3 Mutter, M3 Zahnscheibe und M3 Lötöse
• 6 x Satz Abstandshalter, bestehen aus je 2x  12x 5,5; M3 innen/außen, 1 x 40×5,5; M3 2x innen, je 2x M3x6 Schraube
• 6 x Plexiglaszuschnitte, klar, 3mm XT für den Innenkorpus
• 2 x Anschlusskabel für Akku
• etwas Schaltlitze

Der Aufbau

Projektdaten (Laserschnitt):
Polonium-Cube-Data

Zuerst nimmt man die Acryl-Zuschnitte und legt sie genauso so, wie im nachfolgenden PDF, vor sich hin:

digi-dot-cube Anordnung

Nun nimmt man die Diamex-Panels und schiebt diese unter die Acrylscheiben so, dass man die Schrift normal lesen kann, also nicht auf dem Kopf stehend und nicht um 90 Grad verdreht. Die Aussparungen auf den Acrylscheiben ergeben nun ein sinnvolles Muster mit den darunterliegenden Panels.

In alle grün umringten Anschlüsse muss ein Anschlusssatz geschraubt werden. Schraube auf der LED-Seite durchstecken, Lötöse innen aufsetzen (zeigt zur Panel-Mitte), Zahnscheibe auflegen, Mutter aufsetzen und gefühlvoll festziehen. Vorsicht! LEDs nicht beschädigen. In die Löcher mit dem X muss kein Anschlussatz rein. Die Aktion 24 mal durchführen.

Jetzt die Abstandshalter zusammensetzen. Aus das 40mm Mittelstück werden rechts und links die 12mm Abstandhalter aufgeschraubt. Eine Seite wird in die  sechseckige Aussparung gesetzt und wiederum mit einer Schraube von der LED Seite festgezogen. Siese Aktion wird 6 mal durchgeführt. Die auf der anderen Seite befindlichen 12mm Abstandshalter nicht ganz fest ziehen, die müssen sich ein klein wenig bewegen können, damit der Würfel am Ende stressfrei zusammengesetzt werden kann – die Teile müssen ja genau auf der gegenüberliegenden Seite passen.

Nun wird verdrahtet:

digi-dot-cube Verdrahtung

Rot ist blau und Plus ist Minus – äh nein – Spaß beiseite…

Rot ist immer der Pluspol
Blau ist immer der Minuspol
Gelb ist die Signalleitung

Bitte die fertig montierten Panels wieder genau wie im PDF anordnen – bündig zusammenschieben.
Dann werden die Brücken sauber gelötet, bitte kurze Drähte, sonst sind die bei der Montage im Weg. Damit man auch später noch nachvollziehen kann, was wohin gehört, bitte auch die korrekten Farben für die Anschlußlitze nehmen.
Am Player sollte man die beiden Pole der Stromversorgung (vom Switch kommend) an die Klemmen anlöten (Unterseite). Die Klemmen sind für zwei Drähte nicht ausgelegt.
Die Batterie erst zuletzt anstecken. Das ist dann gleich der Test. Vorher nochmals und unbedingt die Verdrahtung kontrollieren. Ist nämlich eine der Pole nicht korrekt angeschlossen, dann passiert es leicht, dass die erste LED des Panels im Signaleingang zerschossen wird.  Also lieber nochmal die Stromschienen auf Durchgang messen.

Alle Panels, bis auf das rechte (!) sollten nun kurz weiß aufleuchten. Wenn das klappt, dann ist alles ok. Das rechte Panel bekommt erst Signal wenn der Cube endmontiert ist.

Endmontage:

Zuerst wird der CMOS-Switch eingesetzt.
CMOS-Switch
Die Taster passen in die Aussparung. Mit einer Schraube M3x6 fixieren.

Beginnend mit dem unteren Panel und dem zweiten von oben, die werden auf das mittlere Panel aufgesetzt (90 Grad) und die beiden Streben werden verschraubt. Vorsicht, Drähte nicht einklemmen. Danach das obere Panel aufsetzen. Ggf. ein wenig die Streben richten, dass sie genau in die sechskant Aussparungen der Acrylscheibe passen.

Nun das linke Seitenteil anklappen dazu mit den angeschraubten Streben etwas schräg durch die bereits montierten Abstandshalter durchfädeln.

Fast geschafft. Dem LED-Player spätestens jetzt den Schrumpfschlauch überziehen, die SD-Card einstecken (Demo hier) und vorsichtig in der einen entstandenen Kammer verstauen. Im unteren Teil des Bildes zu sehen. Der Akku passt genau in die andere Kammer, ggf kann man zwei parallel betreiben und erhält etwa die dreifache (!) Leuchtdauer. Es passen genau zwei Akkus nebeneinander. Die Drähte sauber legen und das Panel oben aufsetzen.
Ist etwas fummelig, aber das wird schon    Zum Schluss zuschrauben. Die im Bild letzte Schraube verbindet dann auch das letzte Panel mit dem Signal, sodass jetzt alle LEDs ringsherum angesteuert werden.

Num kann man über die zwei Öffnungen mit einem Schraubenzieher o.ä. den Cube ein- und ausschalten. Am besten man merkt sich wo der Schalter sitzt, denn es ist im Betrieb nicht ganz einfach die Öffnung für „Aus“ wiederzufinden.

Dann viel Spaß mit diesem außergewöhnlichen Partygag.
Folker

Modifizierungen:

Denkbar ist eine Stromzuführung. Selbst mit zwei 850mA Akkus ist nach etwa 1,5 Stunden Schluss. Der CMOS-Switch trennt den Cube zu annähernd 100% von der Stromversorgung. D.h. wenn aus, dann auch kein Stromverbrauch. Man kann also das Teil monatelang liegen lassen und es wird immer noch funktionieren, wenn die Akkus aufgeladen waren. Über eine der Ecken oder Montagelöcher kann man einfach mit Schaltlitze Energie (5V) einspeisen und erhält so einen „Dauerläufer“. In idealer Kombination benutzt man den Diamex LED-WLAN-Player. So kann der DJ das Teil vom PC aus steuern. Geht natürlich auch über USB des LED-Player-S, dann muss man halt schauen, wie man die USB Strippe noch reinführt – ggf. über eine der Montagebohrungen (dazu die Acrylscheiben auch durchbohren).  WLAN ist halt eleganter.

48x48mm klein sind die neuen Mini-Panels mit 8×8 (64) SK6812 LEDs. Hell wie die Hölle und wahrscheinlich die allerersten ihrer Art weltweit. Diamex hat wieder großen Wert auf einfache Montage gelegt. Wie gewohnt sind die Panels auch diesmal nahtlos anreihbar. Zu den Panels liefern wir auf Wunsch die nötigen M2,5 Montageschrauben, Lötösen und Muttern mit. Die Schrauben sind eine Spezialanfertigung. Mit nur 4,5mm Kopfbreite verursachen diese keine Schlüsse an den eng gepackten LEDs. Wenn man also die Panels einsetzen will, sollte man den Schraubensatz mitbestellen, das erspart mit Sicherheit Probleme beim Einsatz. Als Antrieb benötigt man Torx T8 Bits. Gibts preiswert in kleinen Schraubersets.
Natürlich lassen sich die Panels mit allen unseren Playern und Controllern ansteuern – sie sind alle WS2812 kompatibel.
Der  Stromverbrauch der SK6812 ist erfreulicherweise etwa nur halb so groß wie der der WS2812, die Dimension ebenso – statt 5mm Kantenlänge der LEDs nur noch 3,5mm. Die Lichtausbeute ist fast identisch.
Als erste Applikation gibts den kleinen Bruder des Polonium-Cube -> Mini-Cube:
Erstaunlich klein (etwa ein Drittel kleiner) – atemberaubend dynamisch im Farbspiel – leistungsfähig durch kompakte LiPo-Akkus – frei programmierbar. Eine Bauanleitung und auch den Bausatz gibts in Kürze.

Der kleine Bruder des Polonium-Cube, „Mini-Cube“ ist in Kürze lieferbar. Etwa 50x50x50 mm ist das Teil nur klein. Phantastische Lichtspiele ohne PC-Ansteuerung sind mit dem integrierten LED-Player-S möglich. Das ist eines der außergewöhnlichsten Innovationen im Bereich Show-Accessoires. Es geht Laufschrift oder tolle Lichtsequenzen. Zwei LiPo-Akkus je 800mAh ermöglichen eine geschlagene Stunde optischen Spaßes. Das ist bestimmt ein ganz spezielles Einsatzgebiet, aber mit Sicherheit ein ganz ungewöhnlicher Hingucker – der es beileibe „in sich hat“. Viel High-Tech-Entwicklung war nötig um so was zusammenzusetzen. Neueste 3x3mm SK2812-Digi-Dot-LEDs und zweiunddreißig-bittige Controllerchips (ARM-Cortex-M3). Das Ergebnis kann sich wirklich „sehen lassen“. Was für ein Anblick! Der Mensch mit seiner genetisch-biologischen Mustererkennung empfindet mathematisch bewurzelte Lichtstimmungen als äußerst harmonisch und als sehr angenehm. Das ist sicher der Grund dafür, dass symetrische Strukturen – natürlich auch Lichtstrukturen – als schön gelten. Genau diesen Nerv trifft der Mini-Cube mit seinen programmierbaren Möglichkeiten. Es ist einfach überraschend, wie schön LED-Technik geworden ist. Übrigens ist der Mini-Cube softwarekompatibel zum Polonium-Cube. Die Effekte können komplett übernommen werden. 384 digitale Leuchtdioden sind sicher kein billiges Vergnügen, aber ein wirklich toller Hingucker auf jeder Party… und passen Sie auf das Teil auf, Begehrlichkeiten sind schnell geweckt…

Die komplette Bauanleitung folgt in Kürze.

Vor Kurzem habe ich einige esp8266 Module bestellt, um damit bei einer Uhr die Zeit über einen NTP Server zu synchronisieren. Wegen der vielen IO Pins, kompakter Bauform und günstigen Preises habe ich mich für die esp-12e Version entschieden (Inzwischen sollte man zu esp-12f greifen, bei dem die Antenne verbessert wurde). Da ich bis jetzt keine Erfahrung mit diesen Modulen hatte, wollte ich zur Einarbeitung erst mal ein kleines Projekt damit umsetzen. Die Wahl fiel dann aus mehreren Gründen auf den Digi-Dot-Booster.

Zum Einen ist die Ansteuerung sehr einfach über SPI, zum Anderen liefert der Digi-Dot-Booster 3,3V für das esp8266 Modul gleich mit. Zwar kann die Leitung max. ca. 130 mA für die Schaltung liefern, das scheint aber für das WLAN Modul noch ausreichend zu sein.

Das esp8266 Module war mit der AT-Firmware programmiert – eine die mit AT-Kommandos über die serielle Schnittstelle angesteuert wird. Diese ist in ihrem Funktionsumfang sehr eingeschränkt, vor allem dann wenn mehr Logik auf dem Modul selbst ausgelagert werden soll. Als Alternativen sind Arduino und NodeMCU zu erwähnen. Erste erlaubt die Entwicklung gewohnt aus der Arduino IDE heraus, die zweite bringt Support für LUA auf das Modul. Ich habe mich für NodeMCU entschieden, hauptsächlich weil bei der Entwicklung nicht die ganze Firmware gebaut und geflasht werden muss, sondern nur der eigene LUA Script übertragen und ausgeführt wird. Wenn alles stimmt, kann man diesen Script dann endgültig im Flash ablegen. NodeMCU ist „Interaktiv“ und erlaubt schnelles Testen durch die Eingabe der Befehle direkt über die serielle Konsole.

Die Installation von NodeMCU sowie die Kommunikation mit dem Modul erfolgt über die serielle Schnittstelle mit TTL Pegeln (3,3V). Ich habe ein FT232RL basiertes Modul verwendet – unbedingt dabei beachten, dass es auch auf 3,3V Pegel eingestellt wird. Die ersten Tests wollte ich nur mit diesem Board machen und habe die 3,3V vom 3V3OUT Pin abgegriffen, dieser liefert jedoch max. nur 50mA, was zu ständigen Reboots vom esp8266 Modul geführt hat. Zum Betrieb vom esp-12e Modul werden noch die Pins GPIO15 an GND und EN an VCC angelegt. Zum Programmieren des Moduls mit der NodeMCU Firmware wird der Pin GPIO0 an GND gelegt, der Rest wird mit den Tools wie in der Anleitung erledigt.

Beim Anschluss des DD-Booster bin ich auf die nahe liegende Idee gekommen, die beschrifteten Pins des SPI Ports auf der Unterseite zu nehmen. Als es nicht funktioniert hat und ich mich auf die Suche nach dem Grund machte, hat sich herausgestellt, dass an dem Port intern der Flash-Speicher des Moduls hängt. Diese Pins können von extern dafür verwendet werden, direkten mit dem Speicher Chip zu arbeiten. Der zweite SPI Port ist an den Pins GPIO12 – MISO, GPIO13 – MOSI, GPIO14 – CLK, GPIO15 – CS, wobei GPIO15 beim Start des Moduls zur Bestimmung des Boot Modus verwendet wird und normalerweise auf GND liegt. Als Chip Select sollte daher ein anderer freier Pin verwendet werden, bei mir ist es GPIO16 geworden. Nachdem alles neu verdrahtet wurde, hat dann auch alles ohne große Probleme funktioniert.

Zum Entwickeln verwende ich ESPlorer. Es ist recht komfortabel und läuft auch auf dem Mac. Alternativen dazu gib es ebenfalls auf der Projektseite von NodeMCU.

Der Regenbogen aus dem LUA Beitrag kann teilweise wieder verwendet werden. Die API zur Ansteuerung von SPI ist etwas anders und der Chip Select Pin muss ebenfalls manuell getriggert werden.

DELAY = 40
LED_COUNT = 24
cs = 0
spiport = 1

function initSPI()
    gpio.mode(cs, gpio.OUTPUT)
    gpio.write(cs, gpio.HIGH)
    spi.setup(spiport, spi.MASTER, spi.CPOL_LOW, spi.CPHA_LOW, spi.DATABITS_8, 60, spi.HALFDUPLEX)
end

function initLEDs()
    gpio.write(cs, gpio.LOW)
    spi.send(spiport, 0xB1, LED_COUNT, 24)
    gpio.write(cs, gpio.HIGH)
    tmr.delay(DELAY * 1000)
end

function clear()
    gpio.write(cs, gpio.LOW)
    spi.send(spiport, 0xA1, 0, 0, 0, 0xA5, 0xB2)
    gpio.write(cs, gpio.HIGH)
end

initSPI()
initLEDs()

i = 0
runs = 100
tmr.alarm(0, DELAY, tmr.ALARM_AUTO, function()
    if runs == 0 then
        tmr.unregister(0)
        clear()
    else
        i = i + 5
        i = i % 360
        gpio.write(cs, gpio.LOW)
        spi.send(spiport, 0xA7, i % 0x100, math.floor(i / 0x100), 255, 50, 0, LED_COUNT - 1, 10, 0xB2)
        gpio.write(cs, gpio.HIGH)
        runs = runs - 1
    end
end)

Im Beispiel sieht man, wie die für den DD-Booster nötigen Pausen zwischen den SPI Transfers umgesetzt wurden. Der Aufruf von tmr.delay(DELAY * 1000) bewirkt eine 40ms lange blockierende Pause. Das ist an der Stelle nicht kritisch, da sie ein Mal beim Initialisieren der LEDs verwendet wird. Jedoch eine Schleife mit diesem Aufruf, wie im LUA Beispiel für den Raspberry Pi,  würde die gesamte CPU Zeit für sich beanspruchen, ohne dass anderer Code (Netzwerk IO z.B.) je ausgeführt werden kann (das führt auch zu Timeouts in ESPlorer, der während der Ausführung der Schleife keine Antwort vom Modul bekommt). Daher wurde die Schleife durch einen Timer Aufruf ersetzt, der die Callback Funktion mit der Ansteuerung des DD-Boosters alle 40ms aufruft. In den 40ms Pause könnte die CPU andere aufgaben erledigen. Das bedeutet aber auch, dass es nicht garantiert werden kann, dass der DD-Booster exakt in vorgegebenen Intervallen gesteuert wird. Wird in der Pause anderer Code länger brauchen, wird sich auch das nächste Kommando an den DD-Booster verzögern. NodeMCU ist eben kein Echtzeitbetriebssystem… Wer sich wundert, warum GPIO16 im Code mit pin 0 adressiert wird, sollte sich das Mapping der Pins in NodeMCU anschauen.

Das es8266 ist eigentlich für die Kommunikation im WLAN bestimmt, daher wäre der nächste logische Schritt, einen Steuerung des DD-Boosters über WLAN zu realisieren. Mit Hilfe einer simple HTML Seite und einem HTTP Server auf dem esp8266 zum Beispiel. Mit NodeMCU ist es auch recht einfach umsetzbar. Evtl. mach ich das etwas später – momentan konzentriere ich mich auf die Anbindung des Moduls zwecks Zeitsynchronisation…

Mittlerweile sind die neuen 8×8-Panels auf Basis der SK6812 LEDs nachhaltig verfügbar. Es liegt also nahe damit mal etwas zu projektieren. Die Teile haben 48mm Kantenlänge, sind sehr hell und doch etwa 50% stromsparender als die „großen“ 8×8 Panels mit WS2812 LEDs. Einen Würfel (Cube) habe ich damit schon gebaut – Anleitung folgt in Kürze. Aneinandergereiht ergeben die Panels ein schönes Effektdisplay, eine Laufschrift oder Hinweis- bzw. Werbeschild.  Das ist auch bei Tageslicht gut zu erkennen und wirklich schön anzuschauen.

  
Meine Idee war es, das alles möglichst einfach zu halten und nach einigem experimentieren bin ich bei meinem Lieblingsmaterial Acryl geblieben. Das sieht immer toll aus und lässt sich auf einem Lasercutter einfach bearbeiten. Der Entwurf ist wie immer in CorelDraw realisiert – eben eine mächtige 2D Software – für Laserschnitt wie geschaffen. Ich habe also eine Grundplatte entworfen, die DXF-Daten des Panels eingefügt und so ganz einfach die Befestigungslöcher ausgeschnitten. Jedes Panel wird in der Mitte angeschraubt, so entsteht eine Reihe von 4 oder 8 Panels. Gehen natürlich auch sechs, hätte den Vorteil, dass man die richtige Anzahl für einen Cube hat und so zwei Projekte mit den gleichen Komponenten realisieren kann. Die Teile sind ja aufgrund der vielen LEDs nicht eben billig. Denn auch kleine Preise summieren sich da schnell zum Luxusprojekt.

   
Eine Streuscheibe aus speziellem Acryl erzeugt aus einer punktförmigen Lichtquelle (unsere LED) ein aufgefächertes, diffuses Licht. Damit akzentuierte und schön begrenzte Pixel entstehen, benötigt man noch einen Kontrastverstärker. Ich bin nach einigem experiemntieren auf Steckschaum gekommen, das Zeug, wo man DIL-ICs reinsteckt, damit die nicht kaputt gehen, die Beinchen nicht verbiegen und so transportiert werden können. In diesem Schaum scheint viel Kohlenstoff drin zu sein, ist ja auch sinnvoll, so werden statische Spannungen abgeleitet. Kohlenstoff ist nicht nur leitfähig sondern auch schön schwarz. Dieser Steckschaum lässt sich klasse mit dem Laser schneiden. Für jede LED gibts ein Loch, besser gesagt ein Achteck-Loch, das kann ein Plottersystem schneller anfahren. Ein kreisrundes Loch benötigt etwa ein Drittel mehr Zeit zum Schnitt, da gaaaaanz viele Näherungswerte abgefahren werden müssen.

Bei 512 LEDs bzw Löchern summiert sich das kräftig auf. Statt 20 Minuten für kreisrunde Löcher benötigt die Octaeder-Variante nur 13 Minuten reine Schnittzeit. Auch noch ganz schön lange…
Die so entstandene „Kontrastmatte“ wird zwischen LED und Streuscheibe gepackt. Ergebnis ist eine wirklich scharfe und sehr regelmäßige „Pixelung“ der einzelnen LEDs.
Ich habe einige Varianten durchprobiert. Rechteckige (gitterflächige) Anordnung sieht nicht so gut aus. Das liegt einfach daran, dass zu wenig Material stehen bleibt und jede winzige Abweichung – ich rede von 0,1 – 0,05 mm – schon unangenehm sichtbar wird. Außerdem wird der Steckschaum sehr instabil, da zu wenig „Fleisch“ stehenbleibt. Die Octaeder sind optisch die beste Variante, da nahe am Kreis. Hierbei bleibt auch genügend Material für eine ausreichende Wandstärke übrig und die ganze Lochmatte wirkt deutlich robuster. Man darf auch nicht vergessen, dass beim Laserschneiden Hitze entsteht und das Material zusätzlich stresst, dahingehend, dass eine gewisse Schrumpfung auftritt. Bei 8×64, also 512 Löchern in einem schmalen Band, wirkt sich das schon so aus, dass der Steckschaum nicht mehr mit den Led-Matrixen in der Länge überein stimmt. Daher sind diese Schlaufen an den Rändern, die einfach über die Spacer gestülpt werden und das Schaum-Material wieder auf die richtige Länge ziehen. Das Ganze ist am Ende so fehlertolerant, dass selbst eine nicht ganz plane Steuscheibe keine negativen Auswirkungen auf den Betrachter hat. Einfach aber effektiv.
Angesteuert wird mit einem LED-PLayer-S, geht natürlich auch der Matrix- oder der WLAN-Player. Der LED-Player-S hat den Vorteil, dass man die via Jinx! erstellten Files auch autonom abspielen kann (SD-Card). Als Energiequelle verwendet man einen LiPo-Akku – 1000mAh reichen schon um eine gewisse Zeit zu „spielen“. Eine USB-Powerbank ist natürlich besser und lässt sich auch gleich an den LED-Player-S per USB anstöpseln. Mit Jinx! erstellt man dann die gewünschten Effekte oder Laufschriften, Werbebotschaften – was auch immer.

Die Montage ist einfach. Die Grundplatte hält die Spacer, auf denen die Panels aufgeschraubt werden. Pro Panel eine Schraube. Eine wichtige Besonderheit: Es handelt sich um M2,5 Schrauben, Lötösen, Muttern und Zahnscheiben. Diese Teile sind im Baumarkt eher nicht zu bekommen. Im guten Schraubenhandel sicher, allerdings nicht gerade billig. Besser man ordert diese Materialen gleich zum Panel dazu, das dürfte erheblich stressfreier sein als selbst auf die Suche zu gehen. Nachdem die Panels richtungsgenau montiert sind (ggf müssen die Abbruchkanten der Nutzenstege etwas mit einer feinen Feile geglättet werden), wird die Rückscheibe aufgesetzt und verschraubt. Vorher sollten die Panels natürlich mit den Lötösen bestückt worden sein. So kann man nun die Betriebsspannung von Panel zu Panel schleifen, indem man nur einen Lötpunkt auf die Lötösen setzt. Gleiches gilt für die Signalleitung. Zuletzt wird der Player angeschlossen. Eine Powerbank mit dem Player verbunden und die SD-Card mit den Beispieldaten eingesteckt. Funktioniert alles? Na prima!

Ich glaube, das dürfte eines der LED-Displays sein, die mit einem sehr geringem Aufwand, arbeitsmäßig und auch materiell, erstellt werden können und trotzdem eine profimäßige Anmutung vermitteln.

Es war einmal ein Träumer, der wollte seinen Lieben zur Vermählung ein ganz besonderes Geschenk machen. Es sollte ein großes Herz sein, das, wenn man es öffnet wunderschön die Widmung „Patricia & Stefan“ farbig illuminiert und dem Hochzeitspaar ein unvergessliches Geschenk sein würde…

Schmalz schmacht schluchz…

Ja, so beginnt die Geschichte – oder auch nicht. Fakt ist, ich bekam einen Anruf aus dem fernen Sachsen und man fragte, wie man denn in einer Holzkiste, die zufällig wie ein Herz aussieht, eine LED-Illumination einbaut, die eine Widmung beleuchtet.
Nachdem der Anrufer seine Vorstellung geäußert hatte, haben wir am Telefon uns recht schnell verständigen können, was denn daraus werden könnte. Ich fand die Idee so cool, dass ich diese Umsetzung hier gerne vorstellen würde. Die Hochzeit ist erst im Juli 2016 – also bitte liebe Leser – noch nichts Patricia und Stefan verraten!!! Dankeschön!

Nun zum Projekt:

Die Herz-Holzkiste (Herzbox groß 15x13x6,5cm) ist hier gekauft: http://www.ebay.de/itm/252347306495

LED-Player-S
8×8-Panel

Die Box habe ich auf einen Scanner gelegt und eingelesen. Das Bild wird in CorelDraw blitz-vectorisiert. Wer sich mit Corel auskennt hat damit keine großen Probleme einen genauen, vectorisierten Umriß zu erhalten (gelb).

Der Umriß wird gespiegelt – und kann nun als genau passende Vorlage verwendet werden.
Die gelieferte Widmung wird übertragen, zentriert und gespiegelt. Für einen Lasercutter ist es kein Problem die Scheibe zu gravieren und zu schneiden. Verwendet wird ein spezielles Plexiglass, was LED-Licht zerstreut ohne viel davon zu absorbieren. Um die gravierte Streuscheibe zu montieren benötigt man noch einen Rahmen. Im Bild links ist die Grundplatte abgebildet Mittig sitzt ein Abstandshalter (Spacer), der aus zwei Teilen besteht. 5mm von der Grundplatte bis zum Panel und 25mm von Panel zur Streuscheibe.

In der Grundplatte sind Ausparungen (grün) für den LED-Player-S und dem Li-Po-Akku ausgeschnitten. Die beiden Teile werden einfach mit Tesafilm fixiert.

Ein Microschalter wird beim Öffnen betätigt und schaltet den Akku an den LED-Player-S. Das Panel kann nun leuchten. Natürlich muss man hier etwas Feinarbeit betreiben. Die Herzbox wird mit einem bereits eingebauten Magneten verschlossen. Leider ist der ziemlich schwach und kann nur mit Mühe gegen den Kontakt halten.

Die Verkabelung ist kinderleicht: Akku Masse zum LED-Player-S, Akku-Plus zum Microtaster, Plus vom Microtaster zum LED-Player-S, drei Leitungen vom LED-Player-S zum 8×8-Panel – fertig. Den Lipo-Akku kann man mit einer kleinen Ladeschaltung an jedem USB-Port aufladen (auch Handynetzteil oder Powerbank).

Die Grundplatte mit den Komponenten legt man nun einfach in die Box und schraubt mit einer Polycarbonatschraube (die ist klar durchsichtig) die Streuscheibe fest.

Der Aufbau ist recht einfach – wie man schon oben gesehen hat. Auf SD-Card ist eine kleine Sequenz gespeichert. Diese ist mit Jinx! erstellt  und sieht schön bunt aus. Alles in allem sicher eine außergewöhnliche Idee – danke nochmal an den Anrufer, der hier anonym bleiben wird 

Und natürlich unbekannterweise an Patricia & Stefan alle guten Wünsche und möge Eure Ehe vom Glück erfüllt sein und so wie die Herzbox (hoffentlich) ewig halten!

Dank dem User phildittrich (Github) gibt es eine kleine Aktualisierungen der Digi-Dot-Booster Library für Arduino. Er hat sich das Datenblatt genauer angeschaut 👍 und die Wartezeiten nach dem Senden der Daten an den Booster optimiert. Danke an der Stelle dafür.

Ein kleine Änderung gab es zusätzlich bei der Funktion configurePins. Der zweite Parameter resetPin ist jetzt optional, falls man nur den ChipSelect Pin ändern möchte, der Reset Pin des DD-Boosters aber nicht verwendet wird.

Die Aktualisierung geht wie gewohnt über den Library Manager der Arduino IDE.

Nach der Aktualisierung liegt die Bibliothek dann in der Version v1.0.1 lokal vor.

Es ist Vorweihnachtszeit, überall sind bunte Lichterketten zu sehen, die außerdem auch noch blinken und allerlei Effekte zaubern. Das sieht meistens recht beeindruckend und schön aus, so ist es dann auch passiert, dass meine Ehefrau unsere Fenster dieses Jahr auch „verschönern“ wollte, und hat mich mit dieser Aufgabe beauftragt…

Eine weiße LED-Lichterkette und eine mit bunten Effekten wurden schnell auf ebay bestellt und 2 Tage später geliefert. Die klassische weiße LED Lichterkette mit kalt-weißem Licht fand ihren Platz draußen, die mehrfarbige mit Effekten drin am Fenster. Die 8 Effekte waren bescheiden, der „Stroboskop“ hat beim Zuschauen mehr Kopfschmerzen verursacht als Weihnachtsstimmung verbreitet. Mir war dann klar, dass muss viel besser gehen!

In der Bastelkiste nachgeschaut fand sich ein langer Strang aus 50 WS2812 LEDs – einzeln auf eigener Platine per dickem Kabel miteinander verlötet (Vor langer Zeit für die Montage hinter dem Fernseher bestellt). Das war schon mal nicht schlecht, den Digi-Dot-Starter dran geklemmt und fertig ist eine Lichterkette mit mehrerer Effekten. Aber…

Aber der Ehrgeiz war schon geweckt – das war zu einfach und zu unflexibel. Es geht bestimmt besser – mit individuellen Effekten, Fernsteuerung usw. Und mir war dann klar – es muss eine LED Matrix fürs Fenster sein, die nicht nur Effekte abspielen kann, sondern Texte und evtl. einfache Bilder anzeigen kann. Es sollte den Innenbereich des Fensters abdecken, aber auch nicht zu groß sein – ich habe mich auf eine Fläche von ca. 80×80 cm festgelegt. Nächstes Problem war nun die Frage nach der Wahl der LED Stripes. Der Abstand zwischen den LEDs sollte nicht zu klein sein, um nicht zu viele davon zu haben – es soll ja kein LED Display werden. Bei Folker habe ich LED-Stripes mit 30 LEDs pro Meter entdeckt, was bei Verwendung von 26 LEDs pro Zeile/Spalte insgesamt 676 LEDs bedeuten würde. Das könnte ein super Mini-Display ergeben, ist jedoch zu viel für eine einfache Weihnachtsbeleuchtung. Außerdem entdeckte ich bei einem weiteren Blick in die Bastelkiste 100 einzelne WS2812 LEDs jeweils auf eigenen kleinen runden Platinen.

10×10 Pixel wäre eine gute Auflösung für den geplanten Einsatz dachte ich, also muss man ja NUR die 100 LEDs miteinander verlöten – kann ja nicht schwer sein. Wenn ich’s nur besser wüsste…

Ich habe mir das Leben natürlich auch nicht einfach gemacht und Kupferlackdraht (fand sich in  der gleichen Bastelkiste) genommen (0,20 mm für Masse und Strom, 0,10 mm für die Datenleitung) – die Idee dahinter war, die Verbindungen zwischen den LEDs möglichst unauffällig zu machen. Es hat sich herausgestellt, dass der dicke Draht problematisch zu löten ist. Der Lack verdampfte erst bei einer Temperatur von mind. 450 Grad und hinterließ verkohlte Rückständer auf dem Kupferdraht. Der dünne Draht ließ sich dagegen einigermaßen bei normaler Löttemperatur verarbeiten. Der einzige für mich ersichtliche Weg hier, war den Lack abzukratzen, um dann den Draht zu verlöten, wobei auch da der Lötzinn nicht so recht haften wollte.

Für die Masse und Strom-Leitungen habe ich 2 lange Drähte als eine Art Schiene genommen, und sie dann nach dem Abisolieren an den richtigen Stellen direkt an die LEDs gelötet. Für die Datenleitung ging ich ähnlich vor, wobei dann das kleine Stück zwischen DI und DO auf der Platine einfach mit einem Messer ausgeschnitten wurde. Der Prozess ging nur schleppend voran: das Abisolieren dauerte seine Zeit, die LEDs sind beim Löten immer wieder verrutscht, die Drähte an den Lötstellen mussten mit Flussmittel nachgebessert werden, die Abstände mussten immer wieder nachgemessen und ggf. korrigiert werden.  So hatte ich dann 4 Stunden später die ersten 10 LEDs in eine Reihe gelötet…

Schnelle Kopfrechnung ergab, dass bei diesem Tempo Weihnachten vorbei sein wird und die Familie nichts mehr davon hat. Der Prozess musste optimiert werden! Erste Idee war die Fixierung der LEDs und ein fester Abstand, um sich das Nachmessen zu ersparen. Folker würde jetzt was Schickes aus Plexiglas mit dem Laser Cutter präsentieren, ich musste wieder in die Bastelkiste greifen . Mein Blick fiel auf ein zerlegtes 3,5 Zoll Diskettenlaufwerk. Der Schlitten für Diskettenaufnahme hatte bereits passende Aussparungen und der Abstand war auch fast perfekt. Also etwas verbogen und die Aussparungen an die quadratische Form der LEDs angepasst und fertig war das neue „Werkzeug“.

Nun ging es etwas schneller voran, das Abisolieren konnte gleich auf der fixierten LED Platine gemacht werden und dann gleich verlötet werden. Die Masseleitung habe ich weiterhin an 2 Lötstellen der LED Platine verlötet, die 5V Leitung nur an einer. Die Zeit für einen Strang aus 10 LEDs hat sich auf etwa 1 Stunde verkürzt. Nach 5 Strängen und vielen vielen weiteren Stunden/Tagen habe ich meine Idee mit der LED-Matrix bereits verflucht…

Jeder Strang wurde nach und nach mit den anderen provisorisch verbunden und immer wieder mit dem Digi-Dot-Starter getestet. Manchmal musste dann auch nachgelötet werden. Als „nur noch“ 20 LEDs übrig waren, machte ich mir Gedanken über die Fixierung des Ganzen am Fenster. Die Stränge sollten von oben nach unten verlaufen im Schlangen-Muster, um die Verbindungen straff und kurz zu halten. Neben der Bastelkiste standen 2 schmale Holzleisten, die nun oben und unten für nötige Fixierung sorgten sollten. Außerdem könnte man danach die LED-Matrix einfach zusammenrollen. Die Abstände wurden ausgemessen, um möglichst gleichmäßige Verteilung der LEDs zu gewährleisten. Einkerbungen mit einem Messer eingeschnitten, Leitungen rein und mit Heißkleber fixiert. Um die „Schönheit“ des Aufbaus ging es zu diesem Zeitpunkt gar nicht mehr. 20 LEDs später sah der Aufbau mit provisorisch hängenden Verbindungen immer noch recht abenteuerlich aus, aber es war tatsächlich eine LED-Matrix zu erkennen!

Jetzt musste ich mir auch Gedanken wegen der Ansteuerung machen. Die einfachste Lösung ist sicherlich der LED-Player mit SD Kartenslot – Effekte auf die SD Karte packen und abspielen lassen – die passenden Dateien zu generieren ist jedoch zeitraubend. Ich wollte das ganze aber in Aktion sehen, also habe ich die LEDs an einen LED-Player-S angeschlossen und per USB mit dem PC verbunden. Jinx! (läuft nur unter Windows) gestartet und ein paar Effekte ausprobiert. Es funktioniert! Allerdings soll die Matrix an einem anderen Fenster angebracht werden, wo kein Windows-Rechner in der Nähe steht. Man kann natürlich auch den WLAN-Player nehmen und die LEDs statt per USB über WLAN vom gleichen Rechner ansteuern. Der Gedanke, einen kompletten PC zur Steuerung einer „Lichterkette“ permanent laufen zu lassen, missfällt mir aber irgendwie. Eine alternative Ansteuerung (über Raspberry Pi z.B.) fällt mir hoffentlich bald noch ein

Auf dem Wege allen Lesern frohe Weihnachten!

Update: Dank dem Tipp von Folker hat sich die Suche nach dem Rechner für die Ansteuerung erledigt. In jinx! ist es nämlich möglich den Output statt auf die LEDs in eine Datei umzuleiten. Danach kann diese Datei problemlos von der SDKarte im LED-player gelesen und endlos abgespielt werden.

Vor etwa einem Jahr wollte ich mich mit der Bluetooth Low Energy (BLE) Technologie beschäftigen. Im Vergleich zu WLAN Modulen haben BLE Module je nach Einsatz weit kleineren Stromverbrauch und können längere Zeit von Batterien betrieben werden. Zudem waren sie schon damals viel kompakter und vor dem Erfolg der ESP-Module auch  viel günstiger. Ich bin damals wie immer vorgegangen: im Internet nach den günstigsten Modulen (damit man mehrere davon besorgen kann und es nicht weh tut, wenn mal das eine oder das andere kaputt geht) gesucht mit der Möglichkeit diese umzuprogrammieren. Sie sollten auch klein sein, damit sie leicht versteckt werden können…

Damals bin ich auf günstige kleine Module gestoßen, die als Blueooth – Seriell Bridges verkauft wurden. Diese Module gibt es auch heute noch, sie basieren auf den TI Chips CC2540 und CC2541. Sie haben einen 8-bit 80C51 MCU-Kern und Bluetooth Schnittstelle. Ziemlich schnell hat sich jedoch herausgestellt, dass die Entwicklung für diese Plattform für einen Hobby-Entwickler kaum möglich ist. Zum einen kann man nicht einfach einen beliebigen 80C51 Compiler nehmen und es mit dem vorkompilierten BLE-Stack verwenden. Man ist auf die Keil- und IAR-Tools angewiesen, die nicht gerade günstig sind. Zum anderen kommt man als Privatperson weder an den BLE-Stack noch an das SDK dran. Letztendlich brauch man noch ein extra Programmiergerät für diese Chips, das man auch vermutlich nie zum anderen Zweck verwenden wird. Das ganze funktioniert nur unter Windows wohl gemerkt. Mit einer Testversion der IAR IDE und einigen Beispielen von github konnte ich einige Experimente damit machen. Das SDK und die vorgegebene Code Struktur war jedoch so komplex, dass es irgendwann keinen Spaß mehr gemacht hat. Zu dem Zeitpunkt gab es auch eine Alternative von Nordic Semiconductor – BLE Chips mit ARM Cortex-M0 Kern. Diese waren jedoch um einiges teurer. Bis heute…

nRF51822 Boards rechts, c2540 Modul zum Vergleich links

Inzwischen gibt es sehr viele Entwickler-Boards auf Basis von nRF51 Chips. Die meisten haben nRF51822 onboard und so gut wie alle haben auch mbed Unterstützung. D.h. die Boards haben einen zusätzlichen Chip, der ein USB Laufwerk emuliert, sodass man darauf vom mbed online Compiler erzeugte Datei ablegen kann und diese dann automatisch in den Flash vom nRF51822 programmiert wird. Inzwischen kann man jedoch die Updates mit einem passenden Bootloader auch über Bluetooth einspielen. Neben mbed kann man die Entwicklung auch mit dem SDK von Nordic starten. Der BLE Stack (SoftDevice gennant) liegt hier als hex-Datei vor und muss einfach in den Flash geschrieben werden und nicht wie bei TI nach dem Kompilieren verlinkt werden. Den Rest des eigenen Programms kann man praktischerweise mit einem beliebigen ARM Cortex-M0 kompatiblem Compiler übersetzen. In meinem Fall ist es GCC geworden. Ich habe wieder die günstigsten und kompaktesten Module gesucht und bin dann auch fündig geworden. WT51822-S4AT Module werden auch als BLE – UART Bridges verkauft, sind aber frei umprogrammierbar – die SWD (ARM’s Serial Wire Debug protocol) Pins sind praktischerweise an den Board Pins vorhanden. Kleiner Hinweis an der Stelle: bei meinem Modul ist die QFAA Version des Chips mit 16 kB RAM verbaut, die QFAC Version hat dagegen 32 kB.

Als Testkandidaten für erste Schritte mit neuer Hardware habe ich wie schon öfter den Digi-Dot-Booster genommen. Aus den gleichen Gründen wie beim ESP12-Modul: Er liefert 3V Versorgungsspannung und liefert mit der SPI Schnittstelle den ersten Eindruck, wie das SDK in der Praxis zu handhaben ist.

Für die Tests ein Modul huckepack mit dem DD-Booster und als Breakout für Breadbord

Zum Programmieren wurde ST-Linkv2 von einem STM32 Nucleo Board verwendet und openocd als Flash tool. Die Tools und Anleitungen von Nordic sind auf die Verwendung von Segger J-Link ausgelegt. Mit den zahlreichen Beispielen aus dem Nordic SDK 12.0 konnte ich auch recht schnell die SPI Schnittstelle ansprechen und die LEDs mit dem klassischen Regenbogen zum Leuchten bringen – das ganze erstmal ohne Bluetooth Funktionalität. Dabei ist eine Tatsache positiv aufgefallen: die Pins können beliebig für die Peripherie konfiguriert werden. Somit konnte ich die Pins an den Seiten der Platine ohne Probleme der SPI Schnittstelle und der RESET Leitung zuweisen.

WT51822-S4AT Modul Pin Belegung. P0.X entsprechen den Pins des nRF51822, in rot die zugewiesene SPI Belegung.

Vom schnellen Erfolg beflügelt, bin ich zu den Bluetooth Beispielen von Nordic gekommen, und musste dann erste Niederlagen erfahren. Egal was ich ausprobiert habe, lief der Bluetooth Stack überhaupt nicht. Ich bin bei den SDK Versionen bis zu der 6-en runter gegangen, verschiedene Versionen des GCC Kompilers ausprobiert, sowohl auf Windows als auch auf dem Mac – mit gleichem Ergebnis. Irgendwann hatte ich von Frustrationen genug und bin zum mbed online Compiler gewechselt (als Plattform RedBearLab BLE Nano ausgewählt). Seltsamerweise funktionierte hier Bluetooth sofort auf Anhieb, obwohl unter der Haube genauso ein SoftCore von nordic verwendet wird. Die Gründe haben mich wenig interessiert – ich war froh, dass es funktioniert. Die BLE API von mbed erwies sich auch um vielfaches einfacher in der Handhabung als das Nordic SDK. So bin ich dann recht schnell zu einer funktionierenden Version des Digi-Dot-Boosters mit BLE Schnittstelle gekommen. Dabei werden die über Bluetooth Service empfangene Befehle einfach 1:1 über SPI an den DD-Booster weitergeleitet. Die Programmierung erfolgt manuell: die aus dem Browser heruntergeladene Datei wird lokal abgelegt und mit openocd in den Flash geschrieben. Mit einem Script kann man sicherlich auch das automatisieren.

Für die Übertragung wird ein BLE Service von Nordic verwendet: NUS – Nordic UART Service. Er hat 2 Charakteristiken: eine zum Schreiben (RX Characteristic) und eine zum Lesen (TX Characteristic) von Daten. Das Schreiben erfolgt ohne Bestätigung, was den Datendurchsatz etwas verbessert. Da der DD-Booster keinen Rückkanal hat und nach dem fire & forget Prinzip funktioniert, wird hier auch nur die RX Charakteristik zur Steuerung benötigt.

nRF Connect Android App mit Infos zum NUS

Den Code für das BLE Modul gibt es hier bei mbed. Im Laufe der Tests ist auch eine vollwertige mbed DD-Booster Bibliothek entstanden, die analog zu der Arduino Library die einzelnen Befehle und die SPI Steuerung in Funktionen kapselt. Über die Import Funktion, kann sie in die eigenen Projekte hinzugefügt werden. Die Biblitohek wurde mit einem Nucleo Board getestet – das WaterDrop Beispiel gibt es auch dazu. Zusätzlich ist der Code der Bibliothek auch auf github zu finden. Probleme und Verbesserungen am besten dort melden.

Die Bluetooth Steuerung kann auf vielen Wegen erfolgen. Sowohl für Android als auch für iOS gibt es BLE Schnittstellen für die eigenen Apps. Seit Kurzem ist auch die Steuerung mit Chrome direkt aus dem Browser heraus möglich. Das ist auch der Weg, für den ich bei der Umsetzung meiner DD-Booster-BLE Web App entschieden habe. Mehr dazu folgt im nächsten Beitrag.