Wi-Fi interferes with RMT peripheral

[darkwater]

I'm using an esp32c3 to drive 100 WS2812 LEDs. A simple rainbow animation at 60 Hz looks fine until I initialize esp-wifi, when the colors start to flicker once or twice per second or so.

I suspect there are interrupts happening with a higher priority than the RMT peripheral, causing some buffer swap to be delayed. Reading some posts from non-Rust users gives me the same idea. The RMT transmit call is blocking so I don't think any async tasks are stalling.

[bjoernQ]

My guess is that the problem is caused by the scheduling of the necessary tasks which need to run to make WiFi work

By default, the tick-rate (see https://github.com/esp-rs/esp-wifi/blob/main/esp-wifi/docs/tuning.md and https://github.com/esp-rs/esp-wifi/blob/a69545dc4c053b9cc9a7398df9250d16834526b5/esp-wifi/src/lib.rs#L92) is 100 Hz so it might take a long time until the main task gets a chance to run again. You can try another tick-rate (configured in cfg.toml) and see if that is enough to get it working

[darkwater]

It looks like it helps a little bit, although it's hard to tell for sure. Even at 1 Hz it still flickers. I've recorded two videos to give a better idea of what it looks like.

100hz.mp4

1hz.mp4

[bjoernQ]

I could imagine increasing the tick rate might help. There might still be problems if some code is run in a critical section which will delay switching to the main task but it might help

IIRC in the very beginning the default was even 1000 Hz

The thing here is that with a very high tick rate the CPU will spend a lot of time in just switching tasks but it takes longer until each task gets a chance to run

[MabezDev]

RMT is very timing-sensitive, as @bjoernQ is suggesting. In esp-idf there are configuration options to store the RMT code in RAM, so that cache misses don't interrupt the transmission (we don't have an equivalent in Rust yet :(). Increasing the priority might also help here, but as @bjoernQ mentioned if there are long critical sections there will still be flickering.

[darkwater]

In esp-idf there are configuration options to store the RMT code in RAM, so that cache misses don't interrupt the transmission

What do you mean here? I’m new to ESP and haven’t used IDF. My understanding is that the hal blocks on the transmission and copies new data into the peripheral’s ram while the transfer is going on (which should mayhaps happen in an interrupt?). Is there another place to store the data for the peripheral to use?

[MabezDev]

Is your code open source? It might be easier to help if we can see the code. Other than that I can only suggest general advice.

[darkwater]

Yeah, here it is: https://github.com/darkwater/home-leds

firmware/src/main.rs initializes esp-wifi amongst other things, and the call to RMT::transmit() is in firmware/src/ws2812_driver.rs

[bjoernQ]

A simple fix might be to run https://github.com/darkwater/home-leds/blob/48f39c9e8b55ffb0704709e077bdb8b5e3c09aa0/firmware/src/ws2812_driver.rs#L79 in a critical section - it should be fast enough to not interfere with esp-wifi

[darkwater]

Thanks, that does solve the flickering. I'll open an issue on the hal repo because that logic should probably be done in an interrupt handler, or at least documented to be susceptible to interference.