RGB LED Treiber

zu langsam ;) 32 RGB LEDs, sinnvoll ist dann eine "Display" Auflösung 
von 8 * 32 = 256 Spalten. Statt nun die Helligkeit per PWM einstellen zu 
wollen kann man auch einfach die Anzahl der Spalten erhöhen. Für zb. 64 
Farben = 6 Bits = 2 Bit pro Farbe ergibt sich ein "PWM" Muster von 3 
Bits ->

1

Farbe   PWM

2

  00    000  

3

  01    010

4

  10    101

5

  11    111

Das heist dann 256 Spalten * 9 PWM Bits = 2304 PWM Zyklen pro Umdrehung. 
Bei 3600 U/min -> 60 U/sec -> 16.7ms pro Umdrehung / 2304 = 7.23 µs pro 
PWM Cyclus. Macht eine Ansteruerungfrequenz von 138KHz. Der Max Baustein 
müsste also minimal 138KHz PWM machen damit du 256 Pixelspalten in 64 
Farben darstellen kannst, schafft er glaube ich nicht. Du wirst bei 
immmer größeren Frequenzen auch Probleme mit den LEDs selber bekommen 
(brauchst höheren Strom), da die Kapazitäten der LEDs nichts zu 
vernachlässigen sind.

Die TLCxxx Teile haben so hohe PWMs -> bis 2Mhz glaube ich. Aber auch 
hier macht es im Grunde wenig Sinn, denn du musst ja sowieso die 
Farbbytes aus dem Speicher dekodieren, auf die RGB LEDs austeilen nach 
Farbe und für jede Pixelspalte immer wieder erneut diese Daten senden. 
Die TLC Teile haben 3 Vorteile:

1.) man kann den LEDs Strom per Sowftware feinjustieren, sprich LEDs 
untereinander abgleichen. Das sparrt die Vorwiderstände. Höhere Ströme 
möglich bis zu 80mA pro LED
2.) 16 Ausgänge statt nur 8 wie bei normalen Shiftregistern
3.) kleine Bauformen

Für die Dekodierung der Farbbytes und die Ansteuerung der Shiftregister 
wird folgendes die einfachste Lösung auf einem AVR sein:

Ein 6 Bit Port des AVRs, hier mal PortD

1

  PD5 -|

2

  PD4 -|-- Input Rot Shiftregister

3

4

  PD3 -|

5

  PD2 -|-- Input Grün Shiftregister

6

7

  PD1 -|

8

  PD0 -|-- Input Blau Shiftregister

Wie man sieht werden die Shiftregister nach Farbe getrennt kaskadiert. 
Es gibt dann 1 Shiftregister Takt für alle Register, 1 Shiftregister 
Enable für Alle, und 3 Shiftregister Dateneingänge pro Farbe einer. Man 
schiebt also alle 3 Farben in parallel raus.

Die Pins des PortD sind die Datenausgänge. Dabei wird aber zb. PD1 auf 
Input und PD0 auf Output oder PD1 auf Output und PD0 auf Input 
geschaltet. Wir haben also einen 2 zu 1 Multiplexer aufgebaut. Und über 
DDRD-> Datenrichtungsregister selektieren wir.

Unser Farbbyte -> 6 Bits -> 64 Farben wird nun einfach auf PortD 
ausgegeben. Über DDRD bestimmen wir welches der 2 Bits pro Farbe 
gesendet wird. Ist PD0/PD1 auf Output/Input gesetzt senden wir das 
unterste Farbbit pro Farbe, bei Input/Output senden wir das obere 
Fabrbit.

Die ISR die nun deine Daten sendet muß 2 Dinge machen:

- Datenrichtungsregister -> DDRD entspechend setzen 
(Multiplexer/Farbbitdekoder)
- 32 Bytes der Pixelspalte X auf PortD ausgeben
- nach jedem Byte logischerweise den Shiftregistertakt toggeln
- nach den 32 Bytes Shiftregister Enable/Store/Latch wieder toggeln

Das macht dann 32*3 + 2, minimal 98 MCU Takte in dieser ISR. Zur 
Verfügung hast du 7µs Pro ISR.

