High-priority interrupt driver for ESP32 RMT devices

[willmmiles]

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.

[willmmiles]

I think this is now ready for review. Some design notes:

• The basic approach is an optimized RMT output driver, driven by a high-priority interrupt to ensure stability.
• This requires a variety of different techniques to work around ESP-IDF bugs/limitations
  • If enabled, the bluetooth high-priority interrupt consumes the available slot on Xtensa systems; fortunately it exposes a usable API to link our own ISR to it
  • Many versions of IDF incorrectly flag the high priority interrupt as reserved
• I'm not thrilled at vendoring in the IDF v4 rmt_ll API to support IDF v3, but it seemed like the lesser evil versus a pile of #ifdef blocks down in the functional code.

I've tested with WLED on ESP32, ESP32-S2, ESP32-S3, and ESP32-C3, using ESP-IDF v3 and v4. I don't anticipate trouble with pioarduino/ESP-IDF v5, though I don't have a testbed yet.

Looking forward to your feedback. If there's anything further I can do, please don't hesitate to ask.