TLC5940 Effizient ansteuern

[Vlad T. (vlad_tepesch)]

Hi,
Kann mir jemand einen Tip geben, wie man den TLC9540 effizient mit einem 
AVR ansteuert?
Ziel ist eine LED Matrix.
Im Blank wollte ich die Spalten umschalten.

Momentan hab ich testweise einen Mega32 genommen.
Würde aber auch nix dagegensprechen einen neueren zu verwenden.

Prinzipielle Ansteuerung ist klar und funktioniert.

Mir geht es um die PWM und den Blank. Das soll möglichst die Hardware 
nebenbei machen.

Ich sehe momentan nur folgende Variante:
ein timer im CTC mode Top auf 1 -> Pin Toggelt jeden 2. Takt
diesen Tak an den TLC.

der 16bit Timer, auch im CTC auf 12bit (eventuell weniger, wenn die 
Frequenz zu klein wird) External Clock aus dem anderen Timerpin,

Im Overflow dann das Umschalten der Spalten, das Latchen der neuen Daten 
den Blank und das Laden der nächsten Daten triggern.

evenutell auch top als vielfaches des Top wertes um zwischendurch noch 
ein blank zumachen um nur alle x blanks die nächste Spalte zu zeigen.
Sollte die SPI ein wenig entlasten.

Nachteil: 2 Verbratene Timer
den kleinen Timer könnte man durch einen externen IC ersetzen (tiny13, 
NE555)

Gibt es bessere Lösungen?

Vielen Dank im Voraus für Vorschläge.
Vlad

[Michael H. (michael_h45)]

Wenn du einen Xmega nimmst, hast du Peripherie im Überfluss. Die SPI 
kann schneller als der Core und mit irrc bis zu 100MHz laufen.

Das ist zwar nicht effizient, macht die Sache aber einfacher.

> Ich sehe momentan nur folgende Variante:
> ein timer im CTC mode Top auf 1 -> Pin Toggelt jeden 2. Takt
> diesen Tak an den TLC.
Das Kriegst du auch mit einem externen Taktteiler (D-FF) vom Clock des 
AVRs hin.

P.S.: Wird das eine neue Word Clock-Hardware?

[Vlad T. (vlad_tepesch)]

Michael H. schrieb:
> Wenn du einen Xmega nimmst, hast du Peripherie im Überfluss. Die SPI
> kann schneller als der Core und mit irrc bis zu 100MHz laufen.

naja, mit "neuren" meinte ich schon AVR-Cores.
Für XMegas fehlen mir die Tools. (zumal es die auch nicht in DIL gibt, 
was wiederum gefertigte Platinen erfordern würde)
Aber eine DMA-SPI wäre in jedem Falle schick., weil den SPI-Interupt 
anzuwerfen lohnt sich bei hohen SPI-Frequenzen nicht, trotzdem 
verballert man ne menge Zeit, wenn man mehrere TLCs kaskadiert.

Michael H. schrieb:
> Das Kriegst du auch mit einem externen Taktteiler (D-FF) vom Clock des
> AVRs hin.

bekomme ich die Clock aus dem Mega irgendwie raus? ansonsten müsste ich 
einen quarzoszi, anstelle des Quarzes benuntzen. Hätte den weiteren 
Vorteil, dass ein Pin frei wird.
Andererseits ist ein D-FF-IC meißt größer als ein Tiny, so das sich das 
eigentlich nicht lohnt

Michael H. schrieb:
> P.S.: Wird das eine neue Word Clock-Hardware?
nö, nur ein kleiner 4x4x4 LED-Cube (also quasi 16x4 Matrix) zum 
Kennenlernen des TLC5940

Ich hatte mir den als Sample bei TI bestellt, weil ich den ganz 
interessant fand. Was ich damals überlesen hatte, war, dass man das Ding 
selbst mit Takt und Blank versorgen muss.

gibt es sowas auch als nicht-One-Shot-Timer Version, der die neuen Daten 
bis zum nächsten Overflow puffert.

SR->[Latch]->Buffer->[Timer-Overflow]->Compare-Register

[Maik F. (sabuty)]

Beitrag "Re: AtMega 48 Timmer"

[Vlad T. (vlad_tepesch)]

Maik Fox schrieb:
> Beitrag "Re: AtMega 48 Timmer"

Interessante Idee.
Der Trick ist also die SPI so langsam wie möglich zu drehen und doch die 
Interupts zu benutzen.

[Michael H. (michael_h45)]

Vlad Tepesch schrieb:
> bekomme ich die Clock aus dem Mega irgendwie raus? ansonsten müsste ich
> einen quarzoszi, anstelle des Quarzes benuntzen. Hätte den weiteren
> Vorteil, dass ein Pin frei wird.
Da der Quarz vom Atmel schon angeschwungen wird, kannst du ihn 
C-entkoppelt über einen Schmitt-Buffer oder Inverter einfach abgreifen.

