Aktuelle Version vom 19. April 2010, 15:38 Uhr

[Bearbeiten] Neuigkeiten

12.04.2010: Nach fast 2 Jahren, hat es mich doch wieder gepackt! Irgendwie war es nicht befriedigend, dass der Cube nicht 100% fertig war. Immer wenn man ihn Besuchern vorführen wollte, war gerade mein Etherrape mit einer anderen Firmware bestückt... Aus diesem Grund hatte ich mich entschlossen, eine leicht abgerüstete Variante der Mikrocontroller-Hardware einzusetzen und diese nur für den Cube zu reservieren. Das Ergebnis findet man unter Cube 2.0 auf dieser Seite. Achtung, in dem Zuge habe ich auch ein wenig an dem Netzwerkprotokoll geändert. Sämtliche Programme, die untereinander kompatibel sein sollten, sind jetzt in einem Archiv-File im entsprechenden Abschnitt dieser Seite zu finden.

[Bearbeiten] 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...

[Bearbeiten] 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...

[Bearbeiten] Umsetzung

[Bearbeiten] 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.

[Bearbeiten] Cube 1.0

[Bearbeiten] Hardware

[Bearbeiten] Übersicht

Auf dem Übersichtsbild sind die einzelnen Komponenten des 3D-LED-Würfels zu erkennen. Dies sind:

• Etherrape
• Decoder
• LED-Matrix

In der Folge werden der Aufbau und die Funktion der einzelnen Komponenten erläutert.

[Bearbeiten] 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
• eine Infrarot-Schnittstelle (Empfänger und Sender) über die man mit einer IR-Fernbedienung (RC-5) den LED-Würfel steuern kann
• 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.

[Bearbeiten] 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! Mit der Zeit sind 2 Versionen des Decoders entstanden, welche in der Folge beschrieben werden.

[Bearbeiten] Decoder (Version 1)

Die ursprüngliche Version, aufgebaut mit zwei 1-aus-8-Decodern und einem 8-Bit-Schieberegister.

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 (Version 1):

[Bearbeiten] Decoder (Version 2)

Die zweite Version des Decoders entstand, um weitere I/O-Ports des Mikrocontrollers zu sparen. Durch die Verwendung von drei hintereinander geschalteten Schieberegistern, werden jetzt nur noch 4 I/O-Leitungen benötigt.

Das Prinzip mit der Auswahl der Ebenen und Spalten sowie der Ausgabe der entsprechend adressierten Zeile erfolgt wie in Version 1. Allerdings werden Ebenen und Spalten der Transistorlogik nicht mehr mittels 1-aus-8-Decodern durchgeschaltet. Vielmehr sind die insgesamt 24 Leitungen der Matrixschaltung mit den 24 (8+8+8) Ausgängen der Schieberegister verbunden. Durch den Mikrocontroller werden nacheinander alle 3 Bytes in die Schieberegisterkette geschoben und ausgegeben. Die 1-aus-8-Kodierung für Spalte und Ebene erfolgt im Programm des Controllers.

Im Gegensatz zu Variante 1 hat jetzt der Microcontroller etwas mehr zu tun (Kodierung Spalte/Ebene, sequenzielles Befüllen der 3 Schieberegister), was sich aber erstmal nicht negativ auswirkt. Die Latenzzeiten bei einem Ping erhöhen sich um ca. 0,1ms.

[Bearbeiten] 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:

Bestellliste für den 8x8x8-Cube:

• 512 Stk. superhelle rote LEDs, 5mm Durchmesser
• 80 Stk. npn-Transistoren BC639
• 80 Stk. 1kOhm Widerstände
• 40m Silberdraht, 1mm Durchmesser
• etwas Kleinmaterial

Es ist geschafft, die 8x8x8-Version funktioniert...!

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!

...und hier die Lösung: Tatsächlich hat der Tip, den ich vor einiger Zeit via Mail bekommen habe (Danke an denjenigen...!), zum Erfolg geführt. Eine minimale Änderung in der Interruptroutine, in welcher die LED-Daten für/an die nachgeschaltete Elektonik zusammengesucht und ausgeben werden, hat geholfen. Bevor man das Bitmuster der nächsten Zeile in das Schieberegister ausgibt, werden für die vorhergehend adressierte Zeile nochmal explizit LOW-Zustände in das Register geschoben und durchgeschaltet. Dies scheint zu reichen, um die Transistoren wieder sicher zu "sperren". Es war also keine Modifizierung der Schaltung notwendig!

