Fastled: Support more than 64K pixels

[marcmerlin]

One thing that's been biting me recently is as you may remember, I'm offering a FastLED CRGB backed framebuffer that displays on lots of backends, from addressable pixels, to RGBPanels, to TFT screens ( https://github.com/marcmerlin/Framebuffer_GFX ).

One issue I'm hitting with TFT screens and RGBPanels on rPi (I wrote a glue library to run Arduino and FastLED sketches on rPi https://github.com/marcmerlin/FastLED_RPIRGBPanel_GFX ) is that some FastLED functions assume you'd never have more than 64K pixels. It's not an unfair assumption, but not true anymore in my use (320x240 pixel TFT for instance, or high resolution RGBPanel of 256x256 which wraps back to 0)

Long story short, I'm hitting the 65536 pixel limit that is assumed in multiple FastLED functions like fade and friends.

Would it be possible to raise all those uint16_t to uint32_t ?

[kriegsman]

You know, I've thought about this, and I think perhaps the thing to do is to create a typedef something like pixelIndex_t which could default to 16 bits wide on 8-bit (AVR) platforms, default to 32 bits on 32-bit (ARM, ESP, Intel, etc) platforms, and in all cases be user-overridable with a #define.

[marcmerlin]

Thanks @kriegsman
I just built a new RGBPanel array that's 384*192, turns out that's also too many pixels :)
I realize you're trying to save a few precious bytes for people still using 328p. If you are worried about the few extra bytes used by the functions that will process 32bit instead of 16bit? I think the caller can still send and receive 16bit so that it remains compatible?
I can however see that if a function returns a 32bit int to a caller that stores the result in a 16bit int, that would trigger a compilation warning, but still work as long as there is no overflow, correct?
That said, if you are ok with the extra work of making the function change between 16 and 32bit depending on the the CPU, that'd be fine with me, or use "int" which should default to 16bit on 328p and 32bit on better MCUs?

[bbulkow]

In the days when arduinos had 2k of RAM, this made sense, but those days are vanishing. With our greatly little embedded systems cresting into megabytes, and this code being used on higher power machines like the RPI, I think it's time to raise the type. Alternately, since someone's going in, use an abstract type ( PixelLen_t ) and thus allow different ports to set what makes sense. I'd probably vote for just going 32 at this point, but it's not a democracy :-)

I'm not above 64k yet because each of the ESP32 controllers I use is only 10 bucks and well networked, but I can see larger panels where it makes sense.