rp2pio: Transfer up to 32 bytes before checking background tasks

[jepler]

@jerryneedell noticed that this problem affected strips short enough to not use the DMA peripheral, thanks for the hot tip!

Instead of checking for background tasks after every byte transfer, try up to 32 transfers before attending to background tasks.

This fixes the problem I was seeing on my 5-pixel circuit.

Closes #4135.

I wrote this before seeing the simpler #4149. I think this MAY be a bit better than #4149, and here's why: Occasionally, background tasks and interrupts can immediately create new background tasks. This PR would ensure that up to 32 bytes were made available to the PIO peripheral before attending to them, while that one doesn't.

[jerryneedell]

Thanks -- I'll try this later today -- Credit goes to @gamblor21 for finding the DMA link to this issue.

[ladyada]

good teamwork - amazing!

[gamblor21]

I agree yours is a better implementation. I did not want to remove the background tasks all together as I wasn't sure of any potential side effects.

[jerryneedell]

Sorry to report this still not working for me.

using a 7 pixel jewel:

dafruit CircuitPython 6.2.0-beta.1-128-g5423e4966 on 2021-02-08; Raspberry Pi Pico with rp2040

>>> from board import *
>>> import neopixel
>>> import time
>>>  
>>> pixpin = GP27
>>> numpix = 7
>>>  
>>> strip = neopixel.NeoPixel(pixpin, numpix, brightness=0.3)
>>> strip.fill(0)
>>> strip.fill(0xff)
>>> strip.fill(0xff00)
>>> strip.fill(0xff0000)
>>> 
```  after the last write, pixel 0 is green -- all others are red....

[jerryneedell]

also ```Adafruit CircuitPython 6.2.0-beta.1-128-g5423e4966 on 2021-02-08; Raspberry Pi Pico with rp2040

from digitalio import *
from board import *
import neopixel
import time

pixpin = GP27
numpix = 7

strip = neopixel.NeoPixel(pixpin, numpix, brightness=0.3)
strip.fill(0)
strip[0]=0xff
strip[0]=0xff00
strip[1]=0xff00
strip[1]=0xff
strip[0]=0xff
strip[0]=0xff00

pixel 0 is not responding properly.

[jerryneedell]

hmm -- I had an "Airlift" connected to the Pi - it was not being used, but now that I have disconnected it, I am so far not able to reproduce the issues -- more testing to do....

[jerryneedell]

I have been unable to reproduce the issue with the Airlift disconnected....

[jerryneedell]

To be fair, I had more that just the Airlift connected.
I had the following connected:
ARILIFT -- lots of pins near the pin used for the neopixel
10Kpullups on SDA.SCL (GP0,GP1) - were for a previous test
pushbutton from RUN to GND -- to facilitate entering bootloader.

I have not determined which was the culprit...yet ... I just assumed it was the Airlift -- perhaps hastily.

With just the bare Pico -- my "jewel" is behaving very normally with this PR.

[jepler]

@jerryneedell let's talk about this in the discord meeting today

[jerryneedell]

Tested with #4160 -- both are working for me.

[dhalbert]

Tested by @jerryneedell and @gamblor21.

[tannewt]

One suggestion to simplify things. (I realize I'm a bit late. Thanks for fixing this!)

[tannewt]

I think it'd be clearer if you replaced the original if statements with while loops. That way you'd load up the 4 or 8 entry FIFO and then move on. 32 seems arbitrary and I'm skeptical you'd ever hit that many due to the FIFO size.

[jepler]

I chose 32 because it was the DMA threshold. I didn't check the FIFO size at all! I'll open an issue suggesting the clean-up, but try to get to it next time I'm working in this code.