Request for upstream merge of FastLED's improvements to espressif's led_strip (IEC-262)

[zackees]

Is your feature request related to a problem?

Hi there, core dev for FastLED.

We made a significant enhancement to the led_strip library from espressif.

We want to merge some of the successes back into espressif. Also, I'm going to mention some of our failures with more advanced features we tried to bolt on.

Two most significant features

these are both ready to integrate now

• async draw. Both RMT and SPI. This is extremely easy to implement and your code base was almost already there. This produces MASSIVE performance gains as the next frame is free to be computed while the current frame hardware bitbangs out.
  • API link
• exposing led timing T0H...T1L
  • API link
  • allows support for any other clockless chipsets like WS2816, WS2815, etc... to be represented by your strip.
  • Instead of passing an enum for the LED strip type, the user passes in the encoder timings explicitly.

Abandoned feature: Moving RMT controllers from one GPIO to another, enabling RMT-worker pools.

• This is missing in RMT5, but was present in RMT4
• We originally did this ourselves through eager teardown after render and RMT reinstatation on next draw. This would allow us to preserve our RMT-workerpool when number of strips > built in RMT units.
  • Our design featured
    • Changing the LED strip array from built into to the RMT controller in the api, to being a pointer.
      • This allowed us to tear down the RMT unit after completion without fragmenting the memory with a variable length embedded pixel array object.
      • What went wrong? After RMT teardown, the GPIO pin on many ESP32-Wroom devices was left floating which caused a transient HIGH pin state with enough amplitude to trigger an errant T1H signal to the LEDs on the next first pulse. It was discovered that the fix was a weak pulldown on the pin, but this was discovered after we abandoned the feature and rebased off of led_strip 3.0.

Broken Feature: RMT Memory settings

• We doubled the memory for ESP32-C3 from 48 -> 96 to prevent flicker during WIFI. According to the datasheet there is 192 RMT symbols that is shared between all RMT devices on -C3. So at 96 RMT words per RMT device, we should have the usage of 2 strips with flicker free LED output during WIFI. However, according to this bug report only one is available before the led_strip API issues a readyE (1104) rmt: rmt_tx_register_to_group(152): no free tx channels. It's entirely possible the user happens to be using another RMT for something else or a WS2812 led status light is being implicitly used. I'm following up with this.

Maybe useless feature: RMT DMA

• We only get one DMA channel on RMT. The docs don't mention this. We have never been able to get this to work in our codebase. Although we suspect this is our issue as https://github.com/suda-morris was able to help us prove with a unit test that this does indeed work. I've submitted a PR to include this in your unit tests, but espressif has yet to review this PR.
  • We were really hopeful that RMT-DMA was going to be the answer. We aren't entirely sure what the specifics are for why this can't be supported on more than one RMT channel. There is no documentation on whether this allows more memory to be allocated to the non-rmt strips. We'd have to experiment on our side to see if this works, but we have an issue that we need to test this across the DMA supporting chipset family, however, this may only actually be the ESP32-S3 chipsets, as non of the other chipsets seem to support DMA.

Broken feature: SPI leds during WIFI transmission

• A bug has been filed on this issue by others.

Broken Feature: RMT on ESP32-S3 loses 3 RMT units instead of 2 when doubling the memory.

• This is to reduce flicker with wifi. We expected that doubling the memory would reduce the available RMT workers by half (-2) but instead it results in losing three workers. I'm having trouble finding our bug reports on this, so my apologies.

Missing Feature (SPI): No ability to change LED timings.

According to the code base, the timings are hardcoded in a weird DMA format. We are not smart enough to reverse engineer this so that we can set the timings for other WS282X chipsets.

Missing Feature: I2S Based Led Strip

This is a big feature and a third party (Yves) already implemented this which was integrated into FastLED. We have versions for ESP32dev and ESP32-S3 for IDF 5.1+. This driver is serving as our "escape hatch" for users not being able to drive enough WS2812 leds in parallel. How exactly it works is a bit mysterious for me but could be alien technology (just kidding). It somehow works by transposing leds into a format the DMA channel expects. We can drive up to 16 leds strips with ESP32-S3, and 24 strips with ESP32dev in IDF4.x. I've recently made the ESP32dev I2S driver compiler compatible with IDF5.x, but I have no idea if it works.

Summary

Two very significant features can be implemented right away: async draw and led chipset timings for RMT. These are production ready and extremely well tested.

I2S demonstrations are available. It's in C++ though and would need to be re-written for espressifs purpose. But their ability to drive an insane number of LEDs has been proven to be extremely valuable.

For RMT the biggest challenge for us is being able to move RMT workers from one GPIO to another. It would be really awesome if this can be done without an IDF core change.

Other bugs with RMT and SPI were presented. Not sure what the issue is or what the fix is.

Links

• FastLED's enhanced led_strip component library:
  • https://github.com/FastLED/FastLED/tree/master/src/third_party/espressif/led_strip/src
• Yves I2S driver
  • ESP32dev: https://github.com/FastLED/FastLED/blob/12f8e82d64b445217694362f793fea5f6b93f1fe/src/platforms/esp/32/i2s/i2s_esp32dev.h#L1
  • Esp32-S3: https://github.com/FastLED/FastLED/tree/master/src/third_party/yves/I2SClockLessLedDriveresp32s3

Thanks for your attention:

~Zach Vorhies - core maintainer for FastLED.

Describe the solution you'd like.

No response

Describe alternatives you've considered.

No response

Additional context.

No response

[Jf7Dee]

Broken Feature: RMT Memory settings
I ran the tests with 4 different WS2812 strips, including one built on the board itself ( the Lolin ESP32 C3 pico).
I also tested it with different combinations of those strips.
Adding to it, even if no strips are attached, the problem persists.: it is really while calling the 2nd "fastLED.AddLeds" attachement.
The same behaviour happens with the SeeedStudio XIAO ESP32-C3, which does NOT have an onboard WS2812, nor a regular led.
Both Lolin and XIAO chips will reboot while having 2 strips added.

Included is a test sketch. If only first AddLeds is present (and thus the 2nd is commented), no problem. If 2nd is present, the C3 will reboot.
It also does not matter which attachment is commented out.
As it can be seen, no additional call could trigger the use of a RMT, even accidently.

The XIAO ESP32S3 does NOT show this behaviour, nor an ESP32 WROOOM dev module.

Package library used is : https://espressif.github.io/arduino-esp32/package_esp32_index.json
FastLED version currently used is 3.9.13

ESP32_Lolin_TwoStrip_BugReport.ino.txt