alto777:
Why bother? If you ever have room for the LEDs, you'll always have room. Just use a maximum number, then talk to as many as actually exist. Or talk to non-existent LEDs. Doesn't matter. As long as there is memory devoted to them.I routinely hook up a few LEDs on a little test strip to check programs designed for many more. No problems.
I am missing something, tell me.
a7
But how does he do it then?
nflug:
But how does he do it then?
Ask him. It's possible his animations are less ambitious.
nflug:
But how does he do it then?
Well when I said
If you ever have room for the LEDs, you'll always have room.
I should have added
If you ever have time for the LEDs, you'll always have time.
If your animations run slow at 1000 or 2000 LEDs, you are running out of time.
Do you want to run the animations with a dependence on how many LEDs are hooked up?
Then you are back, more or less, to your original question. I think it should be a simple matter to trick the fastLED library calls to output only as many packets as necessary.
But it should not need allocating and freeing of memory.
Allocate for a maximum number of LEDs.
Tell fastLED you have some number (<= maximum obvsly) and pass the address to it, doesn't matter that it's too big or too small.
Then all your code and the fastLED library will only take to that smaller number, your animations run apace and all you have which you don't care about at all is an unused amount of memory at the tail end of your real pixels.
Remember, these are there if needed and were not in your way…
Now with more LEDs, more of that memory is used, and your animations start to look like crap. You are out of time.
It should be possible to change the number of LEDs that fastLED will pimp out data for on the fly, but it would be some kind of trick to just change the object's idea of how many LEDs there are and laving the data pointer where it always is: the maximum big array.
fastLED didn't have a terminating call I could find. I thought you could kill one object and instantiate a new one with a new size (BUT the same actual memory address), but I am sure someone can explain or make a hack that just changes its idea of how many LEDs to talk to.
HTH
edit: and you'll have to explain to people why it goes crappy.
a7
First, as noted, you should create the CRGB array to allocate space for the maximum number of LEDs that will be ever needed. Next, to dynamically change the number of "real" LEDs processed, try:
#include <FastLED.h>
const uint16_t numLeds = 2000;
const uint16_t realLeds1 = 200;
const uint16_t realLeds2 = 100;
CRGB leds[numLeds];
CLEDController *controller;
void setup() {
Serial.begin(115200);
controller = &FastLED.addLeds<WS2812B, 4, GRB>(leds, numLeds);
fill_solid(leds, numLeds, CRGB::Green);
controller->showLeds();
delay(2000);
fill_solid(leds, numLeds, CRGB::Black);
controller->showLeds();
delay(2000);
controller->setLeds(leds, realLeds1);
fill_solid(leds, realLeds1, CRGB::Blue);
controller->showLeds();
delay(2000);
fill_solid(leds, realLeds1, CRGB::Black);
controller->showLeds();
delay(2000);
controller->setLeds(leds, realLeds2);
fill_solid(leds, realLeds2, CRGB::Red);
controller->showLeds();
delay(2000);
fill_solid(leds, realLeds2, CRGB::Black);
controller->showLeds();
}
void loop() {
}
Thanks for your help.
I found a solution, how FastLED only pushes the amount needed, even if the array is bigger.
FastLED[0].show(LED_ARRAY, NUMBER_TO_PUSH, BRIGHTNESS);
If the real amount gets bigger it starts getting slow for sure but than I have to think of a microchip with more memory.
Does anyone of you know an alternative for ESP32 (BLE) that is cheap & has more RAM?
Or is it possible to add "external" RAM to the ESP32 I heard that should work somehow.
nflug:
If the real amount gets bigger it starts getting slow for sure but than I have to think of a microchip with more memory.
What proof do you have that the problem is memory? What is your theory of how lack of memory could possibly down the animation?
I'm pretty sure I don't buy it.
gfvalvo:
What proof do you have that the problem is memory? What is your theory of how lack of memory could possibly down the animation?I'm pretty sure I don't buy it.
I don't need to prove anything. Read all the comments above from the other users. I tried it with a FastLED example (like only 20lines of code) and it doesn't work with that amount of LED's.
Or can you tell me maybe how I can run the "Cylon" FastLED example (on ESP32 / with WS2812B) with 2000 LED's on 30-60 FPS? That would be the simplest example.
nflug:
Or can you tell me maybe how I can run the "Cylon" FastLED example (on ESP32 / with WS2812B) with 2000 LED's on 30-60 FPS? That would be the simplest example.
You can't. At least not using a single strip and single Output pin. @arrg already laid out the math for you in Reply #17. It's fixed, nothing you can do about it, and it has nothing to do with the amount of processor memory.
I think your only shot is using DMA techniques to simultaneouly drive multiple strips, as I previously suggested.
gfvalvo:
You can't. At least not using a single strip and single Output pin. @arrg already laid out the math for you in Reply #17. It's fixed, nothing you can do about it, and it has nothing to do with the amount of processor memory.I think your only shot is using DMA techniques to simultaneouly drive multiple strips, as I previously suggested.
I don't use multiple pins. I have 1 pin where 1 strip is on. And on that strip there is another and so on. So you could say I have only 1 strip. I dont have to drive multiple strips simultanously, that is not my question. I'm asking about one strip that is made out of multiple parts eg 144, 60, 30 strips with leds.
I understand that you could have multiple physical strips all in cascade, connected to a single pin, forming what looks like to FastLED, one logical strip. I also understand that your design goal is to run an animation on this strip (up to 2000 pixels long) at 30-60 FPS.
What you don't seem to understand, despite being told by several people, is that is just not going to happen. As @aarg pointed out in Reply #17. Each pixel's worth of data takes 30us to shift out. So, 30us / pixel * 2000 pixels = 60,000 us. Plus, the LEDs need a 50us "breather" after ever update to latch the data. That mean, 60,050 us per update, or16.65 fps.
That's the math, no matter how much you don't like it.
The only solution I could come up with to meet your 2000 pixel, 30-60 FPS design objective (there certainly may be other ways that I'm not smart enough to see) is to split the 2000 pixels into multiple strips. If you could have 8 strips at 250 pixels each (and update them simultaneously), then the update period would be 30us * 250 + 50 = 7550 us. That's 132 FPS. Of course, you'd have to put the 8 strips in cascade PHYSICALLY to look like a single strip. And, probably more difficult, you'd need to be clever in your coding to make the composite look like a single, contiguous strip.
One way to achieve the simultaneous updates is to use DMA and write to a single memory-mapped port supporting the multiple pins driving the strip. The Teensy folks (who actually know what they're doing) have gotten some pretty impressive results: OctoWS2811 LED Library - YouTube
So, if you really need 2000 LEDs at 30-60 FPS, that's one way to go. As I said, there may be others. But, it's pretty clear that the bottle neck is NOT processor memory capacity.