I’m working on additional IR support for some routines and am working on the ability to change the length of the strip with a few keypresses and store that to EEPROM.
It seems to me that NUM_LED’s and the array definition are fixed at startup, so the best I could do is create an array that’s LARGER than what I need and then use a value that’s smaller for my actual strands. . . which I’ve got working.
Any thoughts on that?
That’s my understanding too, the total array size is fixed at compile time for whatever you define CRGB leds[x] to be. Set x to your max number of pixels or something larger, and then only iterate over whatever you need based on your real-time input.
Thanks for the confirmation. It’s working nicely. I’m also storing the current display mode in EEPROM as well and hope to be able to support a strand ID value in there as well.
This wasn’t for real-time changes, but it’s slightly related perhaps. Someone had asked about a setup with multiple strips of different lengths that change periodically. This code still needs to be updated and recompiled for each different strip setup, but this was my concept to easily allow changing the strip lengths and then have the code properly iterate to the correct number of pixels on each strip.
AllPixel by does this by using malloc instead of hard-coding a large pixel count, but your way is likely simpler/safer: https://github.com/ManiacalLabs/AllPixel/blob/master/Firmware/Firmware.ino
I always wondered why fastled was like this, I do it the same way adafruit does for the most part, I bet you could go crazy also and hook the last pixels dout to a input and have an auto length detection method that just pumps data out until it gets that shift registers output back. I was also considering reducing memory usage by not storing repeating patterns in the buffer and just having it loop the buffer if its length is less than number of pixels, so say 5 pixels of buffer data but 150 pixels defined, and just loop those 5 until end and then latch or whatnot.