Hyperk 0.0.5-alpha.1 with HyperSerial support

[satgit62]

Once again, kudos on the implementation of HyperSerial in Hyperk. This combination takes the LED controller to a whole new level and leaves almost nothing to be desired, so it can now be used by a wide range of users. Great work! @awawa-dev ♥️👍

I’ve already tested it and found that, even on the ESP32 series, it has absolutely no drawbacks compared to the RP2040 HyperSerialPico. It runs very smoothly, and the color reproduction is—when set correctly—fantastic.

However, I did discover a possible bug with the ESP32-S2 Mini: Although I used the same LED settings as on the ESP32, not all 263 LEDs light up—only about 217 do.

When I select the ESP32, all 263 LEDs light up.
Both Hyperk LED controllers are controlled via adalight.
I’m not sure if this is related to the fact that the 'Min segments number to force I2S' Menu hasn’t been implemented on the S2 Mini.
In the Wi-Fi v0.0.4 firmware, all LEDs lit up on the S2 Mini as well.

ESP32-S2 Mini

ESP32

[awawa-dev]

Hi, thanks for the kind words and testing!

Non-ESP32 boards don't support I2S LED rendering. ESP32-S2 theoretically does, but low RAM makes it practically impossible to use in Hyperk (unlike in the much smaller HyperSerialESP32). Your ESP32 has min segments number to force I2S set to 1, so it's using a different driver than the esp32-S2. Try setting it to 2 to force the ESP32 to use SPI emulation (same as esp32-S2 does in your setup). Let me know if that breaks something, so we can see if it's a board-specific issue.

[satgit62]

Hi, thanks for the kind words and testing!

Non-ESP32 boards don't support I2S LED rendering. ESP32-S2 theoretically does, but low RAM makes it practically impossible to use in Hyperk (unlike in the much smaller HyperSerialESP32). Your ESP32 has min segments number to force I2S set to 1, so it's using a different driver than the esp32-S2. Try setting it to 2 to force the ESP32 to use SPI emulation (same as esp32-S2 does in your setup). Let me know if that breaks something, so we can see if it's a board-specific issue.

Yes, thanks for the reply—I figured that out in the meantime.
Enabling “Disable Neopixel over SPI” finally got all the LEDs to light up.

This forced the ESP32-S2 Mini to switch to the real I2S-DMA hardware driver. This driver offloads data processing directly to memory, which bypasses the Adalight protocol’s 512-byte limit and now allows all 263 LEDs to be controlled without any issues.

[awawa-dev]

OK, this should force esp32-s2 to use RMT. But wonder why Neopixel over SPI is limiting LEDs number on esp32-s2 and if is it specific for that board only. And if that happens also over network/UDP.

[satgit62]

I also set up the ESP32-S2 Mini as a dedicated Hyperk (v 0.0.5-alpha.1) LED controller via Wi-Fi, and I encountered the same limitation there as well.
With version 0.0.4, there was no limitation.

[satgit62]

So far, I haven't noticed any negative side effects resulting from enabling the “Disable Neopixel over SPI” option on the ESP32-S2 Mini. Everything's perfect.

[satgit62]

Hi @awawa-dev, with Hyperk 0.0.5-alpha.2, all the LEDs on the ESP32-S2 Mini light up brightly without having to enable “Disable Neopixel over SPI.”
Now it also says “LED 0 -> RMT” in the statistics.

Thanks for the quick fix.

[awawa-dev]

I'm pretty sure I fixed it because I managed to debug it using a logic analyzer but on stats page it should only print not RMT but From LED 0 → SPI_NEOPIXEL. I've checked on my ESP32-S2 with 0.0.5-alpha.2, and it switches between RMT and SPI_NEOPIXEL depending on that switch. Maybe browser cache is causing this?

[satgit62]

Yes, you're right—I've cleared the cache now, and the output has changed.