[cckilator]

This adds a new [esp32_s3] PlatformIO environment (s3_WS281x_RGB) targeting generic ESP32-S3 boards with native USB CDC (e.g. ESP32-S3-WROOM-1 dev boards).

Three fixes were needed to get the native USB CDC serial port working reliably on this target:

1. Bounded serial wait: while (!Serial) continue; could hang forever on S3, since native USB CDC can stay unopened if the host never performs the expected handshake. Bounded to a 3s timeout instead.
2. Disabled early Serial.println(): this diagnostic output could block indefinitely on native USB CDC before a host terminal actively opens/drains the port. Disabled on S3 the same way it's already disabled on S2.
3. processSerialTask moved to core 0: pinning it to core 1 (as done for classic ESP32) conflicts with the native USB CDC driver's internal FreeRTOS task, causing a hang after a few seconds of runtime. Moving it to core 0 (alongside processDataTask) fixes this, but starves the IDLE0 task since both tasks now share core 0 - which then triggers a Task Watchdog Timer abort/reboot loop after ~10s. Fixed by calling disableCore0WDT() at the start of setup() on S3.
   Also uses the RMT NeoPixelBus driver (NeoEsp32Rmt1Ws2812xMethod / NeoEsp32Rmt1Sk6812Method) since this fork of NeoPixelBus has no I2S driver implementation for ESP32-S3.

Tested on a generic "ESP32-S3-WROOM-1" dev board (labeled "3S"), wired to a 722-LED WS2812B strip via its native USB port, running through HyperHDR over adalight/AWA protocol at 2000000 baud. No crashes or reboots observed after extended runtime (multiple hours, including a full host reboot).

Happy to adjust anything (naming, guard placement, etc.) to match project conventions.

[awawa-dev]

Hi

Thanks for the PR and for taking the time to implement and test this. I appreciate the effort, and native USB CDC support on the ESP32-S3 is certainly useful.

However, I'm not convinced that ESP32-S3 support belongs in HyperSerialESP32 at this point.

One of the main goals of HyperSerialESP32 is reliable and synchronized multi-segment LED output. Unlike the classic ESP32 and ESP32-S2, the ESP32-S3 doesn't have the same I2S-based output path available in our current implementation, so this approach relies on RMT instead. Your tests look promising for a single LED strip, but I don't think we can assume equivalent synchronization guarantees for multiple segments.

The multi-segment code path also appears to still select I2S-based drivers for RGB configurations, so this PR doesn't seem to cover that use case yet. Additionally, disabling the Core 0 task watchdog to work around task starvation is not a workaround I'm comfortable introducing into the main branch.

After starting the project with ESP32, I made an exception for the ESP32-S2 because it still allows us to use an I2S-based output approach, albeit with a somewhat different implementation. With the ESP32-S3, I see a more fundamental limitation for the kind of synchronized rendering this project is intended to provide.

I've been experimenting with ESP32-S3 support in Hyperk, including native USB CDC and segment rendering using Espressif's RMT Sync Manager. While it synchronizes the start of multiple RMT transmissions, I haven't yet verified that it provides the same timing precision and consistency as the I2S-based approach in all scenarios (see the table).: https://wiki.hyperhdr.eu/Hyperk#12-neopixel-emulation--multi-segment-support .

For these reasons, I'd prefer not to merge this PR into HyperSerialESP32 for now. I really appreciate the work you've put into it, though, and I hope you understand that this is more about the project's design goals than the quality of your contribution.

Thanks again!