Problem mit PCA9685-LED-Treiber

[Dietmar (Gast)]

Hat jemand Erfahrung mit dem PCA9685-LED-Treiber? Bei mir funktioniert 
das Dimmen der LEDs einwandfrei, wenn zwischen den LED-Ausgängen keine 
Phasenverschiebung verwendet wird. Mit Phasenverschiebung ist das Dimmen 
nicht mehr stufenlos - irgendwas stimmt da nicht. Im folgenden Code ist 
die Phasenverschiebung der auskommentierte Term "(n * 256)": es 
funktioniert nur mit 0 statt diesem Term.

// set PCA9685 output <n> (0 ... 15) to 12bit brightness value (0 ... 4095); return 0 if successful or error number

uint8_t
MODULE_pca9685_set(uint8_t n, uint16_t brightness)
{
    uint16_t registers[2];

    if (brightness)
    {
        if (brightness < 4095)
        {
            // do not turn all LED on at the same time

            uint16_t phase_shift = 0; // (n * 256);

            registers[0] = 0          + phase_shift; // on_time
            registers[1] = brightness + phase_shift; // off_time

            // turn off in next 0...4095 cyle?

            if (registers[1] >= 4096)

                registers[1] -= 4096;
        }
        else
        {
            registers[0]  = PCA_ALL_LED_FULL_ON;
            registers[1]  = 0;
        }
    }
    else
    {
        registers[0] = 0;
        registers[1] = PCA_ALL_LED_FULL_OFF;
    }

    return(MODULE_twi_write_register(PCA9685_SLA, PCA_REGISTER_LED0_ON_L + (n * 4), (uint8_t *)registers, 4));
}

[Wolfgang (Gast)]

Dietmar schrieb:
> Mit Phasenverschiebung ist das Dimmen nicht mehr stufenlos - irgendwas
> stimmt da nicht.

Und MODULE_twi_write_register() ist als Fehlerquelle sicher 
ausgeschlossen?
Sonst wäre die Routine auch noch für die Fehlersuche relevant.

Wie groß sind die Sprünge? (Oszi) Kann mit der Zuordnung der beiden 
Bytes zu den Registern irgendetwas schief gehen? Was sagt der Simulator?

[Dietmar (Gast)]

> MODULE_twi_write_register() ist als Fehlerquelle sicher
ausgeschlossen?

Zu 99,9%: ch kann die Kontrollregister beschreiben und der Code ist 
altbewährt - schon in anderen Projekten verwendet. Die Konstanten sind 
auch richtig definiert: es werden die richtigen Register beschrieben.

Beim Verlangsamen des Dimmen ist mir aufgefallen, dass der optische 
Fehler von einem Flackern kommt: die Anzeige ändert beim Beschreiben des 
Registers kurz die Helligkeit - aber nur, wenn der Wert im 
LEDn_ON-Register grösser als der im LEDn_OFF-Register ist (je grösser 
der Abstand wird, desto weniger Flackern). Das Flackern könnte daher 
kommen, dass der Chip beim Beschreiben der 4 Register pro LED die 
Änderung sofort umsetzt statt nach den 4 Bytes, die die Helligkeit der 
LED definieren. Das sollte aber nicht passieren, oder? Im MODE2-Register 
steht Bit OCH auf 0, was laut Datenblatt "Outputs change on STOP 
command" sicherstellt. Im Datenblatt gibt es eine kryptische Passage:

"Because the loading of the LEDn_ON and LEDn_OFF registers is via the 
I2C-bus, and asynchronous to the internal oscillator, we want to ensure 
that we do not see any visual artifacts of changing the ON and OFF 
values. This is achieved by updating the changes at the end of the LOW 
cycle."

Ich habe keine Ahnung, was ein "LOW cycle" ist und wie man dessen Ende 
detektiert.

[Dietmar (Gast)]

Noch etwas: diese Flackern fällt nur auf, wenn an dem entprechenden 
LED-Ausgang (als totem pole konfiguriert) ein per n-MOSFET 
angeschlossenes LED-Backlight hängt. Bei einer direkt angeschlossenen 
LED bemerkt man das nicht?!?

[Bla (Gast)]

Hallo,

sorry, dass ich das Thema jetzt mal hochholen muss. Ist es noch aktuell? 
Ist das Problem behoben?
Ich habe Ähnliches beobachtet, aber auch nur bei LED_ON > LED_OFF. Ist 
ein bisschen nervig, weil sich so die Sache mit der Phasenverschiebung 
nicht wirklich richtig ausnutzen lässt... würde mich echt interessieren, 
woran es liegt.

[Bla (Gast)]

Oder ist es gar ein Hardwarebug?

[Bla (Gast)]

Hmm, hat keiner eine Idee??

[Flicker (Gast)]

Keine Idee, aber das gleiche(?) Problem. Ich benutze auch die 
Phasenverschiebung zwischen den Ausgängen und bekomme beim Schreiben der 
Register immer dann sporadische "Aussetzer" (Flackern), wenn tON>tOFF 
ist.

Der Effekt tritt schon mit einem trivialen Programm auf, das in einer 
Schleife immer wieder die gleichen Werte schreibt:

    START 
    0x82        (Adresse)
    0x06        (Register LED0_ON_L)
    0x00 0x0f   (tON)
    0x00 0x0e   (tOFF)
    STOP

Wenn ich die obige Sequenz alle 500ms schreibe, flackert es jedesmal. 
Sieht so aus, als ob eine ON-Periode verlorengeht. Ohne Wartezeit in 
meiner Schleife flackert es dagegen nie, auch nicht sporadisch. Es 
siehtalso  so aus, als ob nach einer längeren Bus-Inaktivität das erste 
Update nicht richtig funktioniert.

Kann das jemand bestätigen?