Nochmal:
- du hast 256 Pixelspalten, 64 Farben pro Byte/Pixel
- jede Pixelspalte wird 3 mal hintereinander ausgegeben
- über DDRD bestimmst du welches Pixelbit dabei angezeigt wird
- mit Hilfe vom DDRD und den extern zusammengeschalteten PINs des PortD 
bauen wir 3 2 zu 1 Multiplexer auf und sparen so enorm viel MCU Takte in 
Software die ansonsten nötig wären für die Farbdekodierung.
Klar dürfte sein das du DDRD niemals falsch einstellen darfst, von den 2 
zusammengeschateten Pins sollte immer einer auf Input und der andere auf 
Output sein.
- legst du den Takt der Shiftregister ebenfalls auf PortD so kommst du 
auf minimal 100 MCU Takte pro Pixelspalte in deiner ISR


Gruß Hagen

>>Das heist dann 256 Spalten * 9 PWM Bits = 2304 PWM Zyklen pro Umdrehung.
>>Bei 3600 U/min -> 60 U/sec -> 16.7ms pro Umdrehung / 2304 = 7.23 µs pro
>>PWM Cyclus.

Sorry kleiner Fehler drinnen. Wir steuern ja alle 3 Farben gleichzeitig 
an. Für 2 Bits pro Farbe also 3 mal. Macht dann nur 3 Ansteuerungen pro 
Pixelspalte.

256 Spalten * 3 = 768 Zyklen pro Umdrehung -> 1  60  768 = 22µs pro 
Zyklus. Also alle 22µs wird deine ISR aufgerufen, und 3 mal 
hintereinander wird die gleiche Pixelspalte ausgegeben. Das erste mal 
DDRD so gesetzt das das unterset Farbbit multiplext wird, das nächste 
mal das oberste Farbbit und dann nochmal das unterset Farbbit. Fertig 
ist deine Pixelspalte in 64 Farben pro Pixel.

Bei 16MHz Takt hast du 347 Takte Zeit in der ISR, das heist der AVR ist 
zu rund 33% ausgelastet mit der Darstellung des Displays/Füllen der 
Shiftregister.

Gruß Hagen

liegt auf Eis. Das Problem ist nicht die Software sondern die Hardware 
der LEDs. Mit den TLCxxxx Teilen hat man zwar schön kleine Treiber, aber 
das Layout des Armes auf denen die LEDs sitzen ist meiner Meinung nach 
nur 4 lagig hinzubekommen. Viel zu kompliziert für mich. Ausserdem hat 
man bei zb. ab 32 RGB-LEDs mit einem AVR nicht mehr genügend 
Rechenpower. In der Ausbaustufe die ich mir vorstellte bekommt man an 
jeder Ecke Probleme. Stromversorgung geht in mehrere Ampere, LEDs sind 
teuer wenn man saubere Farben haben möchte, Layout ist kompliziert und 
das wird teuer, Software braucht viel RAM usw. usw. Also alles Sachen 
die mich überfordern. Wenn ich mal genügend Kohle übrig habe, und die 
Zeit, packe ich das aber nochmal an.
Dann aber nicht mit einem AVR.

Gruß Hagen

bei 8 Farben == 3 Bit pro Pixel brauchst du nur den PortD anders 
verdrahten. Zb.

1

  PD0--------|---------- Blau

2

  PD1--------+--|------- Grün

3

  PD2--------+--+--|---- Rot

4

             |  |  |

5

  PD3 -> NC  |  |  |

6

             |  |  |

7

  PD4--------|  |  |   

8

  PD5-----------|  |

9

  PD6--------------|

10

11

  PD7 -> NC

in einem Byte stehen dann 2 Pixel der Display Spalten. Zuerst setzt DDRD 
so das PD0 bis PD2 auf Ausgang sind, und PD4 bis PD6 auf Input. Nun 
gibts du auf PORTD das Byte aus. Danach Takt toggeln und dann DDRD so 
setzen das PD0 bis PD2 aug Input und PD4 bis PD6 auf Output sind. Nun 
noch mal Takt toggeln. Schwups hast du 2 Pixel kodiert in einem Byte an 
die 3 Shiftregister gesendet.

