Bug in the 16-bit PWM implementation in dimming examples

[DeveloperZ]

Hi,

Experimental dimming examples contain a 16 bit PWM implementation. I added the Enocean switch functionality to the dimming server example to control the LED on the board with the app as well as with the switch. I was using the 16-bit PWM function to dim the lights by Enocean switch. 

I found a weird bug when I was displaying the light levels while dimming as you can see below:

As you can see, while looping through all the values for light levels, the debugger shows the jump in the values frequently. 

When I tried adding a delay close to 1ms between each value, it is looping through all the values.

Because of these jumps, limits of dimming can't be properly defined. 

Do you guys have any idea on this weird behavior and any solution because adding delay of 1ms while looping through 32000 values I like a lot?

Thank you.

[hmolesworth]

Looks like you have another process interrupting the trace; instead of 5 or 6 increment in the trace timestamp it jumps from (first example) 1052181 to 1052360  = 179 which is about 32 light levels or suspiciously close to the actual light levels "jumped" (19403-19371)=32. If a delay of 1mSec fixes the "jump" then you can assume that the interrupting process takes less than 1mSec to complete; perhaps it's a BLE transmission, or a serial port interrupt for a trace debug message .. ie it's not a light level jump but a jump in trace messages

[awneil]

Or it could just be a limitation of the Trace.

The Trace is not good for spitting out very large volumes of stuff;  it is quite easily overloaded - which could explain the "gaps" that you see...

[DeveloperZ]

Hey! Thanks And no, its not a trace issue, the CURRENT_LIGHT_INTENSITY variable gets affected and it doesn't reach same max values every time... and the "Jumps" are quite random too, so are we leaning towards some BLE transmission, interruptions or something related...?