The timing seems very tight to the tolerances of the chip (>50us) and I can't find any code which accommodates any flush of the 8-word FIFO buffer. Ws2812::write adds 60us onto Ws2812Direct::write but that only blocks until the write to the FIFO buffer is complete, not until the PIO has processed it. In the worst case I think this lag could be -
8 (word tx only FIFO buffer) x 3 (colours) x 8 (bits) x 1.25e-6 (800kHz) = 2.4e-4 = 2.4ms
The original example from the RP Pico datasheet uses a value of 10ms. This seems large enough to cover any required flush and the reset signal itself. However, 60us does not.
Please note I haven't taken a probe to the actual output or observed any real-world problems. I'm just trying to understand it from the specifications and the code written. A perfectly reasonable answer would be that someone attached a scope to the pin and observed the real-world timings (assuming sufficient data to fill the buffer)!
It is indeed taken from the 50μs specified in the ws2812's datasheet with a little bit more just in case.
However, you're right that before waiting for that delay we should also wait for the FIFO to be emptied.
I'm curious how the reset signal duration value of
60us
was calculated?The timing seems very tight to the tolerances of the chip (
>50us
) and I can't find any code which accommodates any flush of the 8-word FIFO buffer.Ws2812::write
adds60us
ontoWs2812Direct::write
but that only blocks until the write to the FIFO buffer is complete, not until the PIO has processed it. In the worst case I think this lag could be -The original example from the RP Pico datasheet uses a value of
10ms
. This seems large enough to cover any required flush and the reset signal itself. However,60us
does not.Please note I haven't taken a probe to the actual output or observed any real-world problems. I'm just trying to understand it from the specifications and the code written. A perfectly reasonable answer would be that someone attached a scope to the pin and observed the real-world timings (assuming sufficient data to fill the buffer)!