v9.0.0.0

• Add true parallel output for HyperSerialESP32 based on development version of Neopixelbus library that already includes some of my changes (Makuna/NeoPixelBus#609 Makuna/NeoPixelBus#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.

v8.0.0.0

Please read the changelog carefully as it contains some breaking changes, that may affect you existing setup.

1. Needs latest HyperHDR v19 beta 2 development version

2. Use separate thread for the serial port handling and data processing to improve performance stability

3. Add initial support for esp32-s2 mini boards. This board supports up to 5Mb speed.
   

4. Removed unnecessary double buffering of LED data for better performance

5. 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).

6. Add option for the second segment to be reversed.

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

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

Benchmark result

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.

Multi-segments can double your large sk6812/ws2812b setup refresh rate for free. All you need is to properly project & construct the LED strip and use HyperSerialESP32 v8.

RGBW LED strip / Device	ESP32 MH-ET LIVE mini
300LEDs Refresh rate/continues output=100Hz SECOND_SEGMENT_START_INDEX=150	93-97
600LEDs Refresh rate/continues output=100Hz SECOND_SEGMENT_START_INDEX=300	78-79
900LEDs Refresh rate/continues output=100Hz SECOND_SEGMENT_START_INDEX=450	55-56

Comparing v6.1 and v8 version (single segment) refresh rate using MH-ET LIVE mini

RGBW LED strip / Device	ESP32 MH-ET LIVE mini HyperSerialESP32 v6.1	ESP32 MH-ET LIVE mini HyperSerialESP32 v8
300LEDs Refresh rate/continues output=100Hz	81-83	80-83
600LEDs Refresh rate/continues output=60Hz	39-40	41-42
900LEDs Refresh rate/continues output=40Hz	21-26	26-28

Comparing v6.1 and v8 version (single segment) refresh rate using generic ESP32 with CH340C

RGBW LED strip / Device	ESP32 (CH340C) HyperSerialESP32 v6.1	ESP32 (CH340C) HyperSerialESP32 v8
300LEDs Refresh rate/continues output=100Hz	72-78	81-83
600LEDs Refresh rate/continues output=60Hz	33-38	39-42
900LEDs Refresh rate/continues output=40Hz	21-25	26-28

ESP32-S2 lolin mini performance

RGBW LED strip / Device	ESP32-S2 lolin mini HyperSerialESP32 v8
300LEDs Refresh rate/continues output=100Hz	80-84
600LEDs Refresh rate/continues output=60Hz	42
900LEDs Refresh rate/continues output=40Hz	27-28

v7.0.0.0

• migration to PlatformIO

Read more: migration from Arduino IDE to PlatformIO

v6.1.0.0

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

v6.0.0.0

Please use v6.1 instead

v5.0.0.0

Initial release for ESP32 devices based on HyperSerialEsp8266 v5.0.0.0