Bad pixel values with Wifi
bkgoodman opened this issue · 4 comments
The project works GREAT. However, When I add Wifi to my project - I often get pixels set incorrectly/randomly. The problem predictably gets much worse if I start pinging the ESP32 like crazy (more network traffic).
I have seen similar cases in other project where interrupts are enabled and it throws the timing of of the pixel updates. I am assuming this is is a problem where network interrupts (or threads?) are being prioritized over the RMT interrupts, making the additional "half" buffer fills happen too late?
I'm struggling to fix this - don't know if anyone else has any more insight for me,
Hi @bkgoodman. That is interesting. I ran a chain of 8 of these LEDs connected with a board that was using WiFi as well. I would see stalls in my animation sequences when web requests were being made but not incorrect/randomness in setting the LED colors.
How many leds do you have chained? Have you tried increasing mem_block_num? If not maybe try bumping it up to 8 (the max if your only using 1 RMT channel.) and see if that helps.
As far as I understand, the peripheral only uses interrupts to copy the items to be sent into the perhpheral's internal memory space. Therefore you shouldn't see incorrect LED colors, only potentially pauses in sequencing. I would think that incorrect colors would mean the pulse timing isn't configured correctly. I think there are variations of this device that have different timing.
@JSchaenzle I am running 96 pixels - so I don't there there is any way I can do this in a single DMA. I am of the belief that if there is a pause between the individual RTM blocks, that this is what causes the issue. (I just don't think RTM was really made for data streams this long). I am asking on ESP IDF forum about trying to reprioritize RTM vs. Wifi (or even disabling Wifi interrupts for a bit) - or running Wifi vs RTM interrupts on different cores...I don't have any answers yet. Thanks for the reply!
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 run the thread which initializes the library (and 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. I would advise a mention of this in the readme. ;-)