Die selber Dekoder/Multiplexer Logik funktioniert auch hier. Wenn du die 
TLC Teile benutzt dann kannst du ja über RExt den Strom einstellen. Hast 
du nun deine Shiftregister pro Farbe kaskadiert kannst du über diese 
RExt Widerstände also die Farben Blau,Rot,Grün nachjustieren. Die 
Trennung der Register hat also Vorteile, mal abgesehen davon das der 
Verdrahtungsaufwand eben leicht komplexer ist.

Gruß Hagen

>>Nehme ich also den ON/Off Mode, muß ich für 16 RGB LEDs, 3x TLC,

korrekt

>> 8 Byte Bilddaten erzeugen und übertragen.

Korrekt.

>> Jedes Byte beinhaltet 2 Pixel.

Korrekt.

>>Also jedes Byte 2x schieben, erst das obere Halbbyte, dann das untere
>>Halbbyte.

Ja korrekt. Allerdings lädst du diese Byte nur einmalig in PORTD und 
ändert das DDRD Register damit du entweder das Low- oder Hi-Nibble 
multiplext. Dazwischen taktest du die Register.

Das ist Software SPI, dürfte in ASM circa 6 Takte pro Byte a 2 Pixel a 6 
Datenbits benötigen. Damit bist du dann schneller als das Hardware SPI 
des AVRs ! (doppelt so schnell als per HW SPI möglich und in den obigen 
6 Takten habe ich schon den Speicherzugriff auf den SRAM mit 2 Takten 
eingerechnet)

>> Nun könnte man auch den Dot-Correcton Mode nutzen,

korrekt.

>> dann müsste man allerdings pro Pixel 3x7 Bit übertragen.

Nöö, macht keinen Sinn. Dann wäre es besser pro Byte im SRAM einen 
FarbPixel zu speichern. Du kannst also pro FarbLED 128 Helligkeiten 
speichern. 3 Bytes ergeben dann einen RGB Pixel. Insgesamt also 2Mio 
Farben. Wenn du das nicht so machst musst du deine Pixel im SRAM auf die 
7 Bit im Dot-Correction Register umrechnen. Du bräuchtest dann am besten 
eine große Lookup Tabelle im Speicher. Zb. bei 256 Farben, würdest du 
pro Pixel 1 Byte SRAM verbrauchen. Das dient dann als direkter Index in 
eine Tabelle mit jeweils 3 Bytes pro Eintrag. In diesen 3 Bytes stehen 
dann die Dot-Correction-Werte a 7 Bit für Rot/Grün/Blau drinnen.

Auf alle Fälle unterstützt das HW-SPI im AVR nur 8 Bit SPI. Du nusst 
also deine 7 Bit Dot-Correction-Werte zusammenschieben. Auch das kostet 
Zeit in der Software.

Ich meine das du dann besser ein Soft-SPI machst aber 3 Datenleitungen 
in parallel fütterst. Eben Rot,Grün,Blau Shift-Register getrennt 
kaskadiert. Das erhöht aber den Verdrahtungsaufwand.


Die "Stabiliserungszeit" für die Konstantstromquellen dauert -> 
Datenblatt -> tpd5 = 1000ns = 1µs. Bei einem Propeller mit 30cm Radius 
und 3600U/min werden in 1µs rund 0.12 Millimeter an den Rotorspitzen 
zurückgelegt, bzw. pro Millimeter braucht man 8.8µs. Das könnte also 
noch funktionieren.

>>Wenn ich es richtig verstanden habe, bauen wir hiermit ja eine Software
>>SPI.Wäre es nicht irgendwie möglich, das Ganze per Hardware SPI hin zu
>>bekommen?

