LED-Laufschrift fürs Vereinsheim

Version vom 25. Oktober 2015, 14:31 Uhr von HKay (Diskussion | Beiträge) (Schalter auf rueckseite in Software auslesbar)
LUMINO hängt und zeigt den aktuellen Song

Idee

  • Aufbau einer LED-Laufschriftanzeige, die das Topic aus dem IRC-Channel anzeigt (wird an der Tür des Vereinsheims installiert Das Lumino ist 1,38 m breit und dafür nicht geeignet).
  • + evtl. LED-Matrix als Leuchtreklame
  • LUMINO als Anzeige für das aktuelle Lied aus dem MPD
  • LUMINO zeigt den Song, scrollt zu lange Zeilen, zeigt eine Fortschrittsanzeige an und zeigt den Staus (Play, Pause oder Stop) an
  • LUMINO hängt gut sichtbar Benutzer:Juhe

Verantwortlich

Funktionsweise

 
Lumino mit internem Aufbau und Client-Struktur

Lumino-intern

Im Lumino befinden sich ein STM32F4Discovery, das die 5 LED-Panels ansteuert sowie ein Raspberry Pi, das die Funktion eines Display-Servers übernimmt und Zeichenfunktionen über das Netzwerk zur Verfügung stellt.

Das Lumino besteht aus 5 LED-Panels, auf denen sich jeweils 32x24 LEDs befinden. Diese sind wiederum in Blöcken von 4x8 LEDs organisiert, wobei jeder Block von einem Treiberbaustein angesteuert wird. Innerhalb dieser 4x8-Blöcke ist die Anordnung der LEDs willkürlich gewählt, allerdings sind alle Blöcke gleich (Dokumentation zum LED-Mapping). Die Zuordnung eines Bits aus dem Framebuffer auf die richtige LED wird durch das STM32F4Discovery vorgenommen.

Die Kommunikation des Raspberry Pis mit dem STM32F4Discovery erfolgt über UART. Es werden grundsätzlich vollständige Frames übertragen.

Auf dem Raspberry Pi läuft der Display-Server, der die Ansteuerung des Displays auf höherer Ebene ermöglicht. Dazu wartet er auf TCP-Port 12345 auf Befehle (siehe API-Doku). Zur vereinfachten Anzeige von Text wird ein zweizeiliger Textbereich („textarea“) zur Verfügung gestellt, der beliebig platziert werden kann. Ist der gesetzte Text zu groß für den Textbereich, wird automatisch gescrollt.

Extern (Client-Skript)

Auf einem Rechner im Vereinsheim (derzeit Stern, Stand 20.07.2014) läuft ein Client-Skript, das die Koordination der Ansteuerung des Luminos übernimmt.

Folgende Funktionen sind derzeit implementiert:

  • Anzeige des MPD-Status (laufendes Lied, aktueller Fortschritt u.ä.)
  • Begrüßung von Mitgliedern, die sich in das NDATool eingetragen haben (dies hat Vorrang vor dem MPD-Status)

Dazu kommuniziert das Skript sowohl mit dem Music Player Daemon als auch dem MACTracker-Skript, das eine Liste der anwesenden Personen generiert. Kommt jemand neu hinzu, wird dieser 1 Minute lang begrüßt, ansonsten wird der aktuelle MPD-Status angezeigt.

Das Skript befindet sich auf Stern unter /home/bingo/scripts/lumino-client.py .

Umbau im Juni/Juli 2015

Im Juni 2015 ging das Original-Netzteil des Lumino-Displays kaputt, das die +3V für die LEDs zur Verfügung stellt. Da das Netzteil 40A liefern können muss, gestaltete die Suche nach einem Ersatz anfangs schwierig, da Netzteile in dieser Leistungsklasse meist nicht gerade günstig sind.

