This does not compile for esp32-c3 and -s3

[zackees]

You are relying on soc headers which change from platform to platform. This code currently only works on the esp32dev in my tests, which were not exhaustive.

[hpwit]

Hello This code is only for esp32. You will find a specific code for the s3 in my directories. One day I will merge al the version together

[zackees]

Thanks for the suggestion, I'll take another look. Do you also have code for the c3? That seems to be really popular choice as well.

Btw, this is for FastLED.

[zackees]

Where is the code, I can't find it in your repo.

[hpwit]

hello here is for the s3 https://github.com/hpwit/I2SClockLessLedDriveresp32s3 I do not have the code for the c3 nor C6 I would need to study these mcc more closely. Lately I have been working on the live coding scripting language that allows to write animation scripts and execute them without having to reload. like in pixel blaze

[zackees]

Thanks. Yeah i found the s3 code and yesterday I got the i2s code to compile on esp32dev for idf4.4 in fastled. We have an old port.

FastLED seems to be quite difficult to get a driver working. I'm refactoring to make this much easier.

[zackees]

Refactoring is done.

You'll find that the new PixelIterator solves most of your issues with writing driver code for fastled.

The previous object you were interacting with, PixelController<> was challenging because it infects all the other code it touches with templates. PixelIterator is concrete, and wraps away the template stuff and hides it.

src/pixel_iterator.h

[hpwit]

Hello My driver does not need FastLED to work. It is compatible with it but it's not needed. I just use FastLED for the hsv and fast math functions that it contains.

[zackees]

Right, I saw a comment where you intended to implement this in FastLED officially.

[hpwit]

Indeed at some point in time but now I am not gonna do that anymore because I have implemented different functionalities in the driver that will make it to complicated to integrate back in FastLED nevertheless I thank you for what you've done and I will look at the code. Always interesting to learn new stuff. May I ask (maybe again) what you are trying to achieve ?

[zackees]

Specifically, I'm trying to get a massive number of pixels rendered in parallel on FastLED.

More generally, I've used FastLED for a long time and now I'm a core contributor. My entrypoint was developing the APA102 HD algorithm that unlocks the full potential of the APA102 (and derivatives) chipset.

To be honest, I just like this library and fixing it up falls in line with two decades of experience writing C++ code and porting low level libraries. It's also allowed me to solve the problem of how to make lots of changes to a library and not have a bunch of issues all over the place. So I've made a fleet of testers which tests every platform on ever CL. This allows me to increase the velocity of changes I or anyone else will do.

Eventually I'll move on, but right now this library is what I think about when I go to bed, wake up, and when trying to socialize. I want to see FastLED power the lights of inspiring tech artists at festivals like burning man and elsewhere and know that I had positive impact in helping them manifest.

[ewoudwijma]

Hi Zach, that sounds good, thanks for providing a bit of background on the current developments in FastLED. It's amazing how many updates there are now and maybe it would be good to tell a bit more on current and future plans. Maybe one of the led YouTubers could even interview you 🙂. Specific questions I have now:

• what is the main platform where FastLED dev things are discussed? I see not much happening on Discord. Is Reddit your main communication channel?
• how support for massive numbers of LEDs will be implemented
• I see new versions are released very frequently. Are they all production ready? In other words how much testing is needed before upgrading to a new version? (With so many updates I cannot easily keep up testing them all extensively, so I start running behind latest)
• are all updates backwards compatible so bugs aside it should be safe to update to latest release?
• who are the testers? Can we see test proceedings?
• are you temporarily spending so much time on FastLED or will you stay as core contributor for the foreseeable future? {ah this you answered above 🙂}
• ...

Maybe some answers are giving on other places already, just braindumping some of the questions I had .

Thx, Ewoud

[zackees]

maybe it would be good to tell a bit more on current and future plans. Maybe one of the led YouTubers could even interview you 🙂

Youtube LED interview sounds great. I've got a broadcast setup in my office.

Current plans are getting the RGBW support in. This is done now and will be released on Monday.

The big thing I'm trying to solve in the near term is getting I2S support in and fixing RMT for IDF 5.1. I2S is targeted for the WS2812 and RMT driver is targeted for all the other led chipsets since RMT supports different controllers on it's bus, while I2S supports just one controller type on it's bus, so might as well target WS2812 of the IS2 since that is the common path.