[Bearbeiten] Schaltungen im Eagle-Format

Auf mehrfachen Wunsch hier die Eagle-Dateien der beiden Decoder-Varianten und des Fragments der Transistorschaltung.

[Bearbeiten] Software

[Bearbeiten] PC-Client (Kommunikationsprotokoll Client/Server)

[Bearbeiten] Allgemeines

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.
• get_led: fordert die Schaltzustände der LEDs an. Als Antwort wird von der Steuerung ein set_led <char[x*y*z]> zurückgegeben, also ein String, in dem eine "0" eine nicht leuchtende und eine "1" eine leuchtende LED kennzeichnet. Die Reihen folge ist die gleich, wie sie mit set_led gesendet wird. (Dieses Kommando ist nicht in allen Versionen der Mikrocontroller-Firmware enthalten!)

[Bearbeiten] Cube-Editor

Siehe Kapitel Cube-Simulator und -Editor!

[Bearbeiten] Cube-Pad

Cube-Pad

Das Cube-Pad ist eine kleine Tcl/Tk-Anwendung, mit der man via Mausbewegungen einen "LED-Cursor" in allen drei Dimensionen auf dem LED-Würfel bewegen kann. X- und Y-Richtung entsprechen der Bewegung des Mauszeigers in dem schwarzen Feld des Applikationsfensters, die Z-Richtung ist durch das Scroll-Rad der Maus steuerbar (der Mauszeiger muß sich dazu ebenfalls im schwarzen Feld befinden). Es kann zwischen kleinem (eine LED) oder großem (2x2x2 LEDs) Cursor umgeschaltet werden. Desweiteren gibt es einen rudimentären Zeichnungsmodus (überstrichene LEDs bleiben an). Die Kommunikation mit dem LED-Würfel erfolgt, wie gehabt, über das Ethernet.

Download Cube-Pad

[Bearbeiten] 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.
• In einer der letzten Version der Etherrape-Software ist die Möglichkeit der Steuerung über die vorhandene Infrarot-Schnittstelle enthalten. Es sind einige einfache Funktionen zum Schalten der LEDs implementiert (die verwendeten Tasten-Codes der IR-Fernbedienung sind dem Quelltext zu entnehmen):
  • Anschalten aller LEDs
  • Ausschalten aller LEDs
  • "Bewegen" einer leuchtenden LED mittels 6 Tasten der IR-Fernbedienung in allen 3 Richtungen

In dem Programmablaufplan erhält man einen groben Überblick über die Funktionsweise der Etherrape-Software.

Folgende Versionen der Firmware sind verfügbar:

• Firmware für Decoder (Version 1), ohne IR-Fernbedienung
• Firmware für Decoder (Version 2), ohne IR-Fernbedienung
• Firmware für Decoder (Version 1), mit IR-Fernbedienung

Die Installation von librape wird vorausgesetzt.

[Bearbeiten] Cube 2.0

[Bearbeiten] Hardware

Auf dem CLT2010 habe ich den "Openhardware Workshop" besucht und die dort angebotene Mikrocontroller-Baugruppe zusammengebaut. Prinzipiell ist dieses Teil ähnlich dem Etherrape aufgebaut und bildet nun das Herzstück meines LED-Cubes. Es fehlen lediglich der Dataflash und die Infrarot-Schnittstelle. Diese Baugruppe wird ausschliesslich mit 3,3V Betriebsspannung versorgt, was für den Rest der Cube-Schaltung nicht reicht. Aus diesem Grund musste zusätzlich eine kleine 5V-Spannungsquelle (auf Basis eines 7805) zur Versorgung des Decoders und der LEDs aufgebaut werden.

Ansonsten ist der Aufbau des Cubes gleich geblieben. Es gilt das, unter Cube 1.0, Gesagte. Als Decoder wird Variante 2 verwendet.

[Bearbeiten] Software

Webseite mit Cube-Status

Die Firmware des Mikrocontrollers hat sich grundlegend geändert. Die Basis bildet jetzt der IP-Stack von U.Radig, den er zu seinen AVR-Webmodulen implementiert hat und sehr leicht erweiterbar ist.