Es stellte sich jedoch heraus, dass etwas Passendes bereits im Vereinsheim vorhanden war: ein +3,3V/40A-Netzteil, das mal auf Verdacht bei Pollin gekauft wurde, weil es gerade billig war. Da dieses Netzteil auch noch +5V/40A und +12V liefern kann, wurde beschlossen, den kompletten Original-Netzteilsatz des Luminos zu tauschen. Für das neue Netzteil wurden Adapter gebaut, so dass die Steckerleisten des alten Netzteils weiterverwendet werden konnten und die Kabel nicht getauscht werden mussten. An die +5V wurde noch der Logik-Teil der LED-Matrix sowie das Raspberry Pi und das STM32F4 Discovery angeschlossen. Die 12V werden nur für den Spannungsteiler zum Dimmen der LEDs verwendet (dieser besteht aus dem Poti im Gehäuse und einem 5,6 kΩ-Widerstand).

Bei der Wiederinbetriebnahme zeigte sich, dass das Dateisystem auf dem Raspberry Pi die häufigen Resets während der Fehlersuche wohl nicht überstanden hatte und somit das System nicht mehr bootete. Es wurde also ein neues System auf Basis von Gentoo mit crossdev aufgebaut, welches nur-lesbar aus einem squashfs-Archiv geladen wird. Dadurch sind zukünftige Ausfälle des Dateisystems ausgeschlossen und die Bootzeit ist wesentlich geringer.

Umbau im Oktober 2015

Das Lumino braucht allgemein zu viel Strom fuer unsere Stromrechnung. Daher soll die Leuchteinheit erst eingeschalten werden, wenn sie benutzt wird. Dazu wurde ein Relais in die 230V Versorgung des +3V Netzteils geschalten. Dieses wird erst eingeschalten, wenn der Raspberry Pi GPIO25 auf High zieht.

Ausserdem wird der schalter an der Rueckseite des Geraets auf GPIO2 eingelesen. Es ist noch kein Zweck fuer diesen Schalter vorgesehen.


Aktueller Stand

  • Pi bootet vom squashfs und startet den DisplayServer :-)
  • Alle LED-Panels können angesteuert werden

Die Entwicklungsumgebung für das Gentoo-Squashfs liegt auf archzilla.bingo. Zum Zugriff darauf als "bingo" einloggen und folgendes tun:

         $ sudo -s
         # cd /home/bingo/chroots/gentoo
         # ./init_chroot.sh
         # chroot . /bin/bash
(chroot) # source /etc/profile

In dieser Umgebung existieren 3 Ordner unter /root:

  • raspi-linux: der Kernel für den Lumino-Pi
  • raspi-root: das Root-Dateisystem, aus dem das squashfs erstellt wird (dieses enthält KEIN Portage!)
  • raspi-initramfs: das initramfs, das das squashfs mountet und mit einem tmpfs überlagert

Zusätzlich gibt es Skripte, die aus diesen Ordnern die entsprechende Zieldatei (initramfs.img, root.squashfs) erstellen.

Alle persistenten Änderungen am Pi-System werden in /root/raspi-root vorgenommen und dann in root.squashfs gepackt, welches dann auf die boot-Partition der SD-Karte kopiert werden kann.

Das installieren neuer Pakete erfolgt in 2 Schritten:

armv6j-hardfloat-linux-gnueabi-emerge -av <paket>


installiert das Paket unter /usr/armv6j-hardfloat-linux-gnueabi, der Buildumgebung für das Rasperry-Pi-System, und erzeugt Binärpakete.

ROOT=/root/raspi-root armv6j-hardfloat-linux-gnueabi-emerge -avK <paket>

installiert die erzeugten Binärpakete (nur die Laufzeitabhängigkeiten) unter /root/raspi-root. Das Flag -K ist sehr wichtig, da dies verhindert, dass Pakete aus den Quellen gebaut werden (das sollte nur in der Buildumgebung geschehen).

Probleme/ToDo

Software:

  • Boot-Zeit zu lang
    • Symptom: OpenRC steht lang bei „Caching service dependencies“
    • Mögliche Ursachen: Datei mit Abhängigkeiten fehlt, falsche Zeitstempel
    • Mögliche Lösung: Root-Dateisystem nach dem Boot vom Pi ziehen, mit dem Original vergleichen und fehlende Dateien nachziehen, so dass diese beim Booten bereits vorhanden sind
    • Alternativer Lösungsansatz: