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));
}

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?

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

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

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.

Oder ist es gar ein Hardwarebug?

Hmm, hat keiner eine Idee??