Interrupt Priorities (Wifi, Disabling...)

[bkgoodman]

I am using a Neopixel library which uses RMT to double-buffer DMA out to the Neopixel strands. i.e. - Fills half the buffer while sending the other half, then when an interrupt indications completion, it sends the other half and vica-versa.

This worked great - until I added Wifi to my project. Now it works most of he time - but I get cases where the data going to the pixels sometimes gets corrupted - and this gets much worse when there is network traffic being thrown to the board. Past experience (other boards/environments) tells me that this is due to [Wifi] interrupts interfering with the very sensitive timing required of the pulses going out.

In past simpler cases, I've just "disabled all interrupts" to solve this problem. But I cannot due that here due to the fact that we're relying on RMT interrupts to make this happen (and the code is otherwise asynchronous, i.e. kernel task stuff needs to work).

So I'm concluding that the best solution for this would be to prioritize RMT over Wifi [interrupts]. This seems "correct" in the general sense in that things that rely on real-time characteristics for human-perceivable things (like audio) should receive high priority.

But:

1. I can't figure out how to do that?
2. Is this really the best way to do this?

Anyone know how to do this, or could advise a better way to approach the issue? (i.e. Something weird - like pushing NeoPixel code to a different core than Wifi?)

[ESP_Sprite]

From what I remember from other discussions, some other LED driving libraries also had this problen. They worked around it by giving the RMT channel the LEDs are on more RMT RAM (you can give one RMT channel the RAM of the next few channels as well) to create a bigger buffer.

[bkgoodman]

Yea. I can't because I have too many LEDs - I'd overflow all 8 channels.

Other idea: Any way to affine the RMT and Wifi interrupts to different cores??

Is there a way to change priorities? The docs were a little unclear.

[bkgoodman]

FYI - Got it working MUCH better. RTM docs for rtm_isr_register say "The handler will be attached to the same CPU core that this function is running on." Given this, I used xTaskCreatePinnedToCore to registers the rtm_isr, thus affining it to core 1.

Thus - when I do this - even when I throw lots of web traffic of flood pings, I get perfect integrity of the data being sent to the pixels.