Skip to content

v9.0.0.0

Latest
Compare
Choose a tag to compare
@github-actions github-actions released this 06 Feb 19:32
· 13 commits to master since this release
db2cc26
  • 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.

obraz

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.