Sooo, inquiring minds want to know: why would using FastLED. take up more memory than using LEDS. ? With my POVpoi code being so large and on the verge of bursting through the virtual memory block, when all my calls are to LEDS., it compiles down to 28,648 bytes. but if I replace all of them to use FastLED. instead, it compiles to 28,770 - which incidentally is too large to fit. I thought one was just an alias to the other …
I am completely stumped.
I’ll stare at the code a little.
#include “FastLED.h”
#define NUM_LEDS 48
CRGB leds[NUM_LEDS];
void setup() {
FastLED.addLeds<LPD8806, 6, 7, RGB>(leds, NUM_LEDS);
}
void loop() {
FastLED.show();
}
That compiles into 6,260 bytes. However, if I replace FastLED.addLeds() and .show() for LEDS.addLeds() and .show(), it compiles into 6,254.
Yes I know the loop() is empty, it’s just a test. 
Hrm. Wonder if there’s symbol issue.
Mind you, I want it to compile smaller, not larger. And since I’ve been using LEDS. for a while now, I never noticed it till now when on a whim I was testing what the difference was, and that happened …
(Also as an orthogonal experiment in code size, try declaring all of your functions as ‘static’. Change anything?)
In my POVpoi code or in the above snippet? The above snippet won’t work because Arduino declares them as extern.
Yeah-I meant in code that has functions other than setup and loop.
Smaller … original code (without any static declarations, and using LEDS.) compiles into 28,648. Declaring all functions static, and leaving LEDS., it compiles down to 28,538, or 110 bytes smaller.
Replacing all instances of LEDS. to FastLED. and leaving the static declarations goes up to 28,664, which is still larger than the original code, but just under the max memory threshold.
For reasons that are not immediately clear to me, “LEDS” is an instance of the class, but FastLED is a reference to an instance of the class:
extern CFastLED & FastLED;
extern CFastLED LEDS;
This means, I suspect, that every time you say “FastLED” it’s adding an additional pointer dereference somewhere.
Dan’s on vacation for the next few days, but I’ll chat with him about it when he’s back on-line. If we can save a few bytes, we’ll do it.
Yah, we have the crux of it and it’s a small change. We’ll roll it in in the next batch of big fixes.