Open egnor opened 1 month ago
E (98) rmt(legacy): CONFLICT! driver_ng is not allowed to be used with the legacy driver
@Makuna this looks familiar. It only happens with arduino-esp32 v3.0.x, in particular v3.0.0 thru 3.0.2. The problem is that the arduino core makes reference to the "new RMT" driver, so any other lib that still uses "legacy RMT" will trigger the bootloop error.
arduino-esp32 version 3.0.3 should have a solution.
Until 3.0.3 gets released, the smartest solution is to stay on version 2.0.14 (and maybe in general v2.0.x is preferable, when looking at the long list of breaking changes in 3.0.x ;-)
@egnor and @softhack007 I will leave this around; it is related to moving to the next core API. Currently, I have no implementation for the next API yet, it is on my list but isn't coming soon. I still have consumers using the older cores.
This is a failure on the core to reference something that will cause legacy API which are depreciated but still supported to cause such a failure. Please raise this with them to get an immediate fix.
FYI here's a corresponding issue with Adafruit's library: https://github.com/adafruit/Adafruit_NeoPixel/issues/375
For ESP-IDF v3 compatibility, Adafruit added a quick function to use the arduino-esp32 RMT layer, but, that requires spelling out all the timing transitions in a buffer (since the Arduino RMT driver doesn't expose the custom timing translation feature), which they allocated on the stack in show()
, which doesn't work for longer strips.
I assume FastLED and others are addressing this in their own way. (Or maybe FastLED doesn't use RMT?)
We use RMT. We are also broken.
Came here to see if NeoPixelBus fixed it... they haven't yet.
We are all in the same boat. IDF 5.1 is a painful break for everyone.
Describe the bug With some cores, such as
esp32s3
(for the Espressif ESP32-S3 dev board), simply referencing a default-method NeoPixelBus in the code (not necessarily actually using it!) causes a boot loop with an error message like thisTo Reproduce Steps to reproduce the behavior:
NeoWs2812xMethod
Expected behavior Sketch runs as usual.
Development environment (please complete the following information):
Additional context I believe this is why this happens:
neopixelWrite()
function which much like NeoPixelBus uses the RMT peripheral, using the "next gen" API https://github.com/espressif/arduino-esp32/blob/614c72b4d3e9fd04dcccfe313bb2353b3b0eea46/cores/esp32/esp32-hal-rgb-led.c#L5RGB_BUILTIN
macro is defined,digitalWrite()
will actually callneopixelWrite()
if that pin is written https://github.com/espressif/arduino-esp32/blob/614c72b4d3e9fd04dcccfe313bb2353b3b0eea46/cores/esp32/esp32-hal-gpio.c#L169digitalWrite()
directly or indirectly, that means ifRGB_BUILTIN
is defined, you end up linking inneopixelWrite()
and thus the "next gen" RMT driver, and if you're using NeoPixelBus you're also pulling in the "legacy" RMT driver, so that explodes