3D-LED-Display

Version vom 24. September 2007, 08:12 Uhr

Idee

Was soll man eigentlich dazu sagen? Irgendwann bin ich beim Rumstöbern im Internet auf ein paar Seiten gestossen, die komischen Spielereien mit LEDs beschrieben. U.a. waren da auch Bilder von dreidimensional angeordneten LEDs dabei, die lustige Animationen anzeigen konnten. Für mich stellte sich gleich die Frage, wie funktioniert das?

Nach einigen Überlegungen um die Funktionsweise eines solchen "Display" (eigentlich handelt es sich ja um eine solche "Geräteklasse", oder?), merkte ich, dass man sich in Wissensgebiete einarbeiten muß, die ich schon immer mal betreten wollte! Super, also nichts wie ran an eine solche Aufgabe und das Projekt "Uwe's LED-Cube" war geboren!

Falls jemand die Frage nach dem Sinn eines solchen Displays stellt: ich betrachte die ganze Geschichte als Studie und letztendlich könnte man die Sache ja auch als "Kunstobjekt" bezeichnen :-). Aber mit der Zeit sind auch ein paar sinnvolle Ideen vorhanden, die man mit einem solchen Ding machen könnte, wenn es mal fertig ist..., schauen wir dann mal!

Eins noch vorweg, wer denkt, dass so etwas ohne viel Zeitaufwand und aus dem Stehgreif realisierbar ist, der soll es am besten gleich lassen! Ich habe das am Anfang auch nicht richtig einschätzen können, aber auf halben Weg mache ich jetzt keinen Rückzieher mehr...

Konzept

In kurzen Stichpunkten:

• Ein Würfel mit einer Dimension von 8x8x8 LEDs (also insgesamt 512 Stk.!).
• Um die Verdrahtung der LEDs in Grenzen zu halten (512 LEDs!), muß eine Schaltung her, die die LEDs in Gruppen zusammenfasst und eine Adressierung in (z.B.) Spalten, Zeilen und Ebenen ermöglicht.
• Die Ansteuerung dieser Spalten, Zeilen und Ebenen erfolgt durch einen Mikrocontroller. Die LEDs werden also nicht statisch an-/ausgeschaltet, sondern es werden zeitlich nacheinander alle Ebenen, Spalten, Zeilen angesteuert (Stichwort Multiplexverfahren). Erfolgt dies entsprechend schnell hintereinander (> 50 mal in der Sekunde pro LED), hat man wieder den Eindruck, ein statischens Bild vor sich zu haben. Ähnlich funktionieren z.B. auch Fernseher.
• Der Mikrocontroller bekommt seine Daten, welche LED an bzw. aus ist, via TCP/IP über das Ethernet von einem PC.
• Auf dem PC läuft eine Clientsoftware, die die einzelnen "3D-Bilder" generiert und zum Mikrocontroller sendet.

Ein schematisches Bild kommt noch...

Umsetzung

Cube-Simulator und -Editor

Bevor man viel Geld für die Hardware ausgibt sowie unnötig Zeit investiert, möchte man natürlich wissen, ob sich der ganze Aufwand überhaupt lohnt. Deshalb entstand die Idee, einen Cube-Simulator zu entwickeln, mit dem man schon mal erste Eindrücke gewinnen kann, wie das Ding später in der Realität aussieht und was man theoretisch damit anstellen kann.

Konzeptionell handelt es sich um eine Client-/Server-Anwendung. Die Client-Seite generiert dabei die vom Server grafisch darzustellenden Bilder und sendet diese via TCP/IP an die Server-Applikation. Der Server setzt die gesendeten Daten (hauptsächlich den Schaltzustand jeder einzelnen LED) in die grafische Darstellung des LED-Würfels um. Der virtuelle Würfel kann vom Anwender im Raum gedreht/bewegt werden.

Die Kommunikation zwischen Client und Server erfolgt über spezielle Kommandos und ist so ausgelegt, dass später der Client auch mit der realen Hardware kommunizieren kann, also von der Seite keine Änderungen erfolgen müssen. Dazu wurden in der Steuerungssoftware für das Etherrape die gleichen Befehle implementiert.

Auf eine eingehende Beschreibung der Simulator-Software wird an dieser Stelle verzichtet und auf die, im Programmpaket vorhandene Kurzdokumentation verwiesen.

