test and adjust NeoPixel timings on multiple ports #6312
Conversation
There was a problem hiding this comment.
Didn't have time to test on any h/w but looked at all the timings in the code. The PIO code I'm most familiar with and looks good to me. The other ports I have done less work with but everything looked right to me matching the timings you are suggesting. But I would defer to someone who has more experience with those ports. If no one is available I can take a closer look later this week if required.
|
|
|
@PaintYourDragon probably of interest to you |
|
@dhalbert Indeed, of interest, thanks. Sounded like you already had this well under control, is why I didn’t chime in. If (when?) we ever have to confront this again in the future, I had some ideas on an ironclad once-and-for-all implementation (no more duty cycle debates). Notes are all in this CircuitPython code, so I’ll just attach the file here… |
|
@PaintYourDragon Thanks! I collected some data like this in an ad hoc manner while working on the PR, but this is an excellent approach if/when we need to revisit this. |
Reworked NeoPixel timings for a number of ports.
Fixes #5505.
Fixes #4102.
Tested with:
No work done on Spresense, i.MX, fomu, or broadcom ports.
The main issue was getting https://www.adafruit.com/product/5225 to work properly. It did not work on several ports previously. SAMD51 timings were also off enough that the first pixel was sometimes wrong.
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.
For reference, I added a datasheet summary to
shared-bindings/neopixel_write/__init__.c..