Hallo, ich plane so etwa 32 RGB LEDs mit einem ATmega8 oder Tiny2313 per SPI und HC595 anzusteuern. Mein Problem sind aber die 3x4 (=12) HCs und die dazugehörigen Treiber. Mächtig viel ICs und Verdrahtung. Gibt es evtl. ein 24 Bit LED Treiber? Ich kenne bislang nur 8 oder 16 Bit Treiber. Wie sieht es bei einem 16 Bit Treiber MAX7221 mit der Geschwindigkeit aus? Wäre es möglich, damit drehende LED anzusteuern? Die LEDs drehen mit max 2500 U/min, und erzeugen 256 (evtl. mehr) Spalten. Wie einige schon wissen, habe ich eine Art Propeller Uhr, nur mit 32 LEDs (einfarbig). Das ganze Projekt soll nun als RGB Version gebaut werden. Danke für euere Hilfe... Gruß Toby
Hallo mal wieder, da ich immer noch nichts Neues weiß, hat vielleicht jamand noch eine Idee. Ich dachte schon daran, 3 AVRs zu nehmen, um 3x SPi zu haben. Für jede Farbe einen. Wie siehts mit diesen aus : TLC5940 / TLC5941 ??? Kann mir dazu evtl. mal jemand eine Funktionsbeschreibung geben? Vor/Nachteile, Ansteuerung, Geschwindigkeit,..... Gruß Toby
Wiso 3 mal SPI ? 3 mal Chip Select reichen...Einfach alle SPI leitungen(ausser dem CS) parrallel anschliessen und fertig..der chip wird dann mittels CS (chip select) ausgewählt
Hallo, das mit dem 3x CS ist mir schon klar. Nur muß ich ja bei 32 RGB LEDs 12 Schieberegister hintereinander schalten. Ich muß also 12 byte per SPI senden. Dabei ist es egal, ob ich einen, oder 3 CS Pinne habe. Mir ging es ja darum, schneller zu werden, also 3x4 Schieberegister zu verwenden. Evtl. habe ich ja mal wieder ein Brett vorm Kopf. Gruß Toby
Angehängte Dateien:
-
spokepov.png
53 KB
Hallo nochmal, ich habs nun kappiert! ;-) Ich habe 3x 4 Schieberegister und wähle je 4 davon mit einem eigenen CS Pin aus. So ähnlich wie im Anhang. Gruß Toby
sorry hab das mit der probelleruhr überlesen. denke mal es wär einen versuch wert. schöne festtage
Hallo Maxer, wie schnell Multiplexen denn diese MAX7221? Interessannt sind die ja schon, da man auch die Helligkeit einstellen kann, und wohl nur einen Wiederstand für alle angesteuerten LEDs benötigt. Wünsche auch ein frohes Fest. Gruß Toby
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
Hallo Hagen, prinzipiell würden mir 8 Bit Farben reichen! Also LED an/aus. Könnte so was mit den HC595/TPIC6C595 funktionieren? Des weiteren spiele ich ja noch mit dem Gedanken, die Anzeige auf bis zu 64 LEDs zu erweitern. Immerhin soll es in einem RC Heli platz finden, und da es diese in mehreren Größen gibt, muß ich wohl oder übel mehr LEDs verwenden. Aber trotz Allem, das sind schon geniale Überlegungen, die Du da machst! Wie weit bist Du mit deiner Planung einer PropUhr???? Gruß Toby
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
Hallo Hagen, ich gehe mal von den TLC5923 aus. Habe mir 3 Samples geordert. Nehme ich also den ON/Off Mode, muß ich für 16 RGB LEDs, 3x TLC, 8 Byte Bilddaten erzeugen und übertragen. Jedes Byte beinhaltet 2 Pixel. Also jedes Byte 2x schieben, erst das obere Halbbyte, dann das untere Halbbyte. So weit richtig? Nun könnte man auch den Dot-Correcton Mode nutzen, dann müsste man allerdings pro Pixel 3x7 Bit übertragen. Da in einem Byte ja 2 Pixel stehen, macht das 7Byte für 2 Pixel im Dot Correction Mode. Sehe ich das so richtig? 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? Wahrescheinlich nicht, da die HW SPI nur einen Daten Pin hat. Vorteil der HW SPI, die macht ja alles im Hintergrund. Daher auch meine Frage, ob man 3 AVRs nimmt, für jede Farbe einen. 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. Da sollte man wohl doch auf einen anderen Prozessor wechseln!? So weit... Gruß Toby
>>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, ich bin mal wieder dazu gekommen, mich meinen RGB LEDs zu widmen. Ich habe nun folgende Schaltung mit 3 TPIC6C595 aufgebaut. PD0--------|---------- Blau PD1--------+--|------- Grün PD2--------+--+--|---- Rot | | | PD3 -> CS | | | | | | PD4--------| | | PD5-----------| | PD6--------------| PD7 -> SCK Nun habe ich zwei Fragen: Wie kann ich die Routine "SPI_Transfer_RGB_Byte" kürzen, da ich ja vier mal das gleiche tue, es ändern sich nur die Daten. Mit einer Schleife, schon klar, aber wie bekomme ich die aten in die Schleife? Wie sollte man bei der Beschaltung vorgehen, um die Daten vernünftig auszugeben, damit der Atmel nicht allzuviel umrechnen muss? Danke für die Hilfe,... Gruß Toby
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
Hallo, habe gestern in der Eile ganz den Anhang vergessen. Kai, ich nutze TPIC6C595 Schieberegister, wie schon Beschrieben. Die TLC Teile sind mir noch zu kompliziert. Müsste erst damit etwas Testen. ;-) Gruß Toby
Nochmal, Hallo.
Im Anhang gibt es einmal die "SPI_Transfer_RGB_Byte".
Damit werden 4 Bytes an die Schieberegister üergeben,
Kodiert, wie Hagen es vorgeschlagen hat.
(Dazu auch die Frage, wie man die Funktion kürzen kann,
da ich ja 4x das gleiche tue)
Dann gibt es noch die "SPI_Transfer_RGB_Bytes".
Hier wollte ich die 3 Bytes Red,Gren,Blue übergeben.
Daraus sollten eigentlich 4 Bytes werden,
in etwa so:
Blue: 0000 0000
Green: 0000 0000
Red: 1111 1111
|||| ||||
|||| ||Byte4: 00100010
|||| Byte3: 00100010
||Byte2: 00100010
Byte1: 00100010
Natürlich ist das eine ganz schöne Rechnerei,
aber so hätte man je Farbe ein Byte.
Gruß Toby
Thread beobachten
Seitenaufteilung abschaltenBitte 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.