Auf Grundlage des Cube-Simulators, hat ein Bekannter (Danke für deine Arbeit!) einen Cube-Editor entwickelt. Mit Hilfe dieses Programmes ist es auf einfachste Weise möglich 3D-Bilder und -Animationen für den Cube zu erstellen, abzulegen und an diesen auszugeben. Mittlerweile konnte dieses Programm auch an der realen Hardware ausprobiert werden und bestätigte den konzeptionellen Ansatz, dass der Simulator durch den echten LED-Cube einfach ausgetauscht werden kann. Einzelheiten zur Bedienung des Editors sind ebenfalls aus der, dem Programmpaket beiliegenden Dokumentation zu entnehmen.

Hier die Quelltexte des Cube-Simulators und des Cube-Editors, welches beides TCL/Tk-Applikationen sind.

Hardware

Display-Steuerung mit Etherrape

Etherrape mit einer kleinen Testplatine

Relativ zeitgleich mit den ersten Überlegungen zu diesem Projekt, erschien im Linux-Magazin ein kurzer Artikel zu einem, übers Internet bestellbaren, Mikrocontrollerbausatz mit dem Namen "Ethterrape". Die dort beschriebenen Eigenschaften des Bausatzes paßten wie die Faust aufs Auge für die Ansteuerung meines geplanten 3D-LED-Displays.

Hier einige Features, die für mich interessant waren:

• Plattform: Atmel ATmega644
  • im optimalsten Fall stellt dieser Mikrokontroller 32 frei programmierbare I/O-Datenleitungen zur Verfügung (Man sollte aber den Schaltplan und die Dokumentation des Etherrape studieren, um die wirklich unbenutzten Ports zu lokalisieren. Ein Großteil der Ports wird schon durch die vorhandene Peripherie belegt!)
  • CPU-Takt 20Mhz, was für die erforderliche Verarbeitungsgeschwindigkeit zur Ansteuerung der LEDs ausreichen sollte
  • bei Kauf des Bausatzes ist bereits ein Bootloader auf dem Chip vorinstalliert, man braucht also keine weitere Zusatzhardware zur Programmierung des Mirkrocontrollers. Es reicht eine serielle Schnittstelle plus entsprechendem Kabel am PC (bzw. USB2Serial-Wandler)
• Ethernetschnittstelle auf der Karte vorhanden
  • Hurra, ich kann die Daten via Netzwerk zur Steuerung schicken!
  • TCP/IP-Stack (uip) bereits in verfügbarer Firmware zum Bausatz integirert
• ein Data-Flash-Chip (2MB) auf der Platine vorhanden
  • das bietet einige Möglichkeiten, auch mal Daten zwischenzuspeichern, um den Cube autonom, ohne PC, betreiben zu können
• freie avr-Toolchain für Linux vorhanden (avr-gcc, avr-libc, avr-binutils, avrdude)
  • man ist bei der Programmierung des ATmega nicht auf propitäre Entwicklungsumgebungen und Compiler angewiesen
• Grundstock einer Firmware verfügbar
  • es ist nicht notwendig sich erst mit irgendwelchen Initialisierungen der Hardware auf der Platine rumzuschlagen, man kann gleich damit beginnen, seine Anwendung in die Firmware zu integrieren
• kompletter Bausatz preisgünstig im Internet bestellbar, gleich mit Gehäuse und Netzteil
  • man muß sich nicht erst mit irgendwelchen Stücklisten, Leiterplatten usw. beschäftigen: Bestellen, Lötkolben raussuchen, Platine bestücken, testen und schon hat man einen kleinen funktionsfähigen Mikrorechner

Eine genauere und vollständige Beschreibung der Eigenschaften, findet man auf der Etherrape-Projektseite..... Hier findet man auch einen Link zum Online-Shop für die Bestellung des Bausatzes.

Decoder

Die direkte statische Ansteuerung jeder einzelnen LED in einer 8x8x8-Matrix ist etwas unrealistisch, da man mindestens 513 Leitungen verdrahten und ansteuern müßte.

Durch eine geeignete Zusammenfassung der einzelnen Ebenen, Spalten und Zeilen der Matrix in Gruppen, die mit Hilfe einer entsprechend gestalteten Transistorlogik gezielt angesteuert werden können (siehe Schaltplan der LED-Matrix im nächsten Kapitel), reduziert sich die Anzahl der notwendigen Leitungen zur Matrix auf 24 (jeweils 8 Leitungen für die Ebenen und Spalten sowie 8 Leitungen für die LEDs einer Zeile).