> Andererseits ist ein D-FF-IC meißt größer als ein Tiny, so das sich das
> eigentlich nicht lohnt
Das stimmt ^^

> SR->[Latch]->Buffer->[Timer-Overflow]->Compare-Register
Das kostet halt ordentlich Platz auf dem Die für die ganzen Werte.
Schön wäre es natürlich schon...

[Maik F. (sabuty)]

Vlad Tepesch schrieb:
> Der Trick ist also die SPI so langsam wie möglich zu drehen und doch die
> Interupts zu benutzen.

Eher so schnell wie möglich. Wenn man die vollen 12 Bit PWM des TLC5940 
nutzen will, braucht man für einen anständige PWM-Frequenz schon einen 
möglichst hohen PWM-Takt.

Im SPI-Interrupt (SPI_STC) wird immer ein Byte geschickt. Dessen Inhalt 
entscheidet eine Mini-State-Machine. Diese hat die folgenden Zustände:

1. Dummy-Daten schicken (512 Bytes (=8*512=4096 Takte=2^12) abzüglich 
der eigentlichen Daten (für einen Chip 16*12/8=24 Byte)), damit die 
GSCLK getaktet wird. Die hier gesendeten Daten sind dem TLC egal, die 
fallen ja hinten aus dem Schieberegister wieder raus.

2. Eigentliche Daten schicken. Parallel dazu wird ja immernoch 
gleichzeitig die GSCLK mitgetaktet, PWM zählt also weiter.

3. Wenn die Daten verschickt sind, Blank, XLAT, !XLAT, !BLANK. Dann 
wieder ein Dummy-Byte verschicken, damit der SPI-Interrupt wieder 
aufgerufen wird. Das muss man eigentlich in Schritt 1 auch noch 
abziehen...

Ich hoffe das ist soweit nachvollziehbar. Wenn man eine 
SPI-Schnittstelle übrig hat, ist das eine ziemlich nette Sache, da sich 
der SPI-Interrupt eben immer wieder passend selbst aufruft und man 
trotzdem noch genügend Rechenzeit hat, um mit den LEDs auch was schönes 
anzuzeigen.

Von einem Test dieser Methode mit kreisrund angeordneten LEDs habe ich 
auch mal mit einem alten Crap-Handy ein Video gemacht, wen's 
interessiert: http://www.youtube.com/watch?v=nYz0KTryewY

[Vlad T. (vlad_tepesch)]

Maik Fox schrieb:
> Eher so schnell wie möglich. Wenn man die vollen 12 Bit PWM des TLC5940
> nutzen will, braucht man für einen anständige PWM-Frequenz schon einen
> möglichst hohen PWM-Takt.

hmm - ok, was hab ich da gestern abend nur gerechnet?

Aber bei höchster SPI-Frequenz lohnen sich die Interupts ja nicht mehr.
im Schnellsten Modus braucht die SPI für ein Byte doch nur 16 Takte oder 
seh ich das falsch?
für einen ISR-CALL gehen schon mal naked und ohne Code 10 oder so drauf
Das heißt für sonstige Logik bleibt nix mehr über.

bei einer Zielfrequenz von 200Hz ergibt sich ein SPI-Vorteiler von 16.

Ich glaub da ist die Sache mit den 2 Timer momentan doch die günstigste.
da muss man nicht ständig dummy Bytes schreiben sondern einfach nur alle 
4092 counts einen Blank und alle x*4092 counts die die Spalte 
umschalten.
Dazwischen kann man in einem sehr langsamen SPI-Mode die Daten per 
Interupt reinschaufeln, oder komplett am Stück mit einem sehr fixen.

vielleicht sollte man auch komplett für die Anzeige einen µC abstellen, 
der parallel die LED-Werte bekommt, diese intern linearisiert und sich 
um die Darstellung kümmert. Ist für den kleinen 4x4x4 sicherlich nicht 
nötig, aber für Größere sicher lohnenswerter.

[Falk B. (falk)]

@  Vlad Tepesch (vlad_tepesch)

>Aber bei höchster SPI-Frequenz lohnen sich die Interupts ja nicht mehr.

Nein.

>im Schnellsten Modus braucht die SPI für ein Byte doch nur 16 Takte

Ja.

>oder seh ich das falsch?

nein.

>bei einer Zielfrequenz von 200Hz ergibt sich ein SPI-Vorteiler von 16.

Falsch. Das ist die Multiplexfrequenz. Die SPI betreibt man dennoch mit 
voller Geschwindigkeit.
In einer 5ms ISR lädt man den TLC mit neuen Daten, so schnell wie 
möglich. Dann erzeugt man per Output Compare Funktion den PWM Takt, das 
macht die Hardware allein.