Ja würde gehen hat Nach- und Vorteile. Nachteil ist eben das man nur 8 
Bit HW-SPI kann wir aber 7 Bit SPI bräuchten. Vorteil ist es das du alle 
3 Register seriell schaltest und an deren Ausgängen jeweil LED1 R-G-B, 
LED2 R-G-B, LED3 R-G-B usw. verdrahten kannst. Das reduziert also enorm 
den Verdrahtungsaufwand. Wenn du aus den 128 möglichen 
Dot-Correction-Register zb. nur 4 Bits als Farbe benutzten würdest so 
hättest du noch einen Wertebereich übrig um einen allgemeinen 
Farbabgleich der LEDs zu machen. Es soll ja alles schön gleichmäßig 
leuchten. Diesen Abgleich pro Farbe R-G-B würdest du bei der anderen 
Methode ja über RExt der Register machen. Bei der letzten Methode 
könntest du dafür wiederum jede LED einzeln justieren.


>> Wahrescheinlich nicht, da die HW SPI nur einen Daten Pin hat.

Doch doch, du musst dann eben alle Register seriell verdrahten.

>> Daher auch meine Frage, ob man 3 AVRs nimmt, für jede Farbe einen.

Nee das ist meiner Meinung nach schlecht. Entweder nimmst dann eine 
ordentlich leistungsstarke MCU, wie zb. einen ARM7. Oder bleibst bei 
einem AVR, da er mit 16/20 MHz Takt eigentlich ausreichend schnell sein 
sollte für 16 RGB LEDs. Bei mehreren AVR bekommst du rießige Problem mit 
der Synchronisation. Denn du musst ja das Bild das du darstellen 
möchtest auf 3 AVRs separieren. Langfristig wird das sehr kompliziert, 
es sei denn du möchtest wirklich nur dummpf das gleiche hardcoded Muster 
anzeigen. Wenn du aber bewegte Texte, kleine Bilder, Animationen 
darstellen möchtest so musst du dann das alles auf 3 AVRs aufteilen und 
synchron halten.


>>Ich frag mich nur, wie die von Wall-/Fan Screen, iBall und Co. das
>>machen.
>>Die haben 85 RGB LEDs und bis zu 3000 Spalten.

Kannste dir ausrechnen. 60 Frames pro Sekunde  3000  85 * 3 / 8 = 5,47 
Mega Bytes pro Sekunde an Daten, wobei dann nur 8 Farben darstellbar 
sind.

Das lässt sich nur reduzieren durch Interleaving, sprich Halbbilder oä. 
Zb. stellt man pro Umdrehung nur jede 2'te Pixelspalte dar, oder pro 
Umdrehung immmer nur eine Farbe Rot/Grün oder Blau.

>>Da sollte man wohl doch auf einen anderen Prozessor wechseln!?

Ab einer gewissen Größe muss man den Prozessor wechseln. Das ist eine 
einfache Rechnung um das festzustellen.

Ich hatte an CPLDs gedacht und sogar schon in VHDL einige Lösungen 
erarbeitet und simuliert. Essentiell wieder 3 Shiftregister-Ketten 
jeweils rot/grün/blaue LEDs getrennt. Der CPLD liest ein 20ns SRAM 
selbstständig aus und sendet die Daten an die Register. Transparent 
stellt der CPLD auch noch einen Zugriffsweg für den AVR zur Verfügung. 
Dh. der CPLD und AVR können quasi-parallel auf den SRAM zugreifen 
(deshalb das schnelle 20ns SRAM). Der AVR kann über sein ExtMEM 
Interface also direkt auf den SRAM zugreifen und somit auf den 
Display-Speicher. Der CPLD übernimmt die komplette Ansteuerung der LEDs 
mit der Ausnahme der Sychronisation des Rotors (das sollte der AVR 
machen). Leider reichte ein 128FF CPLD nicht mehr aus. Projekt 
gestorben, da mir FPGAs dafür zu kompliziert sind.

Gruß Hagen

Hallo Toby,
ich habe mit LED Treibern jetzt schon viel Erfahrung gesammelt und auch 
schon eine RGB Propellerclock mit den TLC5922 gebaut (sind eigentlich 
die gleichen wie die TLC5923)
ich weiß jetzt zwar nicht wofür du dich am Ende entschieden hast, aber 
wenn du da Unterstützung, Code, Schaltpläne oder Eagle Layouts brauchst, 
sag Bescheid.
Gruß
Kai