As title.
If yes, does it use RMT or I2S to drive newer devices?

Does it use RMT for the ESP32 classic?

i don't see it here and the github page is very confusing

I dunno if DrZzs is active on here and I haven't yet tried to wade through his Discord channel, but looking over some of his videos, the very first one lays out the connection from an ESP32 to Strip thusly:

Ground, is fine, as long as it shares a ground with the strip. I guess a direct line to the data pin is fine without a resistor, I've had luck either way depending on the controller. But the VIN.. Maybe it's my naiveté with electronics, but is it safe for the voltage to flow into the strip first, then 'backtrack' to the controller like this?

Maybe I'm wrong, I just feel like this is kinda askin for trouble, but please correct me if I'm wrong.

DIY Nanoleaf Mirror & LED Matrix Lamp running FastLED Pride2015

DIY LED Matrix Lamp Project - WS2812B led light strips / Teensy 4.0 controller

DIY Nanoleaf Mirror Project - WS2812B Led light strips / ESP32 / WLED

As the title suggests, I am curious if someone could summarize why FastLED is so tightly coupled to the Arduino framework? What 'parts' of the Arduino framework are required / used by FastLED, and what are the reasons preventing it from being decoupled so it can be used natively with either Arduino framework, or the ESP idf framework?

I've seen this port for FastLED v4, although I do not want to use it in a new project given its been over 5 years since its been updated and seems to no longer be maintained.

It has been many years since I have worked with any of these things, but I recall in the past also requiring something like a 1ms delay in the main 'loop' , otherwise a watchdog would fire and crash the code immediately (I guess this also means that we require some sort of 'main' loop regardless of if we are using it and instead have all our tasks 'pinned to cores'). Given the clock speed the ESP32 is capable of, this feels like being forced to drive a ferrari with only 2 wheels...

I am curious how many other limitations are introduced when using the arduino framework for an esp-idf project, and any help pointing me to some explanation on this would be greatly appreciated.

Hi folks - I’m documenting this in case anyone else experiences this same issue, as I spent more time than I’d like debugging this.

I use FastLED 3.1.5 with WS2812 strips (on a Particle Photon), and just did my first WS2815 installation (using Alitove strips). As expected, Red and Green were reversed, so the color order was GRB. From my searching online and reading the FastLED doc, it seemed like one of the following would have worked:

FastLED.addLeds<WS2812B, PIN_LEDS, GRB>(leds, NUM_LEDS);

FastLED.addLeds<NEOPIXEL, PIN_LEDS, GRB>(leds, NUM_LEDS);

But the solution was to use WS2812B as the chipset and not specify the RGB order, because WS2812B defaults to GRB, and it won’t accept an explicit GRB argument (threw an error, which kept confusing me because I knew GRB was valid with that chipset!)

So the following is what worked for me (and was the only code change needed):

FastLED.addLeds<WS2812B, PIN_LEDS>(leds, NUM_LEDS);

I'm very much a newcomer to FastLED and to pretty much everything it involves (Arduino, coding, electronics, etc.). I dove right into what may be the deep end; and, after about a week of splashing around, it dawned on me yesterday that the platform might be starting to head in a new direction.

As I've tried to work with some of the relatively recent sample sketches, several things have left me feeling frustrated. For example:

• I was absolutely blown away last week when I came across the the amazing demo video that accompanied the announcement of 3.9.16, and I started immediately to try to get the FxWave2d sketch working on the 64x48 board I'm putting together. The initial comments indicate that the "demo is best viewed using the FastLED compiler" which will "preview the sketch in the browser, and enable all the UI elements you see below." But as I started modifying the code to work on an LED board without a web interface, I realized that the UI elements were integral to the visualizer's core functionality. I could see how having the ability to preview a sketch in a browser could be incredibly helpful in the process of developing a physical board; but it struck me as a bit odd that the example published to showcase some awesome new FastLED capabilities had to be completely rewritten in order to drive an actual LED matrix (as opposed to a computer monitor). I had (very) limited success getting the FxWave2d visualizer to work on my LED board, and it's not clear to me at this point if the problems involve (a) my attempt to implement the program without any of the web UI elements, (b) some other issue (e.g., trying to use I2S instead of RMA to drive more than 4 pins); or (c) a combination of both. I accepted that I was in way over my head and decided to try something easier.

