Repository navigation
Issues in 3.10.6, 7 #4827
Description
Board / MCU
ESP32
LED Chipset
WS2812B / NeoPixel
FastLED Version
3.10.7
Arduino / PlatformIO version
Any, but let's say https://github.com/pioarduino/platform-espressif32/releases/d ownload/61.04.00-RC1/platform-espressif32.zip
Operating System
macOS
Description
There are a couple of issues in the new release(s).
One is that the overrides of CRGB* to void* are now loose enough that super common constructs that you need patch hunks like
- memset(leds, 0, sizeof(CRGB) * _ledcount);
+ memset((void*) leds, 0, sizeof(CRGB) * _ledcount);
- memcpy(pPacket->colors, leds, sizeof(CRGB) * NUM_LEDS);
+ memcpy((void*) pPacket->colors, (const void*) leds, sizeof(CRGB) * NUM_LEDS);
and even
- free(leds);
+ free((void*) leds);
This affects a LOT of code in the wild.
Second, this code is incompatible with Arduino4, now available as an RC. For testing, you can just drop
-platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.311/platform-espressif32.zip
+platform = https://github.com/pioarduino/platform-espressif32/releases/download/61.04.00-RC1/platform-espressif32.zip
into your tree and build.
Because PlatformIO is stupid and compiles a ton of code in FastLED that the linker is going to throw away (I don't WANT most of the new stuff. Sorry.)
For example, in IDF6 (available for several months) many of the crutches in IDF5 that were there for the IDF4 layer, particularly in I2S, are just plain gone, so there are lots of failures like:
.../platforms/esp/32/audio/devices/idf5_i2s_context.hpp: In function 'fl::esp_i2s::I2SContext fl::esp_i2s::i2s_audio_init(const fl::AudioConfigI2S&)':
.pio/libdeps/m5demo/FastLED/src/platforms/esp/32/audio/devices/idf5_i2s_context.hpp:121:21: error: 'i2s_port_t' does not name a type; did you mean 'i2s_role_t'?
121 | static_cast<i2s_port_t>(config.mI2sNum), I2S_ROLE_MASTER);
src/fl/stl/cstring.h:85:7: note: candidate 2: 'void* fl::memcpy(void*, const void*, size_t)'
85 | void* memcpy(void* dest, const void* src, size_t n) FL_NO_EXCEPT;
| ^~~~~~
'memcpy(CRGB*&, CRGB [2048], unsigned int)' is ambiguous
120 | memcpy(g()->leds, ledsbuff, sizeof(CRGB) * NUM_LEDS);
| ^~~~~~~~~~
IDF4 hasn't been supported in a long time. Arduino4 is built on IDF6, not IDF5.
I experimented with #if 0's and ignores trying to get it to quit (failing to) compile code that won't even make it to my executable, but figured it was worth a note to you to add a CI target with Arduino4 snapshots so you can get ahead of it before the release.
I came across this while working on Codetastic's Matrix LED project. I'm moving away from FastLED in my projects because of previously discussed incompatibilies with STL as STL isn't really optional for me, but need to figure out a solution for ESP32 HUB75 LED MATRIX PANEL DMA Display and the rest of the world that will move quickly to current/supported Arduino and IDF.
Steps to reproduce
-platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.311/platform-espressif32.zip
+platform = https://github.com/pioarduino/platform-espressif32/releases/download/61.04.00-RC1/platform-espressif32.zip
Build.
Minimal sketch
Serial / debug output
Checklist
- I have searched existing issues for duplicates
- I have tested with the latest FastLED release or git master
- I can reproduce this with a minimal sketch
Activity
zackees commentedon Oct 13, 2026
FastLED dropped platformio and is using fbuild for everything. Massive speed up.
one of your projects was used as the THE benchmark for recompile speed.
Anyway, these platformio errors will be fixed and a new version released. And I will be putting a release guard in soon that is super heavy.
But yeah, we have the features and we are smaller flash/ram than any other version of fastled.
Not sure what your gripe is. Compile times? The features don't get linked in if you don't use them.
Look the only thing we have against the other libs is that we are the best cross platform LED driver, period.
Now we have async massive parallel led driver. You get all that, AND avr uno gets TINIER.
Not only do we support the high end we also support the low end.
Name me one other led driver that compiles to a $0.15 CHV32?
My only guess is that you haven't made the switch to AI or something and want to do the old fashioned way.
Thats fine, but the future killer led app needs to do everything. FastLED doesn't have to be the killer app, but it MUST be the library. And that means proving out everything. Maximally fast led driver in every possible driver, sound processing, networking.
FastLED offers a hardware abstraction layer that works everywhere.
So if you want to move on to, that's your choice, we appreciate you twiddling with our product and telling us how we can improve. And we hope you will consider continuing that in the future.
robertlipe commentedon Oct 13, 2026
TBC: there are two "gripes". Sorry you found it unclear. Arguably it should have been two reports, but I didn't see a reason to bury you in busywork. (I see that GitHub somewhat mangled the formatting of my report. Sorry. I'll try to edit that.)
The void* overrides are now ambiguous, so you broke a lot of existing callers. Not just my code, but any code using memset, memcpy, std::reverse, memmove, free, or anything else in libc or STL operating on CRGB*, which is extremely common. I worked with three different code bases this week and they were all impacted. You might wish they called fl::memset() or something else, but this wasn't the primary API for years and the installed base is going to break. (I just fixed my own project a few hours ago on this by pinning 3.10.3 because the thrash wasn't worth it to me. Instead of pinning backward forever, I thought I'd share the issue because I'm sure the fix probably isn't that difficult or contentious.
Arduino4 hasn't yet been sorted. This is quite understandable as it's "only" currently an RC, but the upcoming hotness in ESP32-land, the S31, requires it. I get it; you're juggling a lot of platform cats that are on fire. I'm just trying to help you get in front of that release because you seem to have one coming up yourself. "The features don't get linked in if you don't use them." is only part of the story. I'm explaining that another new kitchen-sink feature breaks the build because it was only partially ported to IDF5. I'm not lobbying against FastLED having direct I2S support. (Compiling and then throwing that code away on every build isn't something I'm a fan of, but I have choices.) I'm pointing out one example of a few where new code simply doesn't compile on IDF6 (not totally surprising; it's a new combination) and, thus, Arduino4. This will matter soon to a large percentage of your users. i2s_port_t was deprecated back in IDF5 about three years ago. The crutch holding it up has finally been removed. It's not just S31 or even P4 affected; it'll be all ESP32s using current/supported toolchain by the end of the year or so. Again, I think if you throw the Arduino4/Pioarduino4 tree into your build matrix, the issues will be evident and need mostly mechanical fixes. There are a few issues like this - all in new code that most existing users won't even call.
I was trying to help another project that's strategic in our shared Blinkieverse that uses FastLED and hit both of these branches on the way down, so it seemed worth a note. If anything, the takeaways from this should be "Care about existing API callers using void*/CRGB*" and "Care about IDF6/Arduino4" which are broader than I could hit with a PR tweaking a template or sprinkling an #ifdef here and there.
I suspect you actually DO care about these things. I'm glad that you're able to push the ball forward for everyone. I do understand the challenges. Thank you for that.
zackees commentedon Oct 13, 2026
this seems actionable
test: Arduino 4 board regression for CRGB libc calls, nightly IDF6 bu…
fix: std algorithms and using-namespace-std calls on CRGB no longer a…
fix: fl::move/fl::forward alias std:: when <utility> exists (#4827)
fix: move CRGB/CHSV into fl::pixel so ADL never reaches fl generics (#…
fix: hide fl generics/libc wrappers from ADL behind fl::adl_barrier (#…
zackees commentedon Oct 13, 2026
@robertlipe request for review:
we need a glibc linter for fastled
#4832
fl::malloc -> fl_malloc
fl::qsort -> fl_qsort
I think this is simpler than the adl bypass hacks being put into place by the ai
fix: libc mirrors lose ties to libc; review follow-ups (#4827)
chore(bloat): re-base esp32s3 image to 341131 (#4827)
chore(bloat): re-base esp32s3 budget json to 341131 (#4827)
fix: CRGB and other fl types no longer make libc/std calls ambiguous (#…
robertlipe commentedon Oct 14, 2026
perf(stl): force-inline fl:: libc wrapper templates (-76 B on ESP32-S…
lint: exhaustive libc_mirror rule for fl:: libc-named functions (#4834)…