Guten Morgen, für die Bauteil-Dimensionierung und den damit zsm. hängenden Berechnungen müsste ich mich jetzt auf eine Frequenz festlegen. Dazu benötige ich aber etwas Unterstützung. Als Start habe ich gedacht legen wir uns einfach mal auf 30FPS fest. Da ich FET-Treiber usw. habe sollte das keine Probleme machen(?). Es gibt denke ich zwei Frequenzen. Einmal die der Ebenen-Treiber(FETs) was 8stk sind(8x8x8 Cube). Für dessen Freq. muss ich wahrscheinlich die folgende Frequenz durch 8 teilen, da ich ja Ebene für Ebene zeichne. Dann die Freq. der TLCs(TLC5940). Wenn ich die 6bits Dot-Correction vernachlässige(da es nur in der Initialisierung passiert(?)) bleiben die 12bit der PWM für jedes LED. Pro Ebene 8x8 = 36 LEDs. 36x12bit = 432bit die ich 30x in der Sekunde senden muss. Weiter komme ich momentan leider nicht, bin mir auch sehr unsicher ob ich alle Faktoren berücksichtige. Sollte wohl auch erwähnen das es 4 TLCs in Serie sind. Hoffe auf Nachsicht. MfG. Dex
Irgendwas passt bei deinen Überlegungen nicht.. 8x8 Cube = 64 LEDs pro Ebene 64 LEDs / 16 Channels des TLC5940 = 4 ICs in Reihe 4 ICs in Reihe 16 Kanäle pro Chip 12 Bit Grayscaledaten = 784Bit = 98 Byte 784 Bit pro Ebene * 8 Ebenen = 6272 Bit = 784 Byte pro Bild Zur Wiederholrate 30 FPS * 8 Ebenen = 240 Ebenen / s 240 Ebenen pro Sekunde * 2^12 PWM-Takte pro Ebene =983040 Hz Grayscale Takt Man sieht also, dass du mit 1 MHz Grayscalclock, deine Bildwiederholrate hinbekommst. Aber nun musst du innerhalb deiner 4096 PWM-Takte die kompletten Daten für die nächste Ebene reintakten, also die oben berechneten 784Bit. Hier für braucht ein Atmega mindestens doppelt soviel Takte und ist dabei komplett ausgelastet, sprich kann zum Beispiel nicht die Daten der nächsten Ebene berechnen. Ein ARM Controller mit DMA könnte diese Übertragung im Hintergrund erledigen. Du kannst aber eine schnellere Grayscale clock wählen und die Ebene für mehrere PWM-Perioden anzeigen, um die mehrfache Datenübertragung zu sparen. Du musst halt nur nach Ablauf der 4096 Takte der PWM-Periode einmal am Blankingeingang wackeln, dass der Zyklus neu startet.
Vielen dank für die Erläuterungen trotz meines peinlichen Fehlers :S Ich benutze einen Cortex M4 da sollte es keine Probleme geben. Vielen dank! MfG. Dex
@Dex (Gast) >Als Start habe ich gedacht legen wir uns einfach mal auf 30FPS fest. Da >ich FET-Treiber usw. habe sollte das keine Probleme machen(?). Doch, es flimmert wie Sau. Man braucht mindestens 50, besser 100 Hz. Ein LED-Cube ist nichts anderes als eine LED-Matrix, nur dass die LEDs mechanisch anders angeorndet sind. >Einmal die der Ebenen-Treiber(FETs) was 8stk sind(8x8x8 Cube). Für >dessen Freq. muss ich wahrscheinlich die folgende Frequenz durch 8 >teilen, da ich ja Ebene für Ebene zeichne. Mal 8. >Dann die Freq. der TLCs(TLC5940). Wenn ich die 6bits Dot-Correction >vernachlässige(da es nur in der Initialisierung passiert(?)) bleiben die >12bit der PWM für jedes LED. Man kann auch weniger Bits nutzen. >Pro Ebene 8x8 = 36 LEDs. 8x8 sind bei mir 64. > 36x12bit = 432bit die ich 30x in der Sekunde >senden muss. Nö, die musst du 8x30 senden. Siehe LED-Matrix. >Weiter komme ich momentan leider nicht, bin mir auch sehr unsicher ob >ich alle Faktoren berücksichtige. Sollte wohl auch erwähnen das es 4 >TLCs in Serie sind. Lies den Artikel LED-Matrix. Bei LED-Cus ist halt ein "Zeichen" eine Ebene. Du hast 8 Ebenen a 64 LEDs. Bei min. 100 Hz Bildwiederholrate und 8 Ebenen (Digits) musst du mit 8x100=800Hz die Ebenen ansteuern. In einem Durchgang von 1,2ms musst du 8x8x12=768 Bit = 96 Byte in die TLC reinschieben. Bei angenommenen 10 MHz SPI Takt dauert das 77us. Ein Witz. Die PWM für die Dimmung hat eine Periode von ebenfalls 800 Hz. Bei vollen 12 Bit brauchst du also 800Hz x 4096 = 3,2768 MHz. Das ist kein Problem, diesen Takt kann man mit einer Output Compare Funktion generieren, ganz ohne CPU-Last.
:
Bearbeitet durch User
@ Jan K. (madengineer) >240 Ebenen pro Sekunde * 2^12 PWM-Takte pro Ebene =983040 Hz Grayscale >Takt ~1 MHz, sehr wenig. >Aber nun musst du innerhalb deiner 4096 PWM-Takte die kompletten Daten >für die nächste Ebene reintakten, also die oben berechneten 784Bit. Ja. > Hier >für braucht ein Atmega mindestens doppelt soviel Takte und ist dabei >komplett ausgelastet, NIEMALS! Siehe mein Beitrag! > sprich kann zum Beispiel nicht die Daten der >nächsten Ebene berechnen. Er hat alle Zeit der Welt! EIn AVR schafft das locker, man muss ihn ja nicht mit 1 MHz takten! > Ein ARM Controller mit DMA könnte diese >Übertragung im Hintergrund erledigen. Nett, aber unnötig! > Du kannst aber eine schnellere >Grayscale clock Früher (tm) hieß das Takt! Und früher war TAKTlosigkeit verpönt!
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.