Cube-seitig hat sich in dem Zug das Kommunikationsprotokoll geändert: die LED-Daten werden mit dem Kommando set_led nicht mehr bitweise, sondern byteweise übertragen. Es werden also nicht mehr 512 Nullen oder Einsen gesendet, sondern schön verpackt in einer 128 Byte langen Hex-Zahl. Grund dafür war, dass ich schon in einer vorhergehenden Version der Firmware, das interne Abbild der LEDs auf ein 64-Byte-Feld reduziert hatte. Es bot sich also an, dies auch konsequent für die Kommunikation zwischen Client und Server (LED-Cube) so umzusetzen.

Desweiteren ist jetzt eine kleine Default-Animation hinzugekommen, wenn der Cube keine LED-Abbilder via Netzwerk bekommt. Und man kann sich den Status des Cubes über eine einfache Webseite anschauen. Es werden zum Cube die Dimension, das IP-Port, die Anzahl der aktiven Verbindungen sowie das gerade aktuelle Abbild es "LED-Anzeigepuffers" in hexadezimal aufgelistet. Letztendlich findet man auf der Webseite auch einige Angaben zur Firmware und den gemessenen Wert des Temperatursensors, der sich mit auf dem Board befindet.

Der Rest der Client-Software ist, bis auf die Abänderung des set_led-Befehles, gleich geblieben. Das Ganze (AVR-Firmware, Cube-Editor, Cube-Pad, diverse andere Clients und Cube-Simulator (in dem noch ein kleiner Bug ist...)) ist diesmal vollständig in diesem Archiv zu finden.

[Bearbeiten] Derzeitiger Stand

[Bearbeiten] 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
• Steuerung via IR-Fernbedienung
• Implementierung eines elektronischen Würfels (es ist hier ein Würfel mit den Zahlen von 1 bis 6 gemeint) innerhalb der Software auf dem Etherrape. Der "Ziehungsanstoß" erfolgt via IR-Fernbedienung
• 06.05.2008 - Der 8x8x8-LED-Würfel funktioniert!!! Ich habe mir mal wieder einen Stoß gegeben und endlich die letzten Baugruppen miteinander verbunden. Der anschließende Funktionstest ergab, dass auch die große Version prinzipiell, wie geplant funktioniert, es wird das angezeigt, was ich dem Mikrocontroller sende... Jetzt sind noch ein paar kleinere (ich hoffe es werden keine größeren) Problemchen zu lösen (siehe nächsten Unterpunkt).
• 07.05.2008 - Die groben Fehler beim Aufbau sind gefunden und behoben:
  • 2 kalte Lötstellen auf der Transistortreiberplatine und ein "Fehler in der Matrix" (2 Silberdrähte der LED-Matrix waren so verbogen, dass sie untereinander Kontakt hatten...)
  • das LED-Nachleuchten, welches beim 8x8x8-Würfel noch stärker zum Tragen kam, konnte durch eine kleine Softwareänderung eliminiert werden (siehe weiter oben).
• Juni 2008 - eine neue Version des Decoders aufgebaut: Um weitere I/O-Leitungen des Mikrocontrollers einzusparen, wurde eine neue Decoder-Schaltung entwickelt und aufgebaut sowie die Firmware entsprechend angepasst.

[Bearbeiten] Bekannte Probleme und was man dagegen tun könnte

• Die Helligkeit der LEDs ist geringer als in der 3x3x3-Version. Ich hoffe, dass ich dies mit einer Abänderung der Refreshrate im MC-Programm hinbekomme oder das auf einen Spannungseinbruch in der Stromversorgung zurückzuführen ist (was man durch ein leistungsstärkeres Netzteil korrigieren kann...).
  • hmm, das Problem stellt sich wohl mehr als Design-Fehler dar: die LEDs sind nicht alle insgesamt dunkler, sondern die Helligkeit variiert untereinander, je nach Konstellation der angeschalteten LEDs. Nach einigen grübeln ist auch klar warum: es werden werden ja derzeit 64 Zeilen zu jeweils 8 LEDs hintereinander durchgesteuert. Wegen einer kleinen Eigenwilligkeit von mir in der Schaltung (keine Vorwiderstände für die LEDs...) ist es elektrisch gesehen schon ein Unterschied, ob in einer Zeile 1, 2, ..., 8 LEDs an sind. Im Vergleich zu einer anderen Zeile, in der mehr oder weniger LEDs gleichzeitig an sind, ist dann die Hellikkeit entsprechend anders. Innerhalb einer Zeile sind die LEDs gleich dunkel oder hell. Derzeit sehe ich zwei Wege, diese Geschicht zu lösen:
    • halt doch nächträgliche Vorwiderstände einbauen, wenn man die Stelle halbwegs zentral wählt, wären dies 64 Stück (genau in den 64 Zuleitungen zu den senkrecht nach oben gehenden Säulen). Rein löttechnisch kein allzu großes Problem.
    • eine programmtechnische Lösung in der Ansteuerung. Statt der gleichzeitigen Ansteuerung von 8 LEDs, müsste man jede LED einzeln adressieren und ansteuern. Softwareseitig kein Problem, die Hardware würde es auch hergeben. Durch das eine Schieberegister in der Decoder-Baugruppe, sind es ein paar mehr Programmzeile, als wenn man dafür gleich einen 3aus8-Decoder verwenden würde. Problematisch könnte das Timing werden, denn bei einer Bildwiederholfrequenz von z.B. 60Hz liegen wir dann bei 30720 (512*60) Aufrufen pro Sekunde für die steuernde Interruptroutine (statt jetzt 64*60=3840). Bei einem Controllertakt von 20Mhz könnte das schon knapp werden, zumal er ja "nebenbei" auch noch andere Dinge erledigen soll (z.B. Ethernet-Schnittstelle). Muss man halt mal probieren...