>Ich glaub da ist die Sache mit den 2 Timer momentan doch die günstigste.
>da muss man nicht ständig dummy Bytes schreiben sondern einfach nur alle
>4092 counts einen Blank und alle x*4092 counts die die Spalte
>umschalten.

Ja.

>Dazwischen kann man in einem sehr langsamen SPI-Mode die Daten per
>Interupt reinschaufeln, oder komplett am Stück mit einem sehr fixen.

Eher zweitens.

>vielleicht sollte man auch komplett für die Anzeige einen µC abstellen,
>der parallel die LED-Werte bekommt, diese intern linearisiert und sich
>um die Darstellung kümmert.

Wozu? Ein AVR ist damit schon massiv unterfordert ;-)

MFG
Falk

[Vlad T. (vlad_tepesch)]

Falk Brunner schrieb:
>>Ich glaub da ist die Sache mit den 2 Timer momentan doch die günstigste.
>>da muss man nicht ständig dummy Bytes schreiben sondern einfach nur alle
>>4092 counts einen Blank und alle x*4092 counts die die Spalte
>>umschalten.
>
> Ja.

Das hab ich jetzt gebaut.

...

  // timer 1  (16bit)
  DDRB &= ~(1<<PIN1); // T1 pin as clock input for 16bit timer
  TCCR1A = (1<<WGM11) | (0<<WGM10); // Fast PWM with ICR1 as top
  TCCR1B = (1<<WGM13) | (1<<WGM12)  //
         | (1<<CS12) | (1<<CS11) | (1<<CS10); // external clock (T1) on rising egde
  TIMSK  |= (1<<TOIE1); // enable overflow interupt
  ICR1   = 4096;


  // timer 0
  DDRB |= (1<<PB3);
  TCCR0 = (1<<WGM01) | (0<<WGM00)   // CTC
        | (0<<COM01) | (1<<COM00)   // Toggle on Compare Match
        | (0<<CS02) | (1<<CS01) | (1<<CS00);  // prescaler 64 for test
  OCR0 = 0; // f(OCR) = F_CPU/2/Prescaler

...

ISR( TIMER1_OVF_vect )
{
  LED_TOGGLE(STAT_LED_DEBUG_1);
  tlc5940_blank();
  TCNT1 = 0;
}

der Timer 0 funktioniert.
der erste PWM-Zyklus ist bei geeigneter Einstellung des Vorteilers und 
des OCR0 gut zu beobbachten, allerdings wird die ISR nicht getriggert.
Laut datasheet müsste er doch in dem modus den Overflow auslösen, wenn 
der Counter TOP (ICR1) erreicht ist.

den FPWM-mode wollt ich nehmen, damit ich die die Compares noch frei 
habe.
um eventuell folgende Aufteilung vorzunehmen:
OCR1A = 4096 -> blank,
OCR1B = 8192 -> blank,
ICR1 = 12288 -> Spaltenwechsel + blank

Hat jemand einen Hinweis?
und ja, ich hab die Brücke zwischen PB3 und PB1 wirklich eingebaut ;)

Gruß,
Vlad

[Vlad T. (vlad_tepesch)]

Ich hab die Frage mal in einen extra Thread gepostet. past da sowieso 
besser.
Beitrag "atmega32 timer1 externer Takt funktioniert nicht."
Antworten zu dem Problem also bitte da hin.

[Simon K. (simon)]

Michael H. schrieb:
> Wenn du einen Xmega nimmst, hast du Peripherie im Überfluss. Die SPI
> kann schneller als der Core und mit irrc bis zu 100MHz laufen.

Da weiß ich und das Datenblatt aber nix von :-(.

Die SPI beim xmega ist für schnelle Sachen eh nicht geeignet, wenn ich 
das richtig sehe. Da sollte man lieber die USART im synchronen Betrieb 
nehmen, da diese Double Buffering und DMA Support hat.
Aber die kann man auch nicht mit 100MHz takten. Die Peripherie läuft 
über fCLKPER und das ist maximal 32MHz.

[Hagen (Gast)]

Das SPI beim XMega hat DMA, aber für die empfangenen Daten. Beide, SPI 
und USART würden bei 32MHz CPU Takt = CLKperipherie einen Durchsatz von 
16MBit erreichen. Ich würde aber auch den MSPIM der USARTs benutzen. 
FMax beider ist 32MHz. Das Pinning zwischen MSPIM-USART und SPI ist 
ebenfalls unclever gemacht. Die Pins beider Cores liegen zwar 
übereinander, aber über kreuz. Hätte Atmel das cleverer gelöst so wäre 
beim A1 Core der SPI direkt austauschbar mit MSPIM-USART ohne Änderungen 
der Pinzuordnungen. Naja.

Gruß Hagen