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?
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.
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.
Best regards,
Tomas
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.
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