[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.

• dynamic uptes of LED timings at runtime
• saves over 10k of heap on ESP32 and about 3k on ESP8266
• increases available LED outputs on ESP32 C3 from 2 to 13 (1x 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 7 (2x 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.

[DedeHai]

@netmindz @willmmiles I finished the refactor and fixed quite a few bugs and did a full audit & review of all the WLEDpixelbus files. It is in a much better and cleaner state now and very close to merge-ready. If any of you want to do a review, now would be the time.
I will have an AI do one or two passes of full review to iron out some discrepancies that I found but those are minor things like naming inconsitencies or some UI settings that are inconsistent. The TODO list is still quite long but all of those things are issues that can be addressed later.
What I still want to do is run all drivers on all platforms and also test different LED types to see if any regression creeped in but from my in-between testing over the past weeks all was looking quite good and working.

[netmindz]

Is the usermods build still using V4?

[DedeHai]

Is the usermods build still using V4?

apparently it is. I can update it to extend esp32 V5 and see what happens