Improve Multi-strip support (option to use FastLED's I2S 24-way parallel driver)

[rorosaurus]

>Is your feature request related to a problem? Please describe.
Existing multi-strip support is limited, especially for ESP32-S3, ESP32-S2, and ESP32-C3. Though existing support is more flexible (works for clocked chips, or different protocols), only having 2/3/4 strips per ESP32 can be restrictive for many projects - often leaving significant performance on the table. This could increase complexity (extra unnecessary ESPs) and construction time (awkward data return lines) for certain projects.

>Describe the solution you'd like
It would be nice if we could create an option to use /u/Yves-Bazin and /u/samguyer's 24-way parallel driver for ESP32 to drive RGB only, clockless strips of the same chip type. This would optionally increase the max strips to 24 for ESP32, ESP32-C3, and (I think? I haven't tested) ESP32-S2/S3. Then we could enjoy the benefits of both worlds! I suspect many multi-strip installs meet those requirements, so such a feature would offer those projects extra density/resolution/flexibility.

>Describe alternatives you've considered
Sometimes it's not possible to join strips together in a serpentine pattern (or 2D matrix) for aesthetic or functional reasons. For example, I'm building a beaded door curtain where chaining together the data lines at the bottom of each strip would result in loops that can snag upon entry. I've worked on other projects in the past that used 18 strips, where the physical layout of the strips would have made it very difficult to chain together data lines. That forced me to fallback to using FastLED when I would've truly loved to enjoy all the benefits of WLED adds to an art install!

>Additional context
#104 addressed the initial implementation of multi-strip support
Current Multi-strip Support - WLED
clockless_i2s_esp32.h

Thanks everyone for making WLED the best! It's been a privilege to watch this project grow and develop over the years! Here's to many more!

[blazoncek]

WLED does not use FastLED drivers.

[rorosaurus]

Yes, I'm proposing a new feature to use FastLED drivers when it's beneficial.

[blazoncek]

Changing the LED driver would mean almost rewrite WLED from scratch. Not in any foreseeable future.

There is, however, a similar thing in recent release of NeoPixelBus. Implementing that may take a while.

[softhack007]

Yes, I'm proposing a new feature to use FastLED drivers when it's beneficial.

We cannot "jump" between drivers; WLED uses Neopixelbus for addressable LEDs. If you have an example piece of code for a new driver, the maintainer of NeoPixelBus (makuna) might be happy to try and implement something similar.

There is, however, a similar thing in recent release of NeoPixelBus. Implementing that may take a while.

I remember there is a "8x/16x parallel" driver in NPB. https://github.com/Makuna/NeoPixelBus/wiki/ESP32-NeoMethods#parallel-channels . I've made some experiments with this I2S parallel driving mode, half a year ago. At that time, there were some strong drawbacks for general use in WLED:

1. RAM needed is simply insane. I've tried 1200pixels, evenly distributed so all "8x parallel" channels were in use. Free RAM in wled dropped below 40Kb, making our software absolutely unstable so it crashed every few minutes (WiFi dies, UDP out of memory, webserver crashes, etc).
2. "8x/16x parallel" driving is only possible right now on "classic esp32", because the driver abuses a specific mode of the I2S units. According to Makuna, this specific I2S mode is not available on -S3/-S2/-C3, so won't help with new MCUs.

Some references:

• https://github.com/Makuna/NeoPixelBus/wiki/ESP32-NeoMethods#parallel-channels

• Esp32: Support I2s 24 parrallel mode Makuna/NeoPixelBus#270

• ESP32 I2S Parallel driving external shift register Makuna/NeoPixelBus#648

• ESP32-S3, ESP32-C3: investigate new method to use "General-purpose DMA" units Makuna/NeoPixelBus#598

• Support for ESP32-S3 peripherals Makuna/NeoPixelBus#605

• ESP32 I2S#1 8x parallel driving and audio input on I2S#0 Makuna/NeoPixelBus#697 (comment)

[rorosaurus]

Ty for the info! I wouldn't have guessed changing the driver would require a full rewrite, that's quite surprising to me. I'll have to look closer at what calls are made to NPB.

I don't have an S2/S3 to test with, but I can confirm the FastLED 24 parallel driver works on C3 (I tested 13 parallel outputs) using I2S just like the classic ESP32. Based on the esp-idf documentation, I think it should work for S2/S3 too? Though only classic ESP32 and S3 have a second I2S interface if we want audio reactive input. Maybe NPB uses a different mode.

I'll look at NPB's implementation and test it on my C3 - I didn't know they were also trying a similar approach. I wonder how they differ, given the 16 vs 24 max parallel and the drastically different memory usages.

[blazoncek]

Played with parallel I2S output and as of NPB 2.7.9 it is useless for anything beyond 250 pixels per output (for 8 channel I2S, 16 channel will have limit of 125 pixels).
Reason being huge RAM demands from I2S DMA buffers.

[rorosaurus]

Useless as in poor refresh rate? Thank you for that investigation!

In SmartMatrix and others, I'm familiar with using external PSRAM to help alleviate the limited DMA memory. Is there any chance the bottleneck you're seeing is of a similar type that could be addressed in this way? I know quite a few dev boards that come with PSRAM, which could be fair requirement for mass parallel output.

[blazoncek]

Please provide links.

[softhack007]

n SmartMatrix and others, I'm familiar with using external PSRAM to help alleviate the limited DMA memory. Is there any chance the bottleneck you're seeing is of a similar type that could be addressed in this way?

I don't think that PSRAM will help. We had a version that could use PSRAM for LED buffers and effect runtime data. However, on an esp32 WROVER board (rev.3) this resulted in heavy framerate drops --> Like 60fps when using normal RAM, but down to 5-15 fps when using PSRAM.

I haven't checked if the performance on -S3/-S2 is better, but the bad results on classic esp32 made us conclude that PSRAM is not good for fast changing data. In WLED we found another use for PSRAM - JSON data and "ajax" style UI communication.

[blazoncek]

BTW I'm working with @Makuna on resolving this issue. I have WLED working with 8x 400 pixels ATM.

[coliniuliano]

@blazoncek Any update? Do you have a branch you're working on that I can play with or take a look at?
I'm eagerly awaiting more strips on the S3 and happy to contribute.

[blazoncek]

The template is available in 0_15 and you'll need to uncomment x8 I2S and replace existing I2S. It should be obvious.

[Makuna]

Note, C3 and S3 are not supported with parallel yet. They changed the API due to pulling the parallel support out of the i2s hardware. It's there in another piece of hardware, so requires more research/code to support.

This is being tracked by Makuna/NeoPixelBus#605

[blazoncek]

Available in 0.15.0-b3 and later, build 2406120 or greater.