New LED hardware driver: WLED Pixel Bus

[DedeHai]

This is a major update adding WLED Pixel Bus written from scratch to replace NeoPixelBus and it packs a lot of useful features. From a user perspective the main improvements are less memory use and dynamic adjustment of LED timing to eliminate flickering by fine-tuning the timing from -30% to + 30% in 10% steps (dropdown menu).

The new hardware driver structure allows for fully dynamic updates of LED outputs and LED timings. It also adds glitch free parallel SPI output support on the C3 as well as parallel bit-banging on all platforms including ESP8266.
All parallel outputs (except bit-bang) use ping-pong DMA buffers instead of fully pre-filled buffers - memory usage is optimized and DMA buffers are independent of number of LEDs. Also the calculation from LED colors to DMA buffers is highly speed optimized, making the driver blazing fast - I saw 30% FPS improvements in some cases.
The fully dynamic nature of the driver allows for a "Custom digital bus" in the LED settings to support virtually any LED bus type out there - specify timing, number of color channels, invert any color channel or set any color channel combination. The driver also supports inverting the output signal on any pin (ESP32 only).

The LED config UI was updated to fully support the new driver options.

A lot more testing is required for all different kind of LEDs on all platforms. I am sure there is a ton of bugs and kinks to iron out.

I would like to take this opportunity to thank @Makuna for his outstanding work on NeoPixelBus which served me well as a reference on hardware configurations and special LED types.

• saves over 10k of heap on ESP32 and about 3k on ESP8266
• increases available LED outputs on ESP32 C3 from 2 to 14 (2x RMT, 4x parallel SPI, 8x bit-bang)
• increases available LED outputs on ESP32 S2 with 8x bit-bang if I2S is not available
• increases available LED outputs on ESP8266 3 to 6 (1x UART, 1xI2S DMA, 4x bit-bang)
• allows over 1000 LEDs again on ESP8266 thanks to reduced RAM footprint, it does not use a global buffer but writes to LED buffers directly which is slower but uses less RAM.
• adds support for TM1815
• improved low-brightness color accuracy to TM1814, TM1815 and APA102 by utilizing LED current settings
• improved color resolution on 16bit LED types (UCS8903, UCS8904, SM16825)
• if needed I2S (ESP32 and ESP32 S2) and LCD (ESP32 S3) driver can output on 16 parallel pins changing a #define
• automatic calculation and optimized use of multiple RMT memory blocks, reducing ISR frequency when not using all RMT outputs and thus increases FPS

ESP32 flash and RAM usage comparison (bit bang disabled)

using NeoPixelBus
RAM: [== ] 24.9% (used 81576 bytes from 327680 bytes)
Flash: [======== ] 83.1% (used 1306493 bytes from 1572864 bytes)
Free Heap: (6 outputs, 256 each): 79.8k

using WLEDpixelBus
RAM: [== ] 24.9% (used 81680 bytes from 327680 bytes)
Flash: [======== ] 83.0% (used 1306053 bytes from 1572864 bytes)
Free Heap: (6 outputs, 256 each): 92.8k

Summary by CodeRabbit

• New Features
  • Added per-bus Bus Speed Factor (SF/bsf) settings.
  • Added Custom Bus support with channel mapping, inversion, custom timing, and per-channel colors.
  • Expanded supported output driver/type options (bit-bang, parallel SPI, RMT, I2S, LCD where available) and added new LED type options (e.g., TM1815 / custom bus).
• Bug Fixes
  • Improved ESP8266 direct-to-bus pixel handling and refined gamma/brightness behavior across realtime and particle rendering.
• Chores
  • Updated capability limits and the LED settings UI + config import/export for the new bus features.

[Merikei]

This is great! Thanks so much!

I built for esp32c3dev (no build option edits)
at commit b8e9b53
Date: Sat Jul 11 15:38:13 2026 +0200
bugfix in UI for ESP8266

then flashed OTA.
Non of the usual glitches, even when stress-tested (4 browsers actively using the web interface, peeking, transferring data over the WiFi it's using),
however it does keep crashing and restarting, even when only Home Assistant is connected to it, between every 15~45 minutes, based on a few hours of testing.

• LED outputs
  • Driver: RMT
  • Timing: default
  • 1: WS281x RGB
    • Len: 1
    • GPIO: 8
    • (LED built in to the dev board, didn't glitch even with glitchy firmwares)
  • 2: APA106/PL9823 RGB
    • Len: 100
    • (sold as “WS2812B… WS2812… BTF-LIGHTING… Epistar”, but was trying different options to see if that improved things in the previous glitchy firmware (tested recently: 0.15.3, 16.0.1,17.0.0-dev (2607060)) where the first few pixels glitched)
    • GPIO: 4

Bord sold as “TENSTAR ESP32-C3 Supermini Plus Development Board WiFi Bluetooth ESP32 C3 Super mini V2.0 Red Board”

esptool v5.1.0
Chip type:          ESP32-C3 (QFN32) (revision v0.4)
Features:           Wi-Fi, BT 5 (LE), Single Core, 160MHz, Embedded Flash 4MB (XMC)
Crystal frequency:  40MHz

Not a power supply issue: reboots while LEDs are off, but can turn to 255/255 white for 5 min and it's fine & wasn't happening on glitchy firmware that used the same PSU.
Not a Max. TX power issue: turned down to 8.5 dBm VS 15 was fine on glitchy firmware.

Happy to perform tests or get serial logs if you need?
But this is also a draft PR and there have been commits since I built it yesterday so it may be a known issue.

[DedeHai]

thanks for testing. Yes I am aware of this bug but I was not able to track it down, it's something to do with low level RMT stuff from espressif, maybe a buffer race condition or whatnot. If you use the SPI driver instead of RMT there should be no crashes.

[DedeHai]

@willmmiles I made some progress and think this PR is coming along nicely. Still a lot of work left and I hit a bit of a road-bump on the C3: for some reason it crashes when using RMT. I tried to track it down and it all works up to the point where rmt_write_sample() is called in show(). Under heavy WiFi traffic I can easily get it to stall within a minute, everything freezes up for a few seconds, then reboots, similar to the issue with using the high priority driver but I am not using that on the C3.

[willmmiles]

@willmmiles I made some progress and think this PR is coming along nicely. Still a lot of work left and I hit a bit of a road-bump on the C3: for some reason it crashes when using RMT. I tried to track it down and it all works up to the point where rmt_write_sample() is called in show(). Under heavy WiFi traffic I can easily get it to stall within a minute, everything freezes up for a few seconds, then reboots, similar to the issue with using the high priority driver but I am not using that on the C3.

I certainly wouldn't rule it out. IIRC the signature to look for is a watchdog timeout in vPortYield(). So far my suspicion remains that there's a hardware race with the interrupt controller handling nested interrupts when the software interrupt is pending -- there's some path that results in failing to clear the pending bit, so vPortYield() waits forever. The high priority RMT driver just hits it routinely, the bug is always lurking.

[DedeHai]

ok, I will leave it "as is" for now, it just was strange that it crashes quite soon (minutes) when stressing it and I can not get 16.0 to crash at all (have tried for hours under full load). Maybe it has also something to do with RMT init sequence, I did not check if its done the very same way as NPB.