Prinzipiell funktioniert es dann so, daß in einem Schritt genau eine Ebene und eine Spalte aktiv ist. Für die dazugehörige LED-Zeile müssen dann die entsprechend anzuschaltenen LEDs durchgeschaltet werden. Erfolgt das Durchschalten jeder Ebene/Spalte (für ein Bild sind das 8x8=64 Schritte) entsprechend schnell, entsteht wieder der Eindruck eines statischen Bildes (ähnlich dem Prinzip eine Monitors oder Fernsehers).

Für das Etherrape sind 24 Leitungen immer noch zu viel, da ein Großteil der theoretisch vorhanden I/O-Ports des Atmel644 von der Peripherie der Baugruppe verwendet wird (Ethernetschnittstelle, Dataflash usw.; dazu mal den Schaltplan und die Dokumentation zum Etherrape konsultieren). Also muß die Anzahl der Leitung zum Mikrocontroller weiter reduziert werden und es muß eine entsprechende Schaltung her, die dies erledigt!

In einem Ausgabeschritt muß genau eine Ebene und eine Spalte aktiviert werden. Es bietet sich also an dafür jeweils einen 1-aus-8-Decoder (z.B. 74HC237) zu verwenden. Die genaue Funktionsweise ist dem Datenblatt des ICs zu entnehmen. Prinzipiell wird im IC aus einer 3-Bit-Zahl der entsprechende Ausgang auf "1" geschaltet. Man benötigt für die Ebenen und Spalten der Matrix jeweils einen 1-aus-8-Decoder zu denen jeweils 3 Datenleitungen (also ingesamt 6) zum Mikrocontroller geführt sind und durch diesen angesteuert werden.

Für die Ausgabe eine Zeile muß etwas anders vorgegangen werden, da hier in einem Schritt mehr als ein Ausgang gleichzeitig durchgeschaltet werden soll. Dazu ist ein 8-Bit-Schieberegister (z.B. 74HC595) brauchbar. Die genaue Funktionsweise ist wieder dem entsprechenden Datenblatt zu entnehmen. Vereinfacht gesagt werden die 8 Bits schrittweise (in 8 Einzelschritten) in die Register des ICs geschoben und zum Schluß an die Ausgänge übergeben. Dazu sind wiederum 3 Leitungen zum Mikrocontroller notwendig.

Insgesamt haben wir das ganze jetzt also auf 9 Datenleitungen reduziert, die der Mikrokontroller in geeigneter Art und Weise ansteuern muß. Einzelheiten sind dem Schaltplan des Decoders und der Mikrocontoller-Software zu entnehmen.

Hardwareseitig wurde der Decoder auf einer Lochrasterplatte aufgebaut, da sich die Anfertigung einer gedruckten Leiterplatte als Einzelstück nicht lohnt (siehe Foto rechts). Zusätzlich wurden die Ausgänge der beiden 1-aus-8-Decoder und des Schieberegisters mit Leistungstreiber (z.B. 74HC244) abgesichert, da teilweise durch einen Ausgang mehrere Transistoren durchgesteuert werden müssen.

Hier der Schaltplan und ein Bild des Decoders:

LED-Matrix

Nach einigem Überlegen, wie nun wirklich die LED-Matrix verschaltet werden soll, habe ich mich entschlossen zuerst einen Versuchsaufbau mit der Dimension 3x3x3-LEDs zu realisieren. Was soll ich sagen, bis auf unten geschildertes Problem, funktionierte die Schaltung auf Anhieb!

Verdrahtung der LEDs: Der LED-Würfel wird ebenenweise aufgebaut. Alle LED-Anoden einer Ebene sind verbunden. Die Verdrahtung einer Ebene wurde in einem selbst angefertigten Steckbrett mit 3x3 5mm-Löchern, in welchen die LEDs fixiert wurden, vorgenommen. Die Stabilität wird durch den verwendeten 1mm-Silberdraht gewährleistet. In der Senkrechten sind jeweils alle Kathoden einer Spalte übereinander verbunden. Die Verbindung wurde ebenfalls mit Silberdraht hergestellt, was dann dem Gesamtgebilde die notwendige Stabilität gibt.

