Hi,
Ich habe Probleme mitt der Dot Correction bei einem TLC5940:
der GS mode läuft ohne Probleme.
Das settzten des DC-Registers hat aber irgendwie keine sichtbaren
Auswirkungen, außer das alle Ausgänge verlischen.
im dem nächsten GS-Cyklus ist keine Helligkeits-Änderung sichtbar.
hier der Init Code (neben der SPI init):
1
TLC5949_CTRL_DDR|=(1<<TLC5949_CTRL_DCPRG)
2
|(1<<TLC5949_CTRL_VPRG);
3
TLC5949_CTRL_PORT&=~(1<<TLC5949_CTRL_VPRG);
4
TLC5949_CTRL_PORT|=(1<<TLC5949_CTRL_DCPRG);
Im Kontext der Mainloop werden dann die dc-werte gesetzt und sollten
nach meinem Verständnis sofort Auswirkungen zeigen:
1
cli();// sichern, damit die GS-Interrupts nicht dazwischenfunken
2
TLC5949_CTRL_PORT|=(1<<TLC5949_CTRL_VPRG);// DC register anwählen
TLC5949_CTRL_PORT&=~(1<<TLC5949_CTRL_VPRG);// wieder GS-Regsiter anwählen
16
sei();// weiter wie bisher
Ich hab auch schon probiert direkt am Anfang einfach nur die PWMs mit
0xFFF zu initialisieren und ihm ein paar GS-Clocks zu geben, damit die
Ausgänge angehen und dann mittels Dot Correction die Helligkeit zu
regulieren.
Dies wäre sogar meine favorisierte Methode, da in dem aktuellen Projekt
die 6bit ausreichen, ich dafür aber die Hälfte der Bandbreite einspare.
Hat jemand einen Tip für mich, was ich übersehe?
Gruß
Vlad
Hallo Vlad,
ich glaube mich erinnern zu können, dass Du in jedem Fall 12Bit pro
Kanal übergeben musst.
Das bedeutet, dass Deine Matrix nicht 16*6bit = 96bit = 12Byte sondern
16*12bit = 192bit = 24Byte sein muss.
Gruß
Frank
im Datenblatt steht eindeutig:
> When VPRG is set to VCC, the TLC5940 enters the dot correction> data input mode. The length of input shift register becomes 96 bits.
Simon K. schrieb:> Einmal schreibst du TLC5949 und einmal TLC9540?!
oh, der Typo ist mir noch nicht aufgefallen.
Hatte letztens erst ein paar Namen refactored, da scheint das mit
reingeraten zu sein.
Soll aber natürlich 5940 heißen
Vlad Tepesch schrieb:> Simon K. schrieb:>> Einmal schreibst du TLC5949 und einmal TLC9540?!>> oh, der Typo ist mir noch nicht aufgefallen.> Hatte letztens erst ein paar Namen refactored, da scheint das mit> reingeraten zu sein.> Soll aber natürlich 5940 heißen
Aber es löst nicht zufällig das Problem, oder? ;-)
Simon K. schrieb:> Aber es löst nicht zufällig das Problem, oder? ;-)
Häh? seit wann kümmern sich ICs darum, wie die Variablen im Code heißen,
oder was willst du damit sagen?
Vlad Tepesch schrieb:> Simon K. schrieb:>> Aber es löst nicht zufällig das Problem, oder? ;-)>> Häh? seit wann kümmern sich ICs darum, wie die Variablen im Code heißen,> oder was willst du damit sagen?
Nö das nicht, aber weiß der Geier, was da in deinem Code vorgeht, wenn
da mehrere defines mit leicht unterschiedlichem Namen existieren und man
sich wundert, warum sich nix ändert, wenn man das TLC5940-define ändert
und in Wirklichkeit das TLC5949-define verwendet wird...
Simon K. schrieb:> Nö das nicht, aber weiß der Geier, was da in deinem Code vorgeht, wenn> da mehrere defines mit leicht unterschiedlichem Namen existieren und man> sich wundert, warum sich nix ändert, wenn man das TLC5940-define ändert> und in Wirklichkeit das TLC5949-define verwendet wird...
Du hast mich misverstanden.
ich hab nur vorher die defines global umbenannt um den Modulnamen
voranzustellen. Dabei habe ich mich wohl vertippt (9 statt 0)
(Es gibt auch gar keinen TLC5949)
Vlad Tepesch schrieb:> Simon K. schrieb:>> Nö das nicht, aber weiß der Geier, was da in deinem Code vorgeht, wenn>> da mehrere defines mit leicht unterschiedlichem Namen existieren und man>> sich wundert, warum sich nix ändert, wenn man das TLC5940-define ändert>> und in Wirklichkeit das TLC5949-define verwendet wird...>> Du hast mich misverstanden.
Was heißt hier "missverstanden"? Du bist im Moment der Einzige, der
deinen gesamten Code angucken kann.
Es war ja nur eine Vermutung.
Simon K. schrieb:> Was heißt hier "missverstanden"? Du bist im Moment der Einzige, der> deinen gesamten Code angucken kann.
Ja, ich bin grad dabei, das ganze mal auf das notwenigste einzudampfen
