Fix bit timing

[jepler]

There were 3 cycles of always-low time missing, making the bit time closer to 1us than 1.25us.

This apparently was OK with whatever strips I tested way back, but not with the saleae ws2812b decoder.

Now, a trace generated on either rp2040 or rp2350 decodes in saleae and has the expected content.

[dhalbert]

I did a lot of testing in adafruit/circuitpython#6312, and adjusted the PIO program timing for neopixel_write. How do those timings compare with these?

[jepler]

Your final conclusion seemed to be:

The timings from this code are now:

• zeroes: 4 cycles high + 12 cycles low, about 312ns high, 938ns low
• ones: 9 cycles high + 7 cycles low, about 703ns high, 547ns low

Your conclusion was:

The timings have been adjusted to:
about 300 ns high, 900 ns low, for a zero
about 700 ns high, 500 ns low, for a one
These vary per implementation, based on implementation constraints.

Except for my bugs, my timings were intended to match what was in the core implementation of neopixel for rp2 family micros:

// NeoPixels are 800khz bit streams. We are choosing zeros as <312ns hi, 936 lo> and ones
// and ones as <700 ns hi, 556 ns lo>.

Your overall timing is faster than mine (833kHz vs 800kHz) overall but my "high" timings are very close to yours and I'm closer to what I thought was the received wisdom frequency of 800kHz.

[dhalbert]

Your overall timing is faster than mine (833kHz vs 800kHz) overall but my "high" timings are very close to yours and I'm closer to what I thought was the received wisdom frequency of 800kHz.

I tested something like five varieties until they all worked. But I felt constrained by the granularity of the PIO cycles, so maybe I didn't quite reach optimum. We can leave mine alone, I guess, unless you think they could use touching up.

[dhalbert]

👍