Addressing a single LED?
If I need to only change a single LED, or maybe a couple LEDs close to the beginning of the strip, I imagine we could save a lot of CPU cycles if we only update the LEDs in question and not the whole strip. Refresh rate would also improve. Clearly, it’s technically doable. But does FastLED support it? I can’t find any API other than .show() which updates the whole thing, often quite wastefully.
Unfortunately, the way the strips work (e.g. they take data, then pass the rest down the rest of the strip) - there’s no way to say “Just update the 5th led in the strip”. That said, you could, in theory, only update from the beginning of the strip to the last changed led in the strip. However, doing this in a way that doesn’t end up hurting your performance more in the long term (by pushing out more updates than you should) and in a way that would work generically with FastLED (how should the library determine what the furthest changed led is, etc…) means that it’s not something that’s exposed by default.
That said, for advanced use/edge cases like this - you can get a hold of the underlying LED controller objects directly - see Multiple Controller Examples · FastLED/FastLED Wiki · GitHub - and then you can call show yourself, lying about how many leds to write out. e.g.
#include <FastLED.h>
#define NUM_LEDS 200
CRGB leds[NUM_LEDS];
void setup() { FastLED.addLeds<NEOPIXEL,5>(leds, NUM_LEDS); }
void loop() {
leds[10] = CRGB::Red;
FastLED[0].show(leds, 11, FastLED.getBrightness());
}
doing this you need to manage whether dithering is enabled yourself (because FastLED.show() is what does the timing checks to toggle dithering off if you are under 100 fps) and you will also need to do power management yourself. And of course you need to manage what leds have been changed, to determine how far into the strip needs to be written on a given frame. For that matter, you will want to disable dithering if you do this, because otherwise, dithering won’t be running on the leds after the last changed one, so you should just disable it entirely.
Because you’re creating a situation where every frame you write out might have different timing, you may end up seeing things like your frame rate becoming variable, which you’ll also want/need to account for.
Personally, i’ve found that in the real world, a significant portion of my animation frames involve animating leds near the end of the strip, and so I think most of the time/frame rate savings that would come from this is more theoretical than not, at the cost of some extra code complexity/juggling and less deterministic frame rates.
Great explanation, thank you. I agree this could end up not being something useful for any particular completed project, but I love that the option is there and I’ll certainly experiment with it.
“Clearly, it’s technically doable” — not quite… Most LED strips are more or less glorified shift registers with integrated PWM controllers for the LEDs. When data is written, the pixel will take it’s chunk of bits off the stream, and then pass on the rest. there’s no actual “Addressing” going on (you get some really funky effects manually sending bits since the wrong number of bits per channel will get you one correct LED every few when everything lines up) While working on some audio-reactive code I ran into this as I was bitwise editing the data being sent to the LEDs, and incorrectly assumed that the pixels I was using (not sure which ones they were anymore) used the same number of bits for each of the three channels (they didn’t), result being that it would look OK when green was off, or blue was less than 128, but went funky outside of that range.
@Zeno_Le_Hericy_Z-Inv I understand that, but if you do not need to change the last LED in the strip, you can already save a bit of time, right? And if you only need to update the first 10 LEDs out of 100, that’s a lot of potential time savings.
@Alex_D1 Fair enough, If you have a pattern that never uses more than the first 10, it would definitely save some cycles to do that. However, if you have to loop through the whole array to find the last pixel that needs to be updated, then send the LEDs, you’re definitely better off just sending the whole strip. essentially you’d need two loops, one that goes from 0 to NUM_LEDS that returns “last_updated_led”, followed by one that goes from 0 to “last_updated_led” actually sending the data. I suppose if you are individually setting pixel values in your patterns, you might be able to do something along the lines of “if pixel being set > current max, then current max = pixel being set” and reset the max every time “show” is called, but that means adding quite a bit of logic every single time a pixel change is called. If you figure something out that works definitely post it!! could be quite useful provided that the overhead doesn’t hamper performance (the above method using if statements may improve performance at low pixel numbers, and kill performance at high numbers)