SDK • Re: Where does the DMA time go?

The code doesn't look quite right - for WS2812B the official timings are 400ns high, 400ns data value, 450ns low (total 1250), so a 8:8:9 ratio. Your code has 2:4:3 - which no doubt works but isn't what's specified. The overall timing is then set by the clock divider; so with your total of 9 cycles and the default CLK_SYS of 125MHz you have 156.25 CLK_SYS per 1250ns hence want a divider of 156.25/9 = 17.36. If you added the extra delays for 8:8:9 (total 25), the divider would be 6.25.

I did some experimenting with WS2812B timing by using a scope and signal generator and found that the on/off times not that critical
I used a signal generator generating a 800K 0-5V square wave and varied the duty cycle, sent that to a small strip of pixels. That emulating sending all '1' (all white) or all '0' to all pixels. I'd stop the generator to allow the pixels to latch all white or all offl
I then scoped what I was sending into the strip and what was coming out of the pixels, mainly focusing on the output of the first pixel.

My strips were purchased from BTF lighting, your milage may vary from mine.
I first noted that there's a 68nS delay from when a pixel receives the start of the bit frame to when it forwards it to the next pixel
The input must have a minimum ON time of 4% duty cycle or 50nS before you see anything going out.
Up to 27% ON duty cycle, or 337nS, the output has a ON duty cycle 23.5% or 293nS (later that seemed to be 25%/313nS)
From 28-38% input ON duty cycle (475nS) the output ON time does stretch until it reaches a point where it starts reading a '1' and jumps
At 39% ON duty cycle (488nS) the output mostly jumps to a fixed ON time clearly interpreting the input as a '1' but unstable
A5 40% ON duty cycle (500nS) the output is a fixed ON duty cycle of 58.5% or 731nS.
It didn't seem to care how small the OFF time was, but I didn't focus on that.

After 4 pixels, the output ON time didn't stretch in response to the original input ON time.
It was either 25% (312.5nS) ON time to represent a '0'
or 50% (625nS) ON time to represent a '1'
So the pixels not only level shift, they also reform the timings.

You could be just about perfect of dividing the 1250nS by 4, preamble be 1 clock, data 1 or 2 clocks, and end with 2 or 1 clock to finish up the time.
Then again, without any delays, the following PIO code needs 4 cycles with the preamble taking up a minimum of 2 cycles:You could divide the 800K by 8:
Preamble 2 cycles = 25%
Data 2 cycles = additional 25%, could even be 3 (additional 37.5%) where '1' would produce 50% or 62.5%
End 4 cycles (additional 50%), or 3 (additional 37.5%) if the data is 3.

I've had the timing set to 3/3/3 which would cause the output of the first 3 pixels to stretch the ON time for a '0' bit.
I suppose with a divide by 9, 2/3/4 or 2/4/3 might be more appropriate

voltage
I found that with VCC at 5V, the strip considered voltage as low as 2.7V as ON
VCC at 4V, minimum 2.1V to consider ON
Plenty of margin for input from a 3.3v MCU

Min delay between frames to trigger latch
Now the results of this test surprised me.
I tested by setting up my generator to send 24, 48 or 72 pulses of '1' which should make 1, 2 or 3 pixels light as white respectively, then pause for x period. I'd cycle power to the strip as a means to clear them but not stop the generator.
I got good results with inter-frame delay of 60mS or greater. Below that and I would either get no pixels displayed or more than intended. The strip I tested with is new, purchased only a month ago so I was surprised it wasn't closer to 300nS that is now specified.
Other strips I've used are 2-3 years old but are IP65 so I can't easily get to the individual pixels, and they are 300 pixel strips. Same BTF brand.

Statistics: Posted by DanMan32 — Sun Feb 11, 2024 2:43 am

---