PCA9685 Stagger + Fade

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PCA9685 Stagger + Fade

722 Views
tba10596
Contributor I

All:

We recently introduced "stagger" into the chip, by offsetting the LEDx_ON register by 256 per output channel.

So LED0_ON has 0, LED1_ON has 256, and so on, until LED15_ON has 256x15 (=3840).

The problem we are seeing is when we fade the LED output on LED15 (for instance), at some point, the LED15_OFF will be less than LED15_ON, and an additional off cycle will be added to the output. Is there any way to mitigate this while still using staggering?

0 Kudos
4 Replies

647 Views
tba10596
Contributor I

Reviewing what I just wrote, the final value of LED2_OFF will be 0x1FF, not 0x0FF. Sorry about the typographical error...

By the way, the offsets were introduced so that we would not have a situation where multiple channels would be increasing at the same time.

0 Kudos

647 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hi Todd,

Can you send us the scope waveform about the below descriptions?

 

“LED2_ON stays at 0, and LED2_OFF is incremented to a value of 0x1FF.

When the LED2_OFF register crosses the 0 boundary, (at 0x00), it is "less than" LED2_ON,

which introduces a delay in the update by a cycle. (We have verified with scope.)”

 

My understanding is that if LEDn_ON made > LEDn_OFF, then there may have a cycle delay as in Figure 10 below.

Fig 10.jpg

Best regards,

Tomas

0 Kudos

647 Views
tba10596
Contributor I

Tomas:

Thanks for replying.

Initially, the LED0_ON = 0, and LED0_OFF = 0, 

                   LED1_ON = 256, (0x100) and LED1_OFF = 256

                   LED2_ON = 512, (0x200) and LED2_OFF = 512

and so on,

                   LED15_ON = 3840 (0xF00) and LED15_OFF = 3840.

When doing a fade (from 0 intensity to full intensity), 

LED0_ON stays at 0, and LED0_OFF is incremented to a value of 0xFFF.

However, look at what happens to LED2

LED2_ON stays at 0, and LED2_OFF is incremented to a value of 0x0FF.

When the LED2_OFF register crosses the 0 boundary, (at 0x00), it is "less than" LED2_ON,

which introduces a delay in the update by a cycle. (We have verified with scope.)

While the final value reaches the proper value, the intermediate result is a dip in the LED intensity.

Figure 10 of the datasheet shows that for situations where LEDn_ON < LEDn_OFF, there is no delay in a change.

However, when LEDn_ON > LEDn_OFF, as pointed out above, there is a 1-cycle delay. If many of these happen,

(incrementing LED2_OFF), the result is many instances in a row where there is a 1-cycle delay. One way to mitigate

this, is to keep the update rate slow, so that several cycles of a new PWM can be established before moving to another

PWM, but this is a real hassle from a software point of view. I assume that we will probably have to live with this, but

we were hoping there might be a work-around that does not introduce the 1-cycle delay.

0 Kudos

647 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hi Todd,

Can you post here the PWM registers settings while doing "stagger"?

                                                                                                                                                                                

What do you mean “at some point, the LED15_OFF will be less than LED15_ON”? 

Does it mean “until LED15_ON has 256x15 (=3840)” cannot be completed in one PWM cycle (4096)?

Best regards,

Tomas

0 Kudos