Transistor-Treiber: Aus dem beiliegenden Schaltpaln ist ersichtlich, wie die Treibertransistoren verschaltet sind. Prinzipiell müssen immer 3 Transistoren durchgeschaltet sein, damit eine LED leuchtet. Ein Transistor schaltet die jeweilige Ebene geben Plus der Versorgungsspannung. Die beiden anderen Transistoren steuern den Stromfluß gegen Masse. Wann welcher Transitor durchschaltet ist aus der vorgelagerten Decoderschaltung und dem entsprechenden MC-Programmteil ersichtlich.

Es fällt aus, dass die LEDs ohne Srombegrenzungswiderstand betrieben werden. Bei der Konzeption der Schaltung bin ich davon ausgegangen, dass die LEDs gepulst angesteuert werden und nicht ständig durchgeschaltet sind. Vermutlich würden einige Transistoren/LEDs bei dauerhaften Durchschalten das Zeitliche segnen (will ich aber auch nicht ausprobieren...), da dann ständig zu hohe Ströme fließen würden.

Hier der Schaltplan und 2 Bilder des Versuchaufbaues in der Dimension 3x3x3:

Hier eine kleine Video-Sequenz des 3x3x3-Cube.

Problem, was aufgefallen ist: Mit der obigen Schaltung glimmen die nicht durchgesteuerten LEDs schwach (fällt zwar nicht sonderlich auf, ist aber unschön). Meine Vermutung ist, dass an jedem Transistor noch ein Pulldown-Widerstand zwischen Basis und Emitter geschaltet werden muß, weil beim Low-Pegel die anliegende Spannung an der Basis zu hoch ist und damit der Transistor schon teilweise durchschaltet ist (Formulierung eines Nicht-Elektronikers ;-)...). Dies werde ich demnächst mal ausprobieren... Desweiteren habe ich gesehen, dass es bereits Transistoren mit den beiden Basiswiderständen fertig in einem Gehäuse gibt, habe bloß noch keinen Lieferanten gefunden, der soetwas an Privatpersonen verkauft. Aber für den "richtigen LED-Cube" wäre das sicherlich eine interessante Alternative!

Software

PC-Client (Kommunikationsprotokoll Client/Server)

Aufgabe des Client ist es, die, auf dem 3D-LED-Displays darzustellenden Bilder zu generieren und an dessen Steuerung zu senden. Was für Bilder, wie generiert werden, ist egal und der Phantasie sind dabei keine Grenzen gesetzt. Selbstverständlich können durch geeignete Algorithmen auch Bildsequenzen erzeugt werden, welche dann bildweise sequenziell hintereinander an die Steuerung gesendet werden. Einige TCL-Bespiele sind im Softwarepaket des Simulators (die ja auch für die reale Hardware verwendet werden können) enthalten. Statt TCL kann natürlich auch jede andere Programmiersprache verwendet werden.

Einzig das Kommunikationsprotokoll zwischen Client und Steuerung ist festgelegt. Der Austausch der Befehle erfolgt via TCP/IP (Portadresse siehe Quelltext Etherrape-Steuersoftware). Folgende Kommandos sind definiert:

• get_xyz: fordert die Dimension des 3D-LED-Displays an. Als Antwort wird von der Steuerung ein set_xyz <x> <y> <z> zurückgegeben, also z.B. set_xyz 8 8 8 für 8 Spalten, 8 Zeilen und 8 Ebenen. Dieses Kommando ist nicht zwingend notwendig, kann/sollte aber dazu benutzt werden, um die Länge des Argumentes des Befehles set_led zu bestimmen und natürlich einen Ausgangspunkt für die Bildgenerierung im Client zu haben.
• set_led <char[x*y*z]>: sendet zur Steuerung des 3D-LED-Displays den Schaltzustand jeder einzelnen LED für das darzustellende Bild. Das Argument dieses Kommandos ist ein Text mit jeweils '0'=LED aus und '1'=LED an. Die Länge des Argumentes richtet sich nach der Dimension des Würfels (siehe get_xyz). Jedes Zeichen stellt eine LED dar. Reihenfolge: LED-Zeile der 1.Spalte in der 1.Ebene; LED-Zeile der 2.Spalte in der 1. Ebene ... LED-Zeile der letzten Spalte in der letzen Ebene. Die erfolgreiche Verarbeitung des Kommandos wird mit einem update_ok quittiert.

Etherrape

