Hallo zusammen, ich weiss, dass das Thema LED-Matrix hier schon bis zum Erbrechen durchgekaut wurde, aber fuer meinen Anwendungsfall sind die Infos eher spaerlich und bevor ich anfange, was Halbgares zusammenzuwurschteln, frage ich doch lieber nach: Ich benoetige eine 10x10-Matrix aus RGB-LEDs (zweidimensional, quadratisch). Die LEDs sollen einzeln zu schalten sein, aber die Farbe muss nicht einzeln einstellbar sein. Also wenn LED an, dann auch gleiche Farbe, wie alle anderen. Nun frage ich mich, wie ich das am Besten organisiere. Welchen ATMega schlagt ihr vor und wie lassen sich 10x10 RGB-LEDs am sinnvollsten ansteuern? Viele Gruesse und danke schonmal, Martin
Martin S. schrieb: > Nun frage ich mich, wie ich das am Besten organisiere. Welchen ATMega > schlagt ihr vor und wie lassen sich 10x10 RGB-LEDs am sinnvollsten > ansteuern? wie eine 30*10 Matrix
Eumel schrieb: > Welche Farbtiefe? Habe ich mir ehrlich gesagt noch keine grossen Gedanken drueber gemacht, sollte vom Aufwand her noch vertretbar sein. Das Spektrum sollte abgedeckt sein, ohne dass man beim kontinuierlichen Farbwechsel allzu grosse Spruenge wahrnimmt. Danke, Karlheinz... Die Frage (zugegeben: etwas unpraezise) zielte eher darauf ab, wie es am Besten zu loesen waere: Latches nehmen und pro Farbe einen Port spendieren (Mega32 z.B.?) oder doch Schieberegister?
Die Farbtiefe ist ziemlich wichtig. 8 bit pro Farbe wird mit einer Matrix schon etwas eng.
Eumel schrieb: > Die Farbtiefe ist ziemlich wichtig. 8 bit pro Farbe wird mit einer > Matrix schon etwas eng. Muss auch nicht sein, denke ich. Mit der Haelfte wuerde ich gut hinkommen.
Dann rechne dir mal die Multiplex Frequenz aus. 100 Hz sollten es bei jeder LED sein, für den gesamten Zyklus inklusive Dimmen natürlich.
> Das Spektrum sollte abgedeckt sein, ohne dass man > beim kontinuierlichen Farbwechsel allzu grosse Spruenge wahrnimmt. > > Die Farbtiefe ist ziemlich wichtig. 8 bit pro Farbe wird mit einer > > Matrix schon etwas eng. > Muss auch nicht sein, denke ich. Mit der Haelfte wuerde ich gut > hinkommen. Da widersprichst du dir aber gewaltig. Schon bei 8 bit sieht man Sprünge, bei 4 bit sind das krasse Stufen. 30 x 10 ist mit einem ATMega schaffbar, aber nur in Assembler mit geschickter Programmierung und schnell ansprechbarer Hardware, aber blaue LEDs die den für 1:10 Multiplexing notwendigen Strom aushalten ? Hast du mal eine Typennummer.
> Da widersprichst du dir aber gewaltig. > > Schon bei 8 bit sieht man Sprünge, bei 4 bit sind das krasse Stufen. Ja, habe nochmal drueber nachgedacht. Letztendlich sind die Uebergaenge eh nicht staendig zu sehen, also habe ich mit 4 bit genug Luft. Wenn es schon so hart an der Grenze ist: Wie wuerde man denn ansonsten an sowas drangehen?
30x10 hart an der Grenze? Mein großes LED Display hat 8x136 (16Seg Anzeigen) und der Mega32 langweilt sich. Das braucht bei 100Hz ne ISR Aufruffrequenz von 1kHz und mit BAM 8KHz, sind 2000 Befehle bei 16MHz. Also nen neueren AVR mit 20MHz einplanen. Dimmen kannste mit Bit Angle Modulation, das is recht ressourcenschonend.
Danke schonmal fuer eure Hinweise. Ich habe gerade den TLC5940 gefunden, wie waere es damit? Damit die LEDs in einer Spalte ansteuern und die Zeilen dann multiplexen. Oder gleich mehr von den Dingern spendieren und ganz aufs Multiplexen verzichten?
> 30x10 hart an der Grenze? Bei 8 bit PWM für die Helligkeit. > Bit Angle Modulation Richtig. Wobei, wenn alle gleich gedimmt werden, könnte man sogar hardwaremässig mit OE/CLR durch einen Timer drangehen wenn man synchron zum Timer die Wiederholfrequenz setzt. Dann reicht der ATmega für 256 x 30 x 10 LED :-)
Martin Wende schrieb: > Das braucht bei 100Hz ne ISR Aufruffrequenz von 1kHz und mit BAM 8KHz, > sind 2000 Befehle bei 16MHz. 8 Takte für BAM? Das sind starke 3bit. Der Vorteil von BAM ist doch gerade dass in Assembler >12bit selbst für 1000 Leds machbar ist.
MaWin schrieb: > Dann reicht der ATmega für 256 x 30 x 10 LED :-) Da würde ich mir eine genauere Erklärung zu wünschen. Hört sich interessant an!
Ich habe mich mal ein bisschen in die TLC5940-Materie eingelesen. Was haltet ihr hiervon? PWM mit je einem TLC pro Farbe generieren und dann die 10 Zeilen multiplexen?
Martin S. schrieb: > Ich habe mich mal ein bisschen in die TLC5940-Materie eingelesen. Was > haltet ihr hiervon? > PWM mit je einem TLC pro Farbe generieren und dann die 10 Zeilen > multiplexen? schau dir mal die ausgangsstufen vom tlc an...das geht so nicht...
Einfach 20 TLC wäre was. 12 bit pro Farbe, keine Treiber mehr etc. Eine Möglichkeit.
Ach ja, bei 12 bit sieht man auch wirklich keine Übergänge mehr. Auch bei sehr langsamen faden.
@Andi: Sorry, ich stehe auf dem Schlauch. Was geht deiner Meinung nach so nicht? @Eumel: Und meinte Loesung, nur 3 TLCs zu verwenden und die Zeilen dann zu multiplexen? Machbar?
Die FETs sind falschrum... 10k Gatewiderstand ist auch weit entfernt von dem was da hingehört. Zudem sind das NFE und keine PFET. Hab dir da mal was im Anhang hinterlassen.
> Da würde ich mir eine genauere Erklärung zu wünschen. Hört sich > interessant an! Na wenn man PWM per Timer OC1A an OE der Treiber (z.b. 74HC595) in Hardware macht, dann hat der Prozessor die ganze Multiplexzeit von 100 Hz * 10 = 1ms Zeit um die Daten an die Treiber zu schicken weil er sich um nichts anderes kümmern muß. 1ms sind bei 16MHz 16000 Instruktionen, damit kann man schon 256 * 30 = 7680 bits = 1000 Bytes mit dem aktuellen Bild an die LED schicken, wenn die Hardware passend ist (akzeptiert auch Bytes statt Bits, z.B. durch 8 Schieberegister parallel).
Martin Wende schrieb: > Die FETs sind falschrum... > 10k Gatewiderstand ist auch weit entfernt von dem was da hingehört. > Zudem sind das NFE und keine PFET. > > Hab dir da mal was im Anhang hinterlassen. Danke, ja. Ist mir bewusst. Ich war noch auf der Suche nach passenden P-FETs (die gibts ja schoen zu zweit im Gehaeuse, leider nur SMD). Deswegen hab ich schnell irgendwas genommen und dabei nen N-Channel erwischt. War nicht so geplant. Geht nur generell um den Aufbau, ob das vom Prinzip so hinhauen kann.
Aber schnall trotzdem nochn Bustreiber IC vor. Der kann etwas mehr Strom treiben, trotzdem hat das im Bild noch 6µS Falltime. Das Ghosting dadurch ist aber nur bei 100% Helligkeit und dunklem Raum zu sehen.
MaWin schrieb: > Na wenn man PWM per Timer OC1A an OE der Treiber (z.b. 74HC595) > in Hardware macht, dann hat der Prozessor die ganze Multiplexzeit > von 100 Hz * 10 = 1ms Zeit um die Daten an die Treiber zu schicken > weil er sich um nichts anderes kümmern muß. > > 1ms sind bei 16MHz 16000 Instruktionen, damit kann man > schon 256 * 30 = 7680 bits = 1000 Bytes mit dem aktuellen > Bild an die LED schicken, wenn die Hardware passend ist > (akzeptiert auch Bytes statt Bits, z.B. durch 8 > Schieberegister parallel). Ah, Ok. Und mit dem Timer wird dann einfach nur das neue Ausgabemuster aktiviert?
Martin Wende schrieb: > Aber schnall trotzdem nochn Bustreiber IC vor. > Der kann etwas mehr Strom treiben, trotzdem hat das im Bild noch 6µS > Falltime. > Das Ghosting dadurch ist aber nur bei 100% Helligkeit und dunklem Raum > zu sehen. Danke fuer den Tipp. Hab ich mal noch gemacht und das Ganze etwas aufgeraeumt. Gibts noch Meinungen zu dem Konzept an sich?
> Und mit dem Timer wird dann einfach nur das neue Ausgabemuster > aktiviert? Der Timer macht 2 Dinge: Er sagt, wann das nächste Multiplex-Zeile drankommt. und er sagt, wie viel Prozent der Zeit die LED an sind (und den Rest der Multiplexzeit aus) und bestimmt damit die Helligkeit des GESAMTEN Displays (alle LEDs gleich hell, die einfache Anforderung von Martin S. ). Wie ich gerade lese, RGB, also 3 PWM Ausgänge. Welcher ATMega kann 3 ? Ich glaube, schon der ATmega8.
Martin Wende schrieb: > Äh, wenn A->B die Richung sein soll, dann muss DIR auf 5V. > B->A ist GND Grmpf. Vielen Dank! Ich sitze echt schon zu lange daran heute.
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.