• ich bin scheinbar an die Speichergrenzen im Mikrocontroller (SRAM für die dynamischen Variablen) gekommen: die ganzen zusätzlichen Spielereien, wie IR-Fernbedienung und autonome Animationen, hatte ich nur mit der 3x3x3-Version getestet. Durch die notwendige Erhöhung einiger dynamischer Felder auf die 8x8x8-Größe, scheint der Platz im Speicher etwas knapp geworden zu sein. Als Workarround habe ich erstmal allen Schnickschnack wieder rausgeschmissen und auf das Wesentliche beschränkt. Für alles andere werde ich mich wohl etwas eingehender mit den Speicherbereichen in einem Atmel-Mikrocontroller beschäftigen müssen...;-)

[Bearbeiten] 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))
• Steuerung des Würfels via Web-Browser

[Bearbeiten] Kontakt

Stand 01.07.2008 betrachte ich dieses Projekt als abgeschlossen! Ich werde mich jetzt auf ein neues Projekt stürzen, welches meine zur Verfügung stehende Zeit voll und ganz ausfüllen wird.

Die noch vorhandenen Unzulänglichkeiten (siehe oben) werden vielleicht irgendwann mal behoben, die Lösungswege dazu sind bekannt und beschrieben. Mit Sicherheit wird mit der Zeit die eine oder andere Client-Anwendung erstellt und dann auch hier vorgestellt werden...

Über Anregungen und Verbesserungsvorschläge würde ich mich jederzeit freuen. Für Fragen stehe ich zur Verfügung, garantiere aber keine sofortige Beantwortung...

Hinweis: Diese Seite ist nicht als Nachbauanleitung zu verstehen, sondern soll mehr den Verlauf des Projektes dokumentieren. Mich erreichen in letzter Zeit wieder verstärkt Mails von Leuten, in denen nach genauen Schaltplänen, Boardlayouts oder grundlegenden Dingen zu Hard- und Software gefragt wird. Diesen Leuten möchte ich folgendes mitteilen:

• bis auf die hier verlinkten Schaltbilder gibt es nichts anderes und das, was vorhanden ist, soll nur das Funktionsprinzip darstellen! Die Schaltungen sind im Verlauf des Projektes "historisch" gewachsen, auf Lochrasterplatinen aufgebaut und mehrmals modifiziert worden. Desweiteren weis ich, dass die Schaltung noch einige Unzulänglichkeiten aufweisen, die ich im Text der Webseite beschrieben, aber nie in irgendwelchen neuen Schaltbildern dokumentiert habe.
• es sei davor gewarnt, ein solches Projekt ohne etwas Grundlagenwissen und Verständnis über die Funktionsweise der verwendeten Bauteile und Software nachzubauen. Auch ich habe, nach jahrerlanger Elektronikabstinenz, eine Weile gebraucht diese Grundlagen wieder aufzufrischen.

In diesem Sinne wird es schwer sein, mich bei solchen grundsätzlichen Fragen zum Anworten zu bewegen!

Uwe Berger

[Bearbeiten] 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"
• Qube Solutions 5x5x5 Cubes als Bausatz mit Open-Source PC-Software