Important announcement: there is an English version of this forum on 
Hallo, in meiner Freizeit habe ich mich mit dem Bau eines 8x8x8 LEDcubes beschäftigt. Klar, die Idee ist nicht neu. Dennoch möchte ich meine Ergebnisse (Dokumentation, Schaltplan, Layout, Software) der Community zur Verfügung stellen. Kurze Beschreibung: 8x8x8 LEDcube mit blauen LEDs Atemega32 mit Software in C Konstantstromtreiber pdf-Dokumentation: http://dreadnought.dr.ohost.de/LEDcube/LEDcubeProj... Schaltplan/Layout (Eagle): http://dreadnought.dr.ohost.de/LEDcube/EagleSteuerung.zip Software (GNU license): http://dreadnought.dr.ohost.de/LEDcube/LEDcubeSoft... Ein Video mit Animationen findet man bei youtube unter Youtube-Video "LED cube 8x8x8" Zum Led cube gibt es noch eine passende Stromversorgung (5V, 12W). Dabei handelt es sich um einen quasiresonanten Flyback mit valley-switching/valley-skipping und ausgangsseitiger Synchrongleichrichtung. Er erfüllt sichere Netztrennung nach DIN EN 60065 und DIN EN 61558; leitungsgebundene und abgestrahlte Störungen nach DIN EN 55011 und Surgefestigkeit nach DIN EN 61000-4-5. Bauhöhe ist 8mm (ohne Filter, 10mm mit Filter). Es gibt aber (noch) keine Dokumentation dazu. Schaltplan/Layout (Eagle): http://dreadnought.dr.ohost.de/LEDcube/EagleFlyback.zip Auch wenn das Projekt abgeschlossen ist, für konstruktive Verbesserungsmöglichkeiten bin ich offen. (Man will sich ja weiterentwickeln.) Natürlich auch für Fragen.
Datum:
einfach geil .. sehr schöne Effekte
Datum:
Ja, und hut ab für die Doku! hier ein Link: http://www.mikrocontroller.net/articles/LED_cube hat geringfügig Ähnlichkeit :-) TS
Datum:
...was mich mal interessieren würde: Sind es Bilder die nacheinander abgespielt werden? Die Laufschrift zum beispiel könnte eine Funktion sein, die einen Buffer auf einen String übergeben bekommt, und spielt diesen dann ab. Oder ist es eine Funktion die eine Grafik übergeben bekommt und diese an den 3 Seiten des Würfels ablaufen lässt? Diese erhält dann wiederum aus einem Zeichensatzspeicher die Information wie die Zeichen Aussehen, und der Zeichendatzspeicher erhält aus einem STring die Information welcher Buchstabe als nächstes kommt? Die Softwarestruktur ist immer interessant. Genauso wie die einzelnen Lämpchen die beim Bewegungsstart einer LED Ebene dann scheinbar wahllos stehen bleiben, Zufall? Wo und wann? Oder alles im Speicher festgelegt? Wie festgelegt? Dann zum Schluss, dieser schwingende "Zuckerhut" oder Glockenform? Eine Form vorgegeben und eine Funktion die es bewegt, oder Bilder aus dem Speicher? Bei dem zoomenden 3D Würfel, scheint es mir einfacher. Eine feste Ecke, und dann die Kantenlänge. Dann hätte ich im Speicher, min max - feste ecke (XYZ) zoomgeschwindigkeit? und dann würde man die feste Ecke wechseln und wieder loslegen? Oder sind es allegemeindere Funktionen, die alles Zoomen oder bewegen? Gruß, TS
Datum:
Sehr gute Choreografie!
Datum:
Ein Wort: Wahnsinnsdoku. Mich würd dein IC fürs Flyback-Netzteil noch interessieren :-)
Datum:
wo es dann richtig heftig wird: Youtube-Video "3D LED Cube Laying Screen Flight of the Phoenix" JJ
Datum:
Vielen Dank erst mal für die positive Resonanz von Allen. TS schrieb: > ...was mich mal interessieren würde: Sind es Bilder die nacheinander > abgespielt werden? Die kompletten Frames der Animationen einzeln abzuspeichern ist wegen der Speichergröße nicht möglich. Während ein Frame angezeigt wird, wird der nächste berechnet. Teilweise muss natürlich was im Flash abgelegt werden. TS schrieb: > Die Laufschrift Die Buchstaben sind im Speicher abgelegt. Der Animationsfunktion übergebe ich einen String mit dem gewünschten Text. Die Funktion gibt die Buchstaben zeilenweise hinten aus und lässt den Würfelinhalt immer um eine Position rotieren. TS schrieb: > schwingende "Zuckerhut" oder Glockenform Das ist die Funktion sin(t+sqrt(x^2+y^2)). Das will man auf dem ATmega aber natürlich nicht rechnen. Unter Ausnutzung von räumlicher und zeitlicher Symmetrie sind einzelne Daten abgespeichert, die dann zusammengesetzt werden. Zu den Bewegungabläufen: Die sind pseudo-zufällig. rand()-Funktion Bei tieferem Interesse einfach mal in den Code reinschauen.
Datum:
Floh schrieb: > Mich würd dein IC fürs Flyback-Netzteil noch interessieren :-) TEA1522 von NXP
Datum:
Wahnsinn! Sehr schöne Doku, gut dokumentierter Quellcode - was will man mehr? Darf man denn fragen wie lange dich das Ganze beschäftigt hat? Sowohl von der Hardware her, als auch die Software. Gerade die Idee die Buchstaben "quer" zu speichern gefällt mir gut. Da wäre ich so schnell wohl nicht drauf gekommen ;). Hast du da eigentlich irgendwelche speziellen Werkzeuge (in Form von Software) verwendet, um dir die Bitmuster zu generieren? Oder hast du das wirklich per Hand eingehämmert? Bin auch gerade am Basteln eines Cubes, beschränke mich zunächst aber auf 5x5x5, um ein wenig Erfahrung im Umgang mit den Materialien zu sammeln ;). Werde aber, sofern ich mal einen 8x8x8 Cube bauen sollte, auf dein Projekt zurück kommen. Übrigens: Du solltest in Erwägung ziehen einen eigenen Artikel im Wiki zu erstellen. Der andere Artikel ist zwar auch schön und gut, aber deiner übertrifft das Ganze dann nochmals.
Datum:
Hallo Alex, ich kann mich meinem Vorredner nur anschliessen. Echt tolle Leistung von Dir ;-) Könntest Du auch ein paar Bilder von der bestückten Platine hochladen? Woher hast Du die Bauteile bezogen? Den MAX6968 habe ich nur auf Digi-Key gefunden. Gruss Alois ;)
Datum:
Das ist der absolute Hammer! Ich zolle dir großen Respekt für dieses Projekt. Du machst keine halben Sachen, einfach genial.
Datum:
Das ist genau die Doku, die Stefan S. in Beitrag "Tutorial 10x10x10 LED-Cube" so vollmundig erstellen wollte. Leider ist dein Cube nur für dunkle Zimmer geeignet, weil ganz ohne Not statt 120mA Treibern wie CAT4016 oder PCA9626B nur 35mA für 1/8 der Zeit, also 4.75mA, durch die LEDs geschickt werden.
Datum:
Karol Babioch schrieb: > Hast du da eigentlich > irgendwelche speziellen Werkzeuge (in Form von Software) verwendet, um > dir die Bitmuster zu generieren? Oder hast du das wirklich per Hand > eingehämmert? Ein kariertes Papier und Bleistift für Skizzen reichten mir, um sich zu überlegen, welche Operationen durchgeführt werden müssen. Lediglich bei der sin(t+sqrt(x^2+y^2) Animation habe ich zusätzlich Matlab benutzt um es vorab zu simulieren. Alois Neumann schrieb: > Woher hast Du die Bauteile bezogen? Den MAX6968 habe ich nur auf > Digi-Key gefunden. Die Bauteile für die Steuerung habe ich bei Farnell bestellt, die Teile für den Flyback bei Mouser. Den MAX6968 gibt es aber anscheinend bei Farnell nicht mehr, Mouser hat ihn aber noch im Programm. MaWin schrieb: > nur 35mA für 1/8 der Zeit, also 4.75mA, durch die LEDs > geschickt werden. Der von mir benutzte Treiber kann maximal 55mA pro Kanal. ich habe mich dennoch für "nur" 33mA pro LED entschieden. Vorab habe ich das ganze mit verschiedenen Strömen getestet und für meine Belange war das ausreichend. Sind trotzdem 6,7W LED-leistung. Aber Du hast natürlich recht, wer mehr Leistung will/braucht, sollte einen Treiber für höhere Ströme wählen.
Datum:
Ich habe noch eine kurze Frage zum Quellcode. Wieso ziehst du beim Berechnen der Werte für die Interrupts jeweils 1 ab, z.B. bei folgender Berechnung:
#define OCR2value ((F_CPU/(F_Refresh * 8 * 128)) - 1) |
8 dürfte ja für die Anzahl der Zeilen stehen und 128 ist der Vorteiler. Da es sich bei allen um Ganzzahlen handelt, müsste doch der "Rest" sowieso abgeschnitten werden? Übrigens: Du solltest Konstanten vielleicht immer komplett groß schreiben, also z.B. F_REFRESH.
Datum:
Unlucky2012 schrieb: > Ich habe noch eine kurze Frage zum Quellcode. Wieso ziehst du beim > Berechnen der Werte für die Interrupts jeweils 1 ab, z.B. bei folgender > Berechnung: > #define OCR2value ((F_CPU/(F_Refresh 8 128)) - 1) Für die Bildwiederholfrequenz benutze ich den Timer2 im CTC-Mode. Gemäß Datenblatt berechnet sich die Frequenz zu f_OC = f_CPU / (2*N*(1+OCR)) Daher der Offset von -1 beim Umstellen. Unlucky2012 schrieb: > Übrigens: Du solltest Konstanten vielleicht immer komplett groß > schreiben, also z.B. F_REFRESH. Gebe ich Dir Recht, habe ich nicht konsequent durchgezogen.
Datum:
Alex X. schrieb: > Zum Led cube gibt es noch eine passende Stromversorgung (5V, 12W). Dabei > handelt es sich um einen quasiresonanten Flyback mit > valley-switching/valley-skipping und ausgangsseitiger > Synchrongleichrichtung. Er erfüllt sichere Netztrennung nach DIN EN > 60065 und DIN EN 61558; leitungsgebundene und abgestrahlte Störungen > nach DIN EN 55011 und Surgefestigkeit nach DIN EN 61000-4-5. Bauhöhe ist > 8mm (ohne Filter, 10mm mit Filter). Es gibt aber (noch) keine > Dokumentation dazu. Wie hast du die ganzen DIN normen geprüft? Tolle Doku!
Datum:
Übrigens müsste das PWM "fehlerhaft" sein. Du verwendest ja zwei verschiedene Timer für die Bildwiederholungsfrequenz und das PWM. Ohne weitere Vorkehrungen laufen diese "asynchron". Das heißt es gibt keine Garantie, dass die LEDs, die du ein- und ausschaltest auch diejenigen sind, die du ein- und ausschalten willst. Ich habe das eben durchgerechnet: OCR2value beträgt bei deinen Angaben (16 MHz, 100 Hz Refreshrate) 155, während OCR0 255 beträgt. Eine (vielleicht) einfach zu implementierende Lösung wäre es nur einen Timer für die beiden Funktionen zu benutzen.
Datum:
dummeFrage schrieb: > Wie hast du die ganzen DIN normen geprüft? Ich habe sowohl Zugang zu den DIN Normen, als auch Zugang zum nötigen Equipment um deren Einhaltung zu überprüfen. Unlucky2012 schrieb: > Übrigens müsste das PWM "fehlerhaft" sein. Du verwendest ja zwei > verschiedene Timer für die Bildwiederholungsfrequenz und das PWM. Ohne > weitere Vorkehrungen laufen diese "asynchron". Richtig, dass ist nicht optimal gelöst. PWM-Dimmen war ursprünglich gar nicht vorgesehen, sondern wurde nachträglich noch schnell "reingebastelt". Eine Ebene wird für 1.25ms angezeigt, die PWM fürs Dimmen läuft auf 7800kHz. Das sind nur ca. 10PWM-Zyklen pro Ebene, eigentlich zu wenig mit der Asynchronität. Die eine Ebene würde im worst case die on-Zeit des letzten PWM-Zyklus bekommen, während die nächste dann die restliche Off-Zeit bekommt. Eine Schwebung in der Helligkeit der einzelnen Ebenen könnte entstehen, wenn man Glück hat mittelt es sich raus. Ich habe jetzt nur eine Animation mit Dimming, wo die Helligkeit durchgesweept wird. Da fällt nichts auf. Wer es also vernünftig machen will, wie Unlucky2012 schrieb, 1 Timer benutzen oder halt beide Timer synchron laufen lassen.
Datum:
Alex X. schrieb: > Für die Bildwiederholfrequenz benutze ich den Timer2 im CTC-Mode. Gemäß > Datenblatt berechnet sich die Frequenz zu > f_OC = f_CPU / (2*N*(1+OCR)) > Daher der Offset von -1 beim Umstellen. Wo ist eigentlich die "2" beim Umstellen hin ;)?
Datum:
Übrigens ist mir noch ein Kritikpunkt aufgefallen. Ich habe mich mit der Doppel- und Dreifachpufferung auseinandergesetzt. Du verwendest ja eine Doppelpufferung. Nur fehlt bei dir die Synchronisierung zwischen der Darstellung und der Markierung, dass das Bild jetzt fertig ist. Du markierst ja ein Bild als "ready" und der nächste Timer1 Interrupt wechselt dann die beiden Puffer, unabhängig davon wo sich die Anzeige gerade befindet. Dabei kommt es (zumindest theoretisch) zum Tearing, d.h. es wird ein Teil des "alten" wie auch vom "neuen" Bild dargestellt. Im Video sieht man diesen Effekt nicht. Ich nehme an, dass du "live" auch nichts davon bemerkst, oder? Ich denke das wird wohl auch durch das Multiplexing abgemildert, da du ohnehin mit 100 Hz arbeitest. Denn es dürfte recht schwierig werden das in den Griff zu bekommen, da man beide Interrupts in irgendeiner Form synchronisieren müsste ohne es zu sehr zu blockieren.
Datum:
Unlucky2012 schrieb: > Wo ist eigentlich die "2" beim Umstellen hin ;)? Die Formel im Datenblatt gibt die waveform frequency an (Ausgang toggelt bei compare match). Ich benutze den Interrupt beim Compare Match für konstante Zeiten. Deshalb nochmal der Faktor 2. Unlucky2012 schrieb: > Du markierst ja ein Bild als "ready" und der nächste Timer1 Interrupt > wechselt dann die beiden Puffer, unabhängig davon wo sich die Anzeige > gerade befindet. > Dabei kommt es (zumindest theoretisch) zum Tearing, d.h. es wird ein > Teil des "alten" wie auch vom "neuen" Bild dargestellt. Stimmt, war mir vorher noch gar nicht so bewusst. Danke für den Hinweis. Unlucky2012 schrieb: > Im Video sieht > man diesen Effekt nicht. Ich nehme an, dass du "live" auch nichts davon > bemerkst, oder? Ich denke das wird wohl auch durch das Multiplexing > abgemildert, da du ohnehin mit 100 Hz arbeitest. Live ist mir auch noch nichts aufgefallen. Unlucky2012 schrieb: > Denn es dürfte recht schwierig werden das in den Griff zu bekommen, da > man beide Interrupts in irgendeiner Form synchronisieren müsste ohne es > zu sehr zu blockieren. Ich könnte erst die Verweise tauschen, wenn nicht nur das Flag auf ready steht, sondern auch der Ebenenzähler auf 8 (=letzte Ebene). Dann würde kein Tearing auftreten, aber ich erhalte einen leichten Jitter in der Bildrate. Bei Bildraten in der Größenordnung der Bildwiederholfrequenz wären dann hier wieder Probleme. Solange man nichts sieht, lasse ich es mal so. Ansonsten könnte man noch die Bildwiederholfrequenz hochsetzen um den Effekt zu minimieren.
Datum:
Alex X. schrieb: > Die Formel im Datenblatt gibt die waveform frequency an (Ausgang toggelt > bei compare match). Ich benutze den Interrupt beim Compare Match für > konstante Zeiten. Deshalb nochmal der Faktor 2. Dann kann man sich nach meinem bescheidenen mathematischen Verständnis auch die "-1" sparen. Die ist ja dann nur da, um zu verhindern, dass keine "halbe" Welle (sprich nur ein Toggle) mit reinkommt. Alex X. schrieb: > Ich könnte erst die Verweise tauschen, wenn nicht nur das Flag auf ready > steht, sondern auch der Ebenenzähler auf 8 (=letzte Ebene). Das entspräche dann gewissermaßen dem "VSync", siehe hier (https://de.wikipedia.org/wiki/Doppelpufferung) und hier (https://de.wikipedia.org/wiki/VSync). Einen Jitter dürfte es aber nicht geben. Es sind dann halt nicht mehr alle Frameraten möglich bzw. sinnvoll. Im "schlimmsten" Fall befindet sich das Multiplexing dann in Ebene 1 und muss warten bis Ebene 8 fertig dargestellt ist. Erst dann kann der Wechsel erfolgen. Dadurch verzögert sich der Wechsel und es gibt effektiv weniger Bilder pro Sekunde. Die einzelnen Ebenen müssten aber nach wie vor gleichmäßig beleuchtet sein. Problem dürfte sein, dass es dann dazu kommen könnte, dass der zweite Framebuffer befüllt ist und noch kein Tausch stattgefunden hat. Dann kann nicht weiter gerechnet werden. Die Interrupts treffen aber nach wie vor ein und "verschwenden" ein paar Zyklen. Dem könnte man mit der Dreifachpufferung (https://de.wikipedia.org/wiki/Dreifachpufferung) entgegenwirken ;).
Datum:
Kannst du mal ein Video hochladen wo du den Würfel im hellen am laufen hast?
Datum:
Hallo Alexander, wir sind gerade dabei auch so einen 8x8x8 led cube zu bauen nach deiner Anleitung. Unser Problem ist wir bekommen die daten nich auf unseren atmega 32. wir haben schon so viel ausprobiert , könntest du uns dein geheimniss verraten
Datum:
Moin, In der berufschule haben wir eine projektarbeit daher würde ich gern mit dir sprechen wenn es für dich in ordnnung wäre. wir sind zu zweit und wollen einen 8x8x8 cube nachbauen daher haben wir viele fragen wäre nett wenn wir kontakt aufnehmen können.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten