High-priority interrupt driver for ESP32 RMT devices #892
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Alas, it's no longer efficient enough to operate.
- Strip down ISR to the essentials - Hook the Bluetooth driver instead of NMI in case of conflict
Fix S2, S3, and unsupported (ESP8266) builds.
Small count values seem to occasionally cause bit-shifts in the output.
Expand feature/bug detection of ESP platforms.
This was referenced Jul 31, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch introduces an implementation of an RMT driver using a "high priority" interrupt on ESP32 boards. The intent is to solve flickering problems due to interrupt latency caused by the FreeRTOS scheduler, which blocks interrupts long enough for WS2812 strips to overflow the tiny RMT buffers.
There's still quite a bit of work to do on this code. I'd like to ask for a design review while I continue to fine-tune it. Stylistically it's also still a bit of a mess, please pardon the dust while I clean up the development shims.
Currently this is working in my WLED builds for ESP32 IDF v3 and v4, and ESP32-S2 with IDF v4. I intend to test ESP32-S3 shortly and then consider an implementation for the RISC-V based line. I expect that it will also work with IDF v5 with minor modification, though I would recommend the IDF driver over this one on DMA-capable chips.
The XTensa assembly code is derived from the ESP-IDF v4 Bluetooth high priority interrupt handler; although somewhat ironically, if that driver happens to be linked, it can be co-opted in to serving that purpose directly. I've also pulled in some of the IDF v4 RMT HAL for shimming on IDF v3. The original code is under the Apache 2.0 license which I believe should be compatible with this library.
I've elected to implement this as a parallel interface from the existing driver as it cannot coexist with any other RMT users. This offers application authors a choice of performance vs compatibility, rather than presuming specific requirements. The timing specification classes are shared between both implementations.
Lastly I implemented but ultimately rejected a "catch and restart" regime similar to the NeoEspBitBangMethod. Unfortunately, it's not possible to arrange that the RMT interrupts correspond to pixel boundaries -- on some chips, RGBW or RGBWW pixels are actually too big to fit in one interrupt -- so it would still lead to visible corruption/flickering. I opted to remove that code in favor of keeping the ISR simple. I do have it handy if you think there's a use case for it.
Thanks in advance for any comments or guidance you can offer.