what is the main platform where FastLED dev things are discussed?

Github, reddit. We also use slack for some of the internal communications.

how support for massive numbers of LEDs will be implemented

The Clockless driver for ESP32 will be adapted to use I2S / RMT. We actually have an I2S driver for FastLED esp32 dev but it only works for idf 4.4, which is deprecated. Our RMT driver is also using the legacy library for idf 4.4 on 5.1.

I see new versions are released very frequently. Are they all production ready?

Define "production ready". It's better then what the state was and when something goes wrong there's a community of people stepping forward to tell us what we got wrong and often with fixes. However, most of the bug reports have drawn down to a trickle so I think we are doing something right.

how much testing is needed before upgrading to a new version?

We have platform compile tests for everything we release. We don't do run tests and my advice is pin a version you know that works and update infrequently unless there is some feature that you need.

are all updates backwards compatible so bugs aside it should be safe to update to latest release?

Yes, we have tests for this from Uno to esp idf 4.4 & 5.1. We also have binary size tests to prevent firmware binaries from blowing up unexpectedly.

it should be safe to update to latest release?

It should be relatively safe to update to latest. I have a policy of never removing a header file because I don't know who's depending on it. Any code that is moved to a different header will have the original header include it.

who are the testers? Can we see test proceedings?

Automated tests.

are you temporarily spending so much time on FastLED or will you stay as core contributor for the foreseeable future? {ah this you answered above 🙂}

Temporarily sprinting to fix all the things of the last 8 years and bring it up to parity with the other LED projects. After that I'll step back and mainly pull in PRs and implement the occasional feature.

[ewoudwijma]

Thanks for your explanation. Found this also: https://www.reddit.com/r/FastLED/s/E82KfMUBJb

So this helps a lot already explaining the backgrounds

Thx a lot for your great work !

[hpwit]

I wrote the i2s version currently in use in FastLED. Long long time ago ;).

As for having a very large number of leds using an esp32 you should look at the virtual led driver. You can simulate up to 120 // strips at full speed. https://youtu.be/jPPd2A3RyW0?si=BYcdCV052KDphUu9

[zackees]

Yeah it's your code, but the I2S clock less driver i refactored in FastLED has sam's coding style all over it too so looks like it was collab.

Yes I saw the virtual pin code. I'm moving FasTLED in that direction. However I can't get the I2S to compile in IDF 5.1 that's present for the new Arduino update. Hence why I'm here. 😁

[hpwit]

If you look at the code of the i2sclocklessleddriver there is a line for including header depending on the version of esp idf this should be enough to compile under esp idf 5.x. If you need some help for the i2s virtual pins let me know.

[zackees]

If you look at the code of the i2sclocklessleddriver there is a line for including header depending on the version of esp idf this should be enough to compile under esp idf 5.x.

This does not work for IDF5.1. This was already tested for a while. These are repro steps to compile the old port of your code in our codebase.

Repro case:

• make sure platformio package is installed pip install platformio==6.1.15
• run this bash script after you clone the FastLED repo and cd to the project root

mkdir -p .build/esp32dev
pio project init --project-dir .build/esp32dev --board esp32dev --project-option=platform=https://github.com/pioarduino/platform-espressif32.git#develop "--project-option=build_flags=-D FASTLED_ESP32_I2S"
pio ci --board esp32dev --lib=ci --lib=src --keep-build-dir --build-dir=.build/esp32dev examples/Pacifica/*ino

Attached is the build log showing the compilation errors.

espdev_idf5_i2s.txt

[zackees]

If you need some help for the i2s virtual pins let me know.

Yes I'd like help, but I think that getting I2S to compile is first.

[zackees]

Okay I made this even easier.

Just git clone https://github.com/fastled/fastled && cd fastled

And then run

./compile esp32dev_i2s --examples EspI2SDemo

This will work, because our esp32dev_i2s board type is pinned to the arduino previous core.

./compile esp32dev --defines FASTLED_ESP32_I2S --examples EspI2SDemo

But this will not, because it's using idf 5.1

Ditto for

./compile esp32-s3-devkitc-1 --defines FASTLED_ESP32_I2S --examples EspI2SDemo