ESP32-C6 Support & FastLED Update to 3.9.14 #4626
Conversation
WalkthroughThe changes add support for the ESP32-C6 platform across the project. The PlatformIO configuration now includes a dedicated environment for the ESP32-C6 development board with specific build flags and upload speed, and the FastLED library dependency is upgraded. In the codebase, new macros, typedefs, and extended conditional compilation directives have been introduced in multiple modules to handle ESP32-C6–related functionality such as LED control, touch input, pin validation, WiFi and network configuration, and system information reporting. Changes
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
wled00/pin_manager.cpp (1)
21-21: Minor formatting adjustmentThe line has an extra space added at the end of the comment.
While functionally harmless, for consistency you might want to fix this minor spacing issue:
-static uint16_t ledcAlloc = 0; // up to 16 LEDC channels (WLED_MAX_ANALOG_CHANNELS) +static uint16_t ledcAlloc = 0; // up to 16 LEDC channels (WLED_MAX_ANALOG_CHANNELS)wled00/wled.cpp (1)
627-631: Improved static IP configuration checkModified the WiFi configuration logic to use clearer comparison against empty
IPAddress()objects instead of comparing against0U. This enhances code readability and robustness.Consider adding a comment explaining the logic of this condition, particularly why both staticIP and staticGW need to be set for a static configuration to be used.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
platformio.ini(3 hunks)wled00/NodeStruct.h(1 hunks)wled00/bus_manager.cpp(3 hunks)wled00/bus_wrapper.h(21 hunks)wled00/button.cpp(1 hunks)wled00/improv.cpp(1 hunks)wled00/pin_manager.cpp(2 hunks)wled00/presets.cpp(1 hunks)wled00/src/dependencies/async-mqtt-client/AsyncMqttClient.hpp(1 hunks)wled00/src/dependencies/dmx/SparkFunDMX.cpp(1 hunks)wled00/src/dependencies/e131/ESPAsyncE131.cpp(1 hunks)wled00/src/dependencies/network/Network.cpp(1 hunks)wled00/src/dependencies/network/Network.h(1 hunks)wled00/udp.cpp(1 hunks)wled00/wled.cpp(3 hunks)wled00/wled.h(2 hunks)
🔇 Additional comments (29)
wled00/NodeStruct.h (1)
17-17: LGTM: NodeType ID added for ESP32-C6 support.This addition properly extends the node type identification system to include the ESP32-C6 platform, maintaining consistency with existing definitions.
wled00/src/dependencies/e131/ESPAsyncE131.cpp (1)
24-26: Network name redefined for ESP32-C6 platform.This preprocessor directive correctly redefines the Network class as Network_C6 specifically for the ESP32-C6 target, addressing potential naming conflicts mentioned in the PR description.
wled00/improv.cpp (1)
13-13: Added ESP32-C6 to the list of platforms with disabled WiFi scanning.The change appropriately extends the list of platforms for which WiFi scanning during Improv is disabled, now including ESP32-C6. This is consistent with how other ESP32 variants are handled.
wled00/src/dependencies/dmx/SparkFunDMX.cpp (1)
20-20: Properly disabled SparkFunDMX for ESP32-C6 platform.This modification correctly excludes the SparkFunDMX implementation for ESP32-C6, aligning with the PR description which mentions that SparkFunDMX has been disabled due to compatibility issues with the new platform.
wled00/udp.cpp (1)
757-758: ESP32-C6 node type identification added correctly.This addition properly extends the node type identification system to support the ESP32-C6 platform, allowing the system to report the correct hardware target when sending system information packets to other nodes in the network.
wled00/src/dependencies/async-mqtt-client/AsyncMqttClient.hpp (1)
41-41: Extended semaphore macros to include ESP32-C6 support.The conditional compilation directive has been properly expanded to include ESP32-C6 targets, ensuring that the MQTT client uses the correct semaphore implementation on this new platform.
wled00/src/dependencies/network/Network.cpp (1)
91-95:✅ Verification successful
Conditional NetworkClass instance for ESP32-C6.
The code correctly introduces a platform-specific NetworkClass instance for ESP32-C6 (
Network_C6), while maintaining the original instance name for other platforms. This approach allows for platform-specific network handling while maintaining API compatibility.To verify this change works correctly with other parts of the codebase:
🏁 Script executed:
#!/bin/bash # Check for references to Network_C6 in other files echo "Checking for Network_C6 references:" rg -A 1 -B 1 "Network_C6" echo "Checking for conditional Network references:" rg -A 3 -B 3 "CONFIG_IDF_TARGET_ESP32C6.*Network"Length of output: 997
Verified conditional NetworkClass instantiation for ESP32-C6
The change correctly introduces a dedicated instance (
Network_C6) for the ESP32-C6 target while preserving the original instance name (Network) for other platforms. The cross-file references—such as the aliasing inwled00/wled.hand usage inwled00/src/dependencies/e131/ESPAsyncE131.cpp—confirm that the aliasing mechanism is functioning as intended.wled00/src/dependencies/network/Network.h (1)
22-26: Proper conditional handling for ESP32-C6 network implementationThe code correctly implements a conditional compilation directive to support the ESP32-C6 platform by introducing a separate Network_C6 instance for this specific target.
This change is aligned with the PR objective of adding ESP32-C6 support, and follows the same pattern used for other platform-specific implementations in the codebase.
wled00/presets.cpp (1)
171-171: ESP32-C6 added to platform-specific timing controlThe change correctly adds ESP32-C6 to the list of platforms that need specific timing adjustments for LED strip updates.
This ensures consistent LED rendering behavior across all supported ESP32 variants including the new C6 platform, maintaining compatibility with the existing implementation patterns.
wled00/pin_manager.cpp (1)
210-213: ESP32-C6 pin restrictions properly definedThe code correctly adds ESP32-C6 specific pin validation to prevent use of reserved pins:
- GPIO 12-13 (USB-JTAG pins)
- GPIO 24-30 (SPI FLASH pins)
This follows the same pattern as other ESP32 variants and will prevent hardware conflicts when using these pins for LED control or other I/O functions.
platformio.ini (3)
13-13: ESP32-C6 added to default environmentsThe default environments list has been updated to include the ESP32-C6 development board.
This allows the CI/release system to automatically build for this new platform.
332-358: ESP32-C6 build environment properly configuredThe new environment for ESP32-C6 is well-configured with appropriate build flags and settings:
- Correct platform URL and framework specification
- Architecture-specific flags for ESP32-C6
- Appropriate partition scheme for 8MB flash
- Disabled features that aren't compatible (infrared)
- Watchdog timeout settings
The configuration looks comprehensive and follows the same pattern as other ESP32 variants. The build flags correctly define the target architecture and necessary compiler options.
140-140:❓ Verification inconclusive
FastLED library updated to 3.9.14
As mentioned in the PR description, the FastLED library has been updated from 3.6.0 to 3.9.14.
This is a significant version jump that might introduce changes in behavior. Let's verify the changelog for key improvements or breaking changes:
🌐 Web query:
What are the main changes between FastLED 3.6.0 and 3.9.14?💡 Result:
The FastLED library has undergone significant evolution from version 3.6.0 to 3.9.14, with major improvements in hardware support, performance, and functionality. Here are the key changes:
Core Architecture Improvements
- Asynchronous rendering introduced in 3.9.x enables non-blocking LED updates, achieving up to 70% faster frame rates compared to 3.7.X[3][7]
- ObjectFLED driver integration (from 3.9.8) enables massive parallel output:
- Teensy 4.x: Supports 50-pin parallel WS2812 control[4]
- ESP32-S3: 16-way parallel output with different strip lengths per channel[1][3]
- RGBW support added through RGB emulation mode (3.9.11)[1]
New Hardware Support
Version Supported Hardware 3.6.0 ESP32/ESP8266, Teensy4, RP2040, ATtiny48/88[3] 3.9.x Arduino GIGA, ESP32-S3, ATtiny4313, nordicnrf52_dk[1][3][7] Driver Enhancements
- HD107 "Turbo" 40MHz mode (3.9.13)[1]
- APA102/SK9822 gamma correction (3.7.0)[3][7]
- Improved ESP32 RMT driver with long-standing interrupt bug fix (3.9.13)[1]
- Teensy Audio DMA compatibility for parallel drivers[1]
API and Functionality
- New color manipulation functions:
fill_rainbow_circularandfill_palette_circular(3.6.0)[3]- Enhanced fade functions (
fade_raw,fade_video,fadeUsingColor)[2]- LINEARBLEND_NOWRAP palette mode[3]
- Global brightness control for APA102/SK9822 via
FASTLED_USE_GLOBAL_BRIGHTNESS[5]Performance Optimizations
- Fixed integer math in
scale8(), blending, and noise functions[5]- Reduced compiler warnings and faster build times[3]
- ESP32-S3 I2S driver improvements (3.9.11)[1]
- Teensy parallel driver stability fixes for variable-length strips[1]
Platform Support
- Official PlatformIO starter template[7]
- Arduino 2.3.4 compatibility fixes[1]
- Async rendering for ESP32/Teensy/Raspberry Pi[7]
These changes reflect FastLED's evolution into a more robust, flexible library supporting modern microcontroller architectures while maintaining backward compatibility. The 3.9.x series particularly focuses on parallel output capabilities and non-blocking rendering, making it suitable for large-scale LED installations requiring high refresh rates.
Citations:
- 1: https://github.com/fastled/fastled/releases
- 2: https://fastled.io/docs/group___color_fades.html
- 3: https://github.com/FastLED/FastLED/blob/master/release_notes.md
- 4: https://forum.pjrc.com/index.php?threads%2Ffastled-now-has-50-pin-parallel-teensy-4-1-ws2812-support.76316%2F
- 5: http://fastled.io/docs/fastled__config_8h.html
- 6: https://github.com/FastLED/FastLED
- 7: https://fastled.io/docs/
- 8: https://fastled.io/docs/wasm_8ino_source.html
- 9: https://forum.arduino.cc/t/re-does-anyone-know-the-fastled-internals/1346553
- 10: https://fastled.io/docs/group___color_blends.html
- 11: https://www.arduinolibraries.info/libraries/fast-led
- 12: https://www.codetriage.com/fastled/fastled?issues_before=1924240358
- 13: http://fastled.io/docs/_fast_l_e_d_8h.html
- 14: https://sourceforge.net/projects/fastled.mirror/
FastLED Library Update Verification
The FastLED library update from 3.6.0 to 3.9.14 has been verified against the official release notes. Notable changes in 3.9.14 include:
- Asynchronous Rendering: Provides up to 70% faster frame rates with non-blocking LED updates.
- Enhanced Parallel Output & Hardware Support: New integration for ObjectFLED drivers, support for platforms like ESP32‑S3 and Arduino GIGA.
- Driver & API Enhancements: Improved drivers (e.g., HD107 “Turbo” mode), updated color manipulation functions, and global brightness handling.
- Performance Optimizations: Fixed issues in integer math, blending, and reduced compiler warnings.
While these changes bring enhanced performance and new features, they also warrant careful testing in your application to ensure no unexpected behavior if your code depended on legacy aspects.
File:
platformio.ini
Line: 140
Snippet:fastled/FastLED @ 3.9.14Please confirm that all functionalities work as expected with the new version.
wled00/wled.h (2)
110-112: Added ESP32-C6 network supportThis change defines
NetworkasNetwork_C6when the target configuration isCONFIG_IDF_TARGET_ESP32C6, which ensures the ESP32-C6 networking implementation is properly used.
324-324: Added ESP32-C6 to hardware pin mapping conditionThe conditional compilation check for defining
hardwareRXandhardwareTXhas been expanded to includeCONFIG_IDF_TARGET_ESP32C6, ensuring proper pin mapping for this new ESP32 variant.wled00/bus_manager.cpp (3)
10-10: Added ESP32-C6 to LEDC mutex lock conditionThe conditional compilation directive has been updated to include ESP32-C6 in the check, ensuring the LEDC mutex lock/unlock macros are handled appropriately for this platform.
481-481: Excluded ESP32-C6 from LEDC setupThe
#elifdirective now checks for the absence ofCONFIG_IDF_TARGET_ESP32C6, skipping LEDC setup and attachment for this target, similar to how it's handled for ESP8266.
649-649: Excluded ESP32-C6 from LEDC detachmentUpdated the condition to exclude ESP32-C6 from the LEDC pin detachment process in the
deallocatePinsmethod, consistent with the initialization approach.wled00/wled.cpp (2)
329-329: Added ESP32-C6 to USB serial initialization delayExtended the conditional compilation directive to include ESP32-C6, ensuring a proper delay of 2500ms for CDC USB serial initialization on this platform when debugging is enabled.
373-373: Added ESP32-C6 to PSRAM safety check exclusionUpdated the PSRAM handling condition to exclude ESP32-C6 from the ESP32 revision check for PSRAM safety, treating it similarly to ESP32S2, ESP32S3, and ESP32C3.
wled00/bus_wrapper.h (9)
234-244: Introduce fallback bit-bang approach for ESP32-C6
These typedef statements correctly handle the scenario where the ESP32-C6 lacks I2S or RMT, ensuring compatibility with NeoPixelBus. Everything appears consistent with other ESP32 variants.
258-268: Define bit-bang-based bus macros for ESP32-C6
These new macros (e.g.,B_32_C6_NEO_3,B_32_C6_TM1_4, etc.) follow the established naming and implementation pattern seen for other architectures, ensuring seamless integration.
486-495: Add Begin() calls for ESP32-C6 bus types
Using thebeginTM1814()helper for TM1814 strips and directBegin()for other formats matches the standard approach across the codebase.
595-603: Implement create() support for ESP32-C6
These constructors instantiate the correct bit-bang classes for each bus type on the ESP32-C6, preserving parity with existing architectures.
703-711: Add Show() handling for ESP32-C6 buses
This ensures each newly introduced bus type can properly invoke theShow()method, consistent with the code’s design.
942-949: Provide SetPixelColor() logic for ESP32-C6
Each case appropriately callsSetPixelColoron the newly added bit-bang classes. No issues found.
1047-1056: Implement SetBrightness() for ESP32-C6
Use ofSetLuminance()here is aligned with the pattern used for other ESP32 variants.
1156-1164: Extend GetPixelColor() for ESP32-C6
These additions properly retrieve the pixel color for each newly introduced bus type, including handling TM1814’s 16-bit data.
1388-1396: Add getDataSize() handling for ESP32-C6
Returning the pixel buffer size for each newly defined bus class mirrors the logic applied to other architectures and bus types.
|
thanks for contributing! |
Sadly I didn't find this C6 support branch. If you think that it would be a good idea to combine forces point me to it :) . Yes at least from my understanding NeoPixelBus supports only BitBang for C6 as the I2S changed a lot so unless I try to do add support into NPB for C6 I2S. BitBang is the best I can do. (RMT is not an option in NPB for C6 as well) It's my first coding ESP32 project so could you please tell me why bitbanging is unaccepatble? |
|
So I've discovered that there is some RMT support for C6 inside NPB on the Core3 branch. But when I've tried it doesn't work. When I go to the web interface it's telling me "TypeError: Cannot read properties of null (reading 'classList')" don't know if it's because of something broken inside NPB or I'm doing something wrong when trying to use RMT. |
|
Bitbanging is unacceptable IMO as C6 is not powerful enough to do quality bitbanging while performing other tasks. Also, why change of FastLED? WLED only requires CRGB/HSV support and a few math functions, all of which are being replaced soon by @DedeHai (see open PR). Unless I2S and RMT (or other DMA method) is supported by NPB I see no added value in support for C6 compared to C3 (except for the fact that C6 chip is recognised and able to run WLED). |
|
there is some info about work being done for C6 here: #3078 the only reason to have C6 support would be zigbee, otherwise it is almost identical to the C3 (from a WLED perspective). |
Initial support for the ESP32-C6 platform and updates FastLED to the latest version.
Key changes include:
Added esp32-c6-devkitc-1 definitions to platformio.ini
Fixed network conflicts
Disabled SparkFunDMX (incompatible)
Switched to bitBang mode for C6
Defined GPIO pin mappings
Tested on Espressif ESP32-C6-WR00M-1 v1.0 8MB hardware. Let me know if any adjustments are needed!
Summary by CodeRabbit
New Features
Chores