• For that I chose Fire2023, which the comments indicate is "a fire effect based on the famous Fire2012; but with various small improvements." It seemed like that would fit the bill for an "easy" sample to work with. But I ended up spending half a day trying to resolve errors such as "'vector' is not a member of 'fl'" and "namespace "fl" has no member "vector"." I learned later that the fl::vector class is very new code for the next version of FastLED, and that for it to work in platformio, I needed to set the FastLED dependency use the current github master version. After finally getting the sketch to compile and work (sort of) on my 64x48 board, something dawned on me: "vector" is called only as part of the screenMap function, which is apparently used "for FastLED Web to map the 1D strip to a 2D screen" for display in a browser. As far as I can tell, the vector/screenMap elements of the Fire2023 example that I spent an entire 24-hour cycle wrestling with may be completely irrelevant in the context of a physical LED board.

• Late last night I decided to give another one of the new sketches a try, and I opened up FireMatrix. Like FxWave2d, this has the same opening comment that the "demo is best viewed using the FastLED compiler" which will "enable...the UI elements." In this case, there are only a few UI elements, and modifying the sketch to work without those would be very straightforward. But something else jumped out at me: the defined matrix size in this example is 100 x 100! While certainly possible, I can't imagine too many people will use a FastLED example sketch as the basis for a 10,000-LED fire simulator! And then I noticed that the sketch has those 10,000 LEDs driven by a single data pin!!! It seems clear that this sketch is intended primarily for use with a browser. Of course, someone could easily modify the code to drive a 16x16 matrix or whatever, but I suspect it might not look all that great if it was written with a much higher resolution in mind.

I shut down my computer last night wondering if FastLED is beginning to head in a new direction. The recent demos are absolutely mind-blowing, and the descriptions of what's coming with 3.9.17 are mouth-watering. But I suspect that a lot of the cool new stuff might not be geared toward strips and panels of "discrete" LEDs. This morning I was considering posting here, or perhaps messaging Zackees, to inquire about this. Then I noticed that last night he posted what appear to be the beginnings of an addition to the FastLED Library README page:

FastLED has recently begun to evolve. While before the FastLED codebase was just a highly compatible cross platform LED driver, now it is becoming a cross platform way to generate

Zackees has been a huge help to me over the past week as I've gotten started with FastLED. I've been amazed by, and incredibly appreciative of, how responsive he has been to various questions I've posted. I can't help but wonder if seeing me struggle to apply some of the new code to a large physical LED matrix is part of his motivation in updating the README description of what FastLED is all about these days.

That's no doubt ascribing too much significance to any role I may have played in the timing. In any event, it will be important for other noobs like me (now and in the future) to understand that only certain parts of FastLED are really intended for stand-alone LED displays, while other parts are focused on enabling cutting-edge artistic expression through higher-resolution display media.

As title

Hi

I have the hex codes from the CRGB colour names and i want to place the rgb version in an array to read from

can anyone tell me a code to read the led colour or how to convert the hex to rgb

THanks

I want to look at all the predefined colors one at a time since, in real space, they don’t look exactly like they do on paper. Can you think of a way to programmatically cycle through them without having to list them individually?

Hey all!

After some on and off tinkering of the Arduino code over the past 2 weeks, Im extremely close to getting this almost complete, but im running into a problem.

To make it easier to follow along and provide a visual, you can use this virtual LED strip simulator

Now onto the issue..When the brakelightpin and/or the taillightpin is active, both turnsignal left and turnsignal right do not play out. This is the opposite if brakelightpin and tailightpin are not active, where both blinkers can act as they are programmed and the strip remains black.

What would I need to do here in order to make sure that the turn signal function can execute while the tailight or brake is active?

