3D-LED-Display
Aus BraLUG-Wiki
(→Display-Steuerung mit Etherrape) |
(→Simulator) |
||
Zeile 23: | Zeile 23: | ||
[[Bild:Cube_viewer.jpg|thumb|320px|Screenshoot: cube_viewer]] | [[Bild:Cube_viewer.jpg|thumb|320px|Screenshoot: cube_viewer]] | ||
− | Bevor man viel Geld für die Hardware | + | 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. | 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. |
Version vom 8. Juni 2007, 12:19 Uhr
Inhaltsverzeichnis |
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
Simulator
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.
Hier der Quelltext der TCL/Tk-Applikation.
Hardware
(Schaltplan LEDs plus Decoder...)
Display-Steuerung mit Etherrape
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
- 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 entsprechendes 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.
Software
PC-Client (Kommunikationsprotokoll Client/Server)
mögliche Kommandos und deren Reihenfolge...
Etherrape
Die zum Etherrape-Bausatz verfügbare Firmeware (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 Firmeware 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.
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)
Offen
- LED-Hardwareaufbau
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ß.