Refine neopixel timing

[dhalbert]

Users have seen some glitches writing NeoPixel strings on SAMD51 with CircuitPython. I took some timings in July 2020 of the NeoPixel one and zero waveforms, both for the Arduino code and neopixel_write. It seems like some SAMD51 times could be adjusted

@PaintYourDragon You mentioned recently about the "1/3 - 2/3" rule of thumb for NeoPixels, if I remember right. Do you see marginal values above, especially in the SAMD51 CircuitPython columns? Thanks.

[PaintYourDragon]

Revisiting NeoPixel timing is One Of Those Things I’ve Been Meaning To Get Around To But There’s Always More Pressing Issues. The “1/3 - 2/3 rule” isn’t so much a rule as just a hacky thing that seemed to work for Adafruit_NeoPixel_ZeroDMA and Adafruit_NeoPXL8 but isn’t grounded in science, datasheets, or anything else. It might fall apart on really long runs, I haven’t checked.

Because datasheets lie, and because NeoPixel-alikes reshape the signal on the way out, a winning strategy would most likely be to time the output from the first pixel rather than the microcontroller. I’d be inclined to average the measurements over several specimens of each type (WS2812, WS2812B and SK6812, maybe others) and then model the software timing after that. At least we know 800 KHz is a Known And Valid Constant Of The Universe.

The SAMD51 first-pixel issue might be related to caching. It looks like common_hal_neopixel_write() is disabling instruction and data caches on certain SAMD devices, which is good and desirable for deterministic timing … I’d just double-check that it’s actually being compiled in on whatever the test device is. The Arduino library does some dirty pool with the SYSTICK counter instead, so it’s immune to caching and overclock settings, but I’m guessing CircuitPython avoided that strategy on purpose because Reasons.

If experiencing glitches, I’d suggest testing the same pattern with Adafruit_CircuitPython_NeoPixel_SPI if one can afford the RAM. If this works, then yes, it’s likely a timing issue (regardless, I think this will fix the first-pixel problem). If it still glitches, then “bit timing” is a red herring. Other things that can cause glitching include lack of level shifting (WS2812 variants are right at the threshold of often-working with 3.3V logic, but really should be level-shifted, while SK6812’s fare better at this) and sagging power, in which case:

1. Try a less bright set of data to the pixels. If that doesn’t glitch, then it’s likely a too-small power supply.
2. Try adding a 50 to 100 uF cap every meter or so.
3. If powering a long strip from one end, don’t do that.

[tannewt]

Looks like this is still happening: https://forums.adafruit.com/viewtopic.php?f=60&t=189442

[dhalbert]

Looking at the output of a NeoPixel on Itsy SAMD51 at 5V D5 pin, with the current code, I see 1.28uS total bit time:
1: 320ns high + 960ns low
0: 160ns high + 1.12us low
I see some 1.12us bit times

[dhalbert]

RP2040 Itsy 5V D5 does not have this glitch, and is using PIO for precise timing. RP2040 times in ns:
input zero: 416 high / 832 low
input one: 832 low / 416 high

from the far end Neopixel of an 8-NeoPixel SK6812 string:
output zero: 268 high / 978 low (varies slightly by a few ns)
output one: 698 high / 550 low (varies slightly)

[dhalbert]

Datasheet timings:

// From the SK6812 datasheet:
// T0H 0 code, high level time 0.3µs ±0.15µs
// T1H 1 code, high level time 0.6µs ±0.15µs
// T0L 0 code, low level time 0.9µs ±0.15µs
// T1L 1 code, low level time 0.6µs ±0.15µs
// Trst Reset code，low level time 80µs

// From the WS2812 datasheet:
// T0H 0 code, high voltage time 0.35us ±150ns
// T1H 1 code, high voltage time 0.7us ±150ns
// T0L 0 code, low voltage time 0.8us ±150ns
// T1L 1 code, low voltage time 0.6us ±150ns
// RES low voltage time Above 50µs

// From the WS28212B datasheet:
// T0H 0 code, high voltage time 0.4us ±150ns
// T1H 1 code, high voltage time 0.8us ±150ns
// T0L 0 code, low voltage time 0.85us ±150ns
// T1L 1 code, low voltage time 0.45us ±150ns
// RES low voltage time Above 50µs

Note that T1H especially varies quite a bit, and if we got by the datasheets, we need to choose a happy medium.