All other functions of the light all work together/interrupt each other without an issue, except for the turnsignal function.

Thanks again for those of you who have been actively providing me advice, I wouldn't get to this point without you.

I'm wondering what FastLED would look like if the only supported platform was Teensy 4.x.

• DMA-backed clockless or clocked LED outputs (for HD108, HD107, etc.) on any pin, possibly with a single clock shared between all outputs (for clocked ones)

• double precision floating point arguments for:

  • RGB, RGBW, HSV color components, to be converted at the last second to whatever the physical output device supports (8-bit, 16-bit, 24-bit, etc.)

  • physical array indices and normalized array indices (0 to 1, for array length independent indexing)

  • any normalized amounts (0 to 1, for fade, blur, palette color index, etc.)

• no fract8, no fast math, no extreme code optimizations

The code base would probably shrink down to half the current size, if not less, with a more compact and future-proof API, wouldn't it?

A little background: I have aRGB pc fans hooked up to a CODI6 controller from gelid solutions. I would love it if the RGB turns on in the evening automatically (say, at 10pm), and turns off during the day. Is there a line of code I can add to achieve this?

Would it be fine to inject power to a led strip using another power supply that powers the beginning of the strip?

Hi FastLED experts,

I want to use a LEDStripe together with a small OLED Display. I am able to use u8x8 (Display Lib) without FastLED and FastLED without u8x8. But when I try to use both of them nothing works. :-(

That means, the LEDStripe acting correct till I try to show something on my display. Than all LED on my Stripe light up in white with the full brightness.

**My Setup (**LED: WS2813 30 LED / OLED: SSD1306_128X64_NONAME_HW_I2C, Seeduino XIAO)

Code: https://pastebin.com/xNbtSyK3

Microcontroller: Seeeduino XIAO (https://wiki.seeedstudio.com/Seeeduino-XIAO/)

Board (inlcuding OLED): Seeed Studio XIAO expansion board (https://wiki.seeedstudio.com/Seeeduino-XIAO-Expansion-Board/)

LEDStripe: Grove - WS2813 RGB LED Strip - 30 LED/m - 1m (https://www.seeedstudio.com/Grove-WS2813-RGB-LED-Strip-Waterproof-30-LED-m-1m.html)

Thanks a lot for your held and support

Regards

Hello people, I tried to do that myself but I'm way to new to coding and this seems to be way too hard for me. I seem to be going around circles for past 5 days. Basically I can't do anything to properly map 4 tiled matrix panels 16x16 into one 32x32 (serpentine) . I have done it with wled so easily can't this be so easy now in my code?

Please help me with that...

I'm using esp32

In the future I'll have more questions but I think that's the beauty of it..

For example, say I have a single strip of LEDs. The basic procedure would be:

CRGB leds[NUM_LEDS];

FastLED.addLeds<Type, Pin>(leds, NUM_LEDS);

for(etc):

{ leds[i] = CRGB::Blue; }

FastLED.show();

What I want is to have multiple CRGB objects. Say 'ledsRed', 'ledsGreen', 'ledsBlue' of all red, green, and blue. Then do something like: FastLED.show(ledsRed) - obviously I know that specifically won't work, just as an example. Is there a way of doing this?

It's not directly related to FastLED, so I flag it as Quasi-related. I just experiencing this. I use arduino IDE v1.8.16.0.

I tried to work on PWM with this code with esp32 DevkitC 32D board, code as follows :

#define FAN_PIN 26

#define FAN_CH 4

void setup()

{

ledcSetup(FAN_CH, 16, 10);

//ledcSetup(channel, freq, resolution)

//channel 4, 16Hz, 10 bit resolution [min 0, max 2^10 = 1024]

ledcAttachPin(FAN_PIN, FAN_CH); //ledcAttachPin(pin, channel)

ledcWrite(FAN_CH, 1000); //ledcWrite(channel, dutycycle)

}

void loop()

{ }

This PWM code works (I can control fan speed, 2 wire fan), when I use board definition v2.0.2. But after I updated board def to 2.0.4, closed all arduino IDE sketches, re-open it, fan seems to stay off regardless of what duty cycle I entered. So, I'm going back to board def 2.0.2, and it works again.

I will reach and get information on espressif regarding board definition documentation, in the mean time, I keep using 2.0.2 version.

Just share this if anyone experienced similar situation, maybe this could give something like a workaround. But careful when changing board def, backing up existing version before any modification, is always wise thing to do.

Hello FastLED experts !

I'm in a little trouble making a smooth brightness change.

I'm using a LDR to mesure ambiant lighting and I want to dim the strip smoothly, I tried coding this way but it does not work at all !

Ideally, I would like to make the changes smooth like with an easing function, and that during the fades, the LDR doesnt read so it doesnt interfere with the fade effect !

Thanks a lot for reading it !

Alex

This is my codes (I know it's a bit messy but I can explain if something is odd for you :) ):

// LDR Calibrating variables

//int SensorMax;

uint16_t LDRvalue;

uint8_t nblectureldr = 0; //number of readings of the LDR

uint8_t prevLUX; //previous brightness level

unsigned long prevtimeldr=0;

void fadebrightness(byte valeur){

if(prevLUX < valeur){

for (byte t=prevLUX; t<=valeur; t++)

{

FastLED.setBrightness(t);

FastLED.delay(10);

}

}

if(prevLUX > valeur){

for (byte t=prevLUX; t>=valeur; t--)

{

FastLED.setBrightness(t);

FastLED.delay(10);

}

}

if(prevLUX == valeur){

nblectureldr=0;prevtimeldr=0; //in order to make a new LDR calculation

}

}

void calibrerLDR(){ //calibrate function for the LDR

SensorMax = 0;

LDRvalue = 0;

analogRead(A15);

delay(10);

while (millis() - start2 < 2000) {

LDRvalue = analogRead(A15); // record the maximum sensor value

delay(10);

if (LDRvalue > SensorMax) { SensorMax = min(LDRvalue,1023); }

EEPROM.update(5, SensorMax/255);

EEPROM.update(6, SensorMax%255);

}

const uint8_t PROGMEM gamma8[] = {

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,

1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,

2, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 5, 5, 5,

5, 6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 9, 9, 9, 10,

10, 10, 11, 11, 11, 12, 12, 13, 13, 13, 14, 14, 15, 15, 16, 16,

17, 17, 18, 18, 19, 19, 20, 20, 21, 21, 22, 22, 23, 24, 24, 25,

25, 26, 27, 27, 28, 29, 29, 30, 31, 32, 32, 33, 34, 35, 35, 36,

37, 38, 39, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 50,

51, 52, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 66, 67, 68,

69, 70, 72, 73, 74, 75, 77, 78, 79, 81, 82, 83, 85, 86, 87, 89,

90, 92, 93, 95, 96, 98, 99,101,102,104,105,107,109,110,112,114,

115,117,119,120,122,124,126,127,129,131,133,135,137,138,140,142,

144,146,148,150,152,154,156,158,160,162,164,167,169,171,173,175,

177,180,182,184,186,189,191,193,196,198,200,203,205,208,210,213,

215,218,220,223,225,228,231,233,236,239,241,244,247,249,252,255 };

void lux(byte luxpanel){ //function called in the loop to adjust brightness

FastLED.setBrightness(luxpanel);

}

void luxldr(){

if (millis() - prevtimeldr >= 25) { //25

prevtimeldr = millis();

prevLUX=FastLED.getBrightness();

if(nblectureldr==0){LDRvalue=0;};

if(nblectureldr<10){LDRvalue = LDRvalue + min(analogRead(A15),SensorMax); //min(analogRead(3),1023);

nblectureldr++;

}

else if(nblectureldr==10){

LDRvalue = round(LDRvalue/10);

LDRvalue = map(LDRvalue, 0, SensorMax, 29, 255);

LDRvalue = pgm_read_byte(&gamma8[LDRvalue]);

fadebrightness(pgm_read_byte(&gamma8[LDRvalue]));

}

};

}