File sent. I’d be damned if it finds a reference somewhere that I missed … or that’s being included without my knowing.
Also - random8 inlines aggressively (more about performance than code size) - and is probably about 32 bytes per use. There is probably a point based on number of times that you call random where your code size will go back up. I’m beginning to suspect that’s more likely what you’re seeing here. All the rand functions combined take up about 338 bytes of program space - so if you have more than 10 calls to random8 - your space usage will go up considerably.
Ah, that might be it. I’ll have to rethink that portion of the code. It’s being called 12 times within one pattern function.
Actually, it’s not being called 12 times, it just appears 12 times. Through case switching, the most it will get called is 8 times …
From just a quick skim of the symbol dump/disassembly
- 7536 bytes are being used by the Sd card classes.
- 1396 bytes are being used by your main loop function.
- 1378 bytes are being used by wheelDivisions
- 1480 bytes are used by LPD8806Controller::show/showColor() - but I think I can shave that down by at least 300 bytes by keeping gcc from inlining there where it shouldn’t be
- 788 bytes are being used by usb functions
- 878 bytes by a pair of vectors - vector_10 and vector_11, not sure what they are for yet
- 704 bytes by strtod
- 368 bytes used by batteryCheck
- 310 bytes by hsv2rgb
- 296 bytes are used by a function called OneButton::tick?
- 244 bytes by getFileData
- 178 bytes used by delay
Some good info in here for me to use to get the library trimmed down even further 
wheelDivisions is the one with the numerous calls to random8() … so it would make sense that it’s large based on your previous comment about random8().
tick() is part of the OneButton library.
Also - i really should make fastpin usable for reading pins as well as writing pins - get rid of all your digitalRead/Write calls (a total of 354 bytes used by digitalRead/digitalWrite and turnOffPWM which they call).
Digital write takes at LEAST 35 clocks, upwards of 67 (plus another 13-20 clocks on top of that to call turnOffPWM).
FastPin<13>::hi() takes two clocks. Period. If I added a value checking function to FastPin, that would also take two clocks.
Ah, vector_10 and vector_11 are the USB interrupt handlers.
(Also - this is an argument for putting everything FastLED into a namespace - would make it a lot easier for me to pick my functions out of your size table 
Weird - the arduino compiler isn’t aggressively inlining writePixels, but your compiler is. That’s why showColor and show have exploded so much in size.
The digitalRead() and Write() functions are controlling an error LED, as well as turning on/off the NPN/PNP pairs (that in turn will apply VCC to the strings when required.)
Nice - and probably not used enough to justify switching to FastPin :). BTW - are you also blocking the data lines when you block the VCC lines to the pins/chips? I have sometimes seen what appears to be the WS2812’s (and other chips?) attempting to draw current down the data line if VCC isn’t connected 
“My compiler” would translate into AS6.
It uses the AVR toolchain. AVR8 toolchain uses GCC 4.7.2, the avr32 toolchain uses 4.4.7
I also suspect you’re compiling for performance optimization, not code size, judging by the aggressive inlining i’m seeing.
Actually, I’m using that ability to my advantage. For some odd reason, if the LPD8806 sits unused for some extended period, it reset to full duty cycle so the next time you apply power it drives the attached LEDs to full white. When I approached my vendor and through several e-mails back and forth, the manufacturer suggested keeping VCC low (cut off), sending the equivalent of CRGB::Black to the strip, and then apply VCC. There’s enough phantom power being drawn on the CLK/DATA lines that it will latch the data.
Huh - neat idea.
Ok, hold the phone. I’m sending you two new files …
Hey @Daniel_Garcia , how did you get the sizes of each function from the elf file? I want to see where else I can optimize/shave this code.
avr-objdump -t