LED-Cube, mindest Frequenzen für 30fps berechnen, TLC5940

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.

@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.

@ 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!