Hi, ich hab die Aufgabe einen RGB-LED-Cube zu bauen, der soll die Ausmaße 5x5x5 haben, also 125 RGB-Led's. Ich hab mir jetzt erstmal meinen Kopf gemacht und raus gekommen ist der Schaltplan, siehe Anhang. Da ich mich gerade in EAGLE einarbeite, hab ich leider die Exportfunktion zu png noch nicht gefunden, daher in pdf und auch so könnte sicherlich einiges noch besser sein. Es geht darum, ob das so funktionieren würde. RGB-Led's sind mit Common-Kathode. Es sind jeweils auf einer Ebene die Anoden gleicher Farbe verbunden. Die Kathoden sind in Säulen angeordnet, also 5x5 Kathoden Säulen und 3x5 Farbebenen. Damit kann ich vom Prinzip her jede LED einzeln ansteuern via multiplexing. Die Led werden jeweils über ULN/UDN getrieben und die Ansteuerung erfolgt über Schieberegister die via SPI am ATMEGA32 hängen. Nun ist die Frage, funktioniert das so wie ich mir das gedacht habe, oder bin ich komplett aufm Holzweg. Zum Zweiten: An den Atmega soll entweder noch USB via FT232 oder der Softwarelösung wie beim fischl-Programmer. Was wäre da empfehlenswert? Und dann bleibt da natürlich noch die letzte Frage: Schafft der AVR das überhaupt zu multiplexen oder muss ich mir da auch noch eine andere Lösung suchen? Herzlichen Dank schon im voraus, Jens
Ich würde hier den jeweils gemeinsamen Vorwiderstand (R1,R2,R3) pro Farbe als Schwachpunkt sehen. Wenn du mal mehr und mal weniger LEDs pro Seite und Farbe ansteuerst, dann werden die unterschiedlich hell sein. Denn der Vorwiderstand muss so groß sein, dass auch eine einzeln angesteuerte LED nicht kaputtgeht und den Strom für diese einzelne LED begrenzen. Werden dann alle LEDs angesteuert, dann wird der Strom (der ja für eine einzelne LED berechnet wurde) für alle zusammen nicht ganz reichen. Eigentlich müsstest du für jede LED einen eigenen Vorwiderstand spendieren. Bei überlegtem Programmaufbau reicht die Performance des uC locker aus, weil du ja nur 3 Scanzyklen hast (die 3 Farben). Da könnte man ohne Weiteres noch ein paar Helligkeitsstufen mit ins Spiel bringen. BTW: Das Multiplexen der Farbe über die Zeit bringt dann auch den von DLP-Beamern bekannte "Regenbogeneffekt" zustande. Bei Beamern lästig, könnte das für den Würfel eine Art Performance sein..... http://de.wikipedia.org/wiki/Regenbogeneffekt
Das mit den Vorwiderständen ist schon ok, wenn so gemultiplext wird, daß pro Widerstand immer nur eine LED angeschaltet wird. Das geht hier, wenn jeweils nur eine Säule in allen Farben leuchtet. Evtl. gibt es beim reinschieben der Daten unerwünschte Effekte, d.h. sehr kurzzeitiges Aufleuchten der falschen LEDs. Ein paar Helligkeitsstufen pro Farbe per PWM halte ich auch für möglich. Das Teil von "Das Labor" ist übrigens mit einem FPGA gemacht: http://www.das-labor.org/wiki/Farb_Borg_3d Jürgen
MoinMoin, Jürgen wrote: > Evtl. gibt es beim reinschieben der Daten unerwünschte Effekte, d.h. > sehr kurzzeitiges Aufleuchten der falschen LEDs. > dieses, tatsächlich auftretende, Problem löst man am besten, indem man sämtliche Ausgänge des Decoders, hier alle Schieberegister, programmtechnisch auf 0 schaltet, bevor man die neuen Daten reinschiebt. Also SCL kurzer Low-Impuls und via RCK in die Latches übernehmen. Grüße Uwe
Herzlichen Dank für eure Ausführungen, bin also auf dem richtigen Weg. Ich dachte so an 8-Bit PWM, das mit dem Regenbogeneffeckt wusste ich noch gar nicht. Ich hatte auch die Idee, die Farben auf einer Ebene immer in eine 5er Reihe zusammen zuschliessen,also nicht wie jetzt 15. Da würde ich aber pro Ebene dann ja 3x5 Farbreihen brauchen und auf den Cube hochgerechnet dann 75 Farbreihen die dann alle einen Vorwiderstand hätten. Wäre das eventuell empfehlenswerter? Gruss Jens
> Ich dachte so an 8-Bit PWM
Daraus wird so nichts werden, vielleicht geht 4 Bit
(rechne mal aus, wie lange das Laden der Schieberegister über SPI
dauert).
Jürgen
Du könntest die UDN2981 direkt an dem Atmega anschließen. Oder brauchst du die leeren Ports noch? Dann brauchst du nicht soviel schieben und wärst ein bisschen schneller.
Hab nun nochmal drueber nachgedacht, die Schieberegister fuer die udn`s fallen weg und kommen direkt an den Atmega, es wird jetzt noch ein ft232 angeschlossen werden fuer die Kommunikation mit dem PC. Die Farben auf einer Ebene lass ich auch im 15er "Pack" so wie es war, das solle mit dem multiplexen schon passen und 4-6 Bit Pwm sollte auch drin seien. Von daher nochmal herzlichen Danke, Jens
Hallo könntest du nun nochmal eine abschließende skizze machen was du jetzt wie und wo einbaust, ich wäre an diesem Thema auch interressiert. Danke
Siehe Anhang, ist jetzt die letzte Basis. Bin immer noch am löten der Led's, zieht sich hin, wenn man nicht viel Zeit hat, leider. Ft232 hab ich noch nicht da, deswegen erstmal normales uart. Gruß Jens
>> Ich dachte so an 8-Bit PWM >Daraus wird so nichts werden, vielleicht geht 4 Bit >(rechne mal aus, wie lange das Laden der Schieberegister über SPI >dauert). Es gibt noch einen zweiten Grund: Speicherplatz. Hast du mal ausgerechnet, welche VideoRAM du dazu brauchst?? 5x5x5 Cube mit je 3Leds (die Farben) ergibt: 375Leds = 375Bits = 47Bytes bei einer 8Bit PWM je Farbe ergibt das aber 375Bytes. Nur um anzulegen, welche Led mit welcher Farbe wie hell/an/aus ist. Weiterhin musst du dir vorher mal Gedanken über das genaue Mapping machen. Ich hab jetzt aber keine Lust, alles nochmal zu tippen, deshalb mal darauf verwiesen: Da geht es zwar um eine Propelleruhr, aber sonst ist das ja vergleichbar: Beitrag "Re: Schaltplan Rotordisplay"
Hallo Ich habe nochmal eine kleine Frage. Laut dem Datenblatt sind alle PB I/Os gleich. Kann ich nun die ISP buchse so wie sie hier angeschlossen ist (Mosi, Miso,sck...) anschließen und die Schieberegister auf PB0-4 ? oder würde das einen unterscheid machen und es letzt endlich nicht laufen? MfG
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.