High speed USB serial port LED strip driver for HyperHDR using ESP32 or ESP32-S2 devices. Multi-segment & multi-core support.
MIT License
Bot releases are visible (Hide)
Add true parallel output for HyperSerialESP32 based on development version of Neopixelbus library that already includes some of my changes (https://github.com/Makuna/NeoPixelBus/pull/609 https://github.com/Makuna/NeoPixelBus/pull/606).
This feature is fully supported by ESP32 and ESP32-S2. Finally we switched to my optimized for HyperSerialESP32 fork: https://github.com/awawa-dev/NeoPixelBus
When using multi-segments in parallel mode, both segments are perfectly in sync: the signal for both segments is generated at exactly the same time.
Both single & multi segment mode are using live prefill processing now!
Two frames can be render&pre-render at the same time. Pre-filling provides a back buffer mechanism with little impact on RAM: there is no need to store a full second buffer, which can be a critical issue with larger LED strips or ESP32-S2. It is synchronized with DMA buffer processing.
fixed critical I2S bug in the core rendering library that could stop ESP rendering under certain circumstances and required the ESP board to be reset
better thread synchronization between the serial port client and the render&processing unit using new semaphore.
switched the ESP32-S2 from a resource-hungry real-time RMT to an I2S renderer.
update espressif32 to 6.0.0
On the following screenshot HyperHDR and ESP32 & ESP32-S2 with HyperSerialESP32 are handling 1800 RGBW LEDs at the same time (two 900LEDs segments). First two lines are for ESP32-S2 sending output to the two LEDs segments, the third line is rendering new frame busy status (or sleeping and waiting for DMA buffer to be freed), the fourth line is is awaken and filling part of DMA buffer that was already sent. Next four lines are for the second device: ESP32 and its two 450 RGBW LEDs segments. RGBW LEDs (sk6812) requires much more data to be stored in memory, prepared and sent than RGB like ws2812b.
This shows how prefill for the second frame is started immediately while the first frame is still being rendered. It waits till DMA reports that it;s already processed part of the i2s buffer (with the first frame's data) so we can safely fill that part (with the second frame's data) and wait for the next call. Without it filling i2s buffer after the first frame is sent, can take up to few ms causing delay between frames.
It's highly recommended to customize the serial port speed in the firmware and set it to the maximum that your boards support e.g. 4000000 for CH9102x and 5000000 for ESP32-S2 lolin mini (CDC). For multi-segment mode we are no longer limited by 800KHz Neopixel LED strip data bus.
Published by github-actions[bot] almost 2 years ago
Needs latest HyperHDR v19 beta 2 development version
Use separate thread for the serial port handling and data processing to improve performance stability
Add initial support for esp32-s2 mini boards. This board supports up to 5Mb speed.
Removed unnecessary double buffering of LED data for better performance
Multi-segment support. Currently two segments are supported because of preferred ESP32 i2s interfaces number for neopixel (s2 mini supports only one so it's not recommended for multi-segments but still supports it using different renderer).
Add option for the second segment to be reversed.
Advanced test units: using mockups of the Serial and LED objects, we verify correctness of the data processing. We sent valid and damaged frame and check if the frame was accepted or rejected.
For SPI leds we changed the default clock output from GPIO 0 to GPIO4, because some of newer board don't have a GPIO0 forwarded to the pinout
ESP32 MH-ET LIVE mini is capable of 4Mb serial port speed and ESP32-S2 lolin mini is capable of 5Mb. But to give equal chances all models were tested using the default speed of 2Mb.
RGBW LED strip / Device | ESP32MH-ET LIVE mini |
---|---|
300LEDsRefresh rate/continues output=100HzSECOND_SEGMENT_START_INDEX=150 | 93-97 |
600LEDsRefresh rate/continues output=100HzSECOND_SEGMENT_START_INDEX=300 | 78-79 |
900LEDsRefresh rate/continues output=100HzSECOND_SEGMENT_START_INDEX=450 | 55-56 |
RGBW LED strip / Device | ESP32MH-ET LIVE miniHyperSerialESP32 v6.1 | ESP32MH-ET LIVE miniHyperSerialESP32 v8 |
---|---|---|
300LEDsRefresh rate/continues output=100Hz | 81-83 | 80-83 |
600LEDsRefresh rate/continues output=60Hz | 39-40 | 41-42 |
900LEDsRefresh rate/continues output=40Hz | 21-26 | 26-28 |
RGBW LED strip / Device | ESP32 (CH340C)HyperSerialESP32 v6.1 | ESP32 (CH340C)HyperSerialESP32 v8 |
---|---|---|
300LEDsRefresh rate/continues output=100Hz | 72-78 | 81-83 |
600LEDsRefresh rate/continues output=60Hz | 33-38 | 39-42 |
900LEDsRefresh rate/continues output=40Hz | 21-25 | 26-28 |
RGBW LED strip / Device | ESP32-S2 lolin miniHyperSerialESP32 v8 |
---|---|
300LEDsRefresh rate/continues output=100Hz | 80-84 |
600LEDsRefresh rate/continues output=60Hz | 42 |
900LEDsRefresh rate/continues output=40Hz | 27-28 |
Read more: migration from Arduino IDE to PlatformIO
Published by awawa-dev over 2 years ago
Fix: Force compiling using esp32 board manager version 1.x due to serial port performance problem of newer 2.x
Add white color channel calibration for RGBW LED strips.
You need latest v18 or above to use this feature in HyperHDR's Adalight driver panel.
Thanks @inferno1231 https://github.com/awawa-dev/HyperHDR/discussions/267
Published by awawa-dev over 2 years ago
Please use v6.1 instead
Published by awawa-dev about 3 years ago
Initial release for ESP32 devices based on HyperSerialEsp8266 v5.0.0.0