Die zum Etherrape-Bausatz verfügbare Firmware (Orginal bzw. librape) bildet die Grundlage für Eigenentwicklungen. Einerseits initialisiert sie die, auf der Platine vorhandenen Hardwarekomponenten (serielle Schnittstelle, Ethernetschnittstelle, Data-Flash usw.). Zum anderen sind Routinen implementiert, welche in eigene Anwendung eingebunden werden können. U.a. sind dies:

• Ein-/Ausgabe via serieller Schnittstelle
• Ein-/Ausgabe via Ethernet (TCP, UDP)
• Initialisierung/Lesen/Schreiben eines Filesystemes auf dem Data-Flash
• ... und einiges mehr (da noch keine richtige Dokumentation verfügbar ist, im Quelltext nachschauen)

Aufbauend auf die Firmware wurden für die Ansteuerung der LED-Hardware folgende Dinge realisiert:

• Eine, vom Rest der Anwendung, unabhängig laufende Interruptroutine, die das Durchschalten der LED-Zeilen, -Spalten und -Ebenen des Würfels realisiert sowie natürlich den Schaltzustand jeder LED an die Hardware ausgibt. Der Interrupt wird durch den Überlauf eines ständig laufenden Timers ausgelöst. Die Initialisierungswerte des Timers sind so eingestellt, dass jede LED pro Sekunde ausreichend oft angesteuert wird, um den visuellen Eindruck eines statischen Gesamtbildes zu vermitteln.
• Ein weiterer Programmteil realisiert die Kommunikation zwischen einem Client und dem Etherrape via Ethernet (TCP/IP). Es werden die eingehenden Kommandos/Daten analysiert und entsprechend verarbeitet. Die Beschreibung des Protokolls zwischen Client/Etherrape ist im Abschnitt "Software->PC-Client zu finden. Zu Testzwecken sind folgende weitere Kommandos implementiert:
  • version: es wird ein Programmname und der Übersetzungszeitpunkt der momentan auf dem Etherrape installierten Firmware zurückgegeben.
  • set_prescale <unsigned integer>: ermöglicht es, die Parameter des Timers zur Laufzeit zu manipulieren, also die Zeit zwischen zwei Aufrufen der Interruptroutine zu verlängern oder zu verkürzen.

Den derzeitigen Entwicklungsstand der Etherrape-Firmware zur Ansteuerung des Cube findet man hier. Innerhalb der Datei cube.c ist die Implementierung der Ansteuerung des Decoders und des Kommunikationsprotokolles zu finden. Die aktuell dort eingestellten Timerwerte der Interruptroutine sind für den Betrieb des Testaufbaues (3x3x3-Würfel) optimiert. Die Installation von librape wird vorausgesetzt.

Derzeitiger Stand

Erledigt

• Simulator (mit einigen Clientprogrammen, die mehr oder weniger sinnvolle Bildsequenzen generieren)
• Etherrape (Bausatz zusammengelötet und getestet)
• Steuerungssoftware für Etherrape (Client-Kommandos, Ansteuerung der LED-Hardware)
• Aufbau eines 3x3x3-Cubes, um Schaltung auszuprobieren, den geeigneten LED-Typ zu finden und die korrekte Funktionsweise der Etherrape-Software im "Echtzeitbetrieb" zu testen

Offen

• LED-Hardwareaufbau des eigentlichen 8x8x8-Cube

Erweiterungsideen

• Das Etherrape besitzt auch einen Dataflash auf der Platine, in dem man ein Filesystem anlegen und Daten ablegen kann. Hier könnte man die einzelnen "Bilder" ablegen und auf dem LED-Display anzeigen, ohne dass ein Client angeschlossen sein muß.
• unterschiedliche Helligkeiten jeder einzelnen LED (ein erster Versuch mit unterschiedlicher "Refresh-Rate" für die einzelnen LEDs ergab kein befriedigendes Ergebnis; --Bergeruw 09:12, 24. Sep. 2007 (CEST))

Kontakt

Uwe Berger

Weitere Informationen zum Thema

• Lichtdesign...
• LEDCube
• Blinken Borgs
• etwas Hardware für einen LEDCube
• noch ein Cube mit MC
• eine Diskussion zur Schaltung eines LED-Cubes
• Hypnocube - "nur" 4x4x4 aber dafür in bunt!
• Heimatseite des Projektes "Etherrape"