I'm trying to compile the test NoisePlusPalette for an attiny85 arduino clone (micronucleus bootloader) after

I’m trying to compile the test NoisePlusPalette for an attiny85 arduino clone (micronucleus bootloader) after rebuilding a dev environment. I’m now running into size errors which I wasn’t last time I built this. Did fastled get bigger? Does gcc 4.3.2 make larger files? Did I completely forget tweaks I was doing to reduce the size?

/home/blackbox/Downloads/DigisparkArduino-Linux64/Digispark-Arduino-1.0.4/hardware/tools/avr/bin/…/lib/gcc/avr/4.3.2/…/…/…/avr/bin/ld: NoisePlusPalette.cpp.elf section .text 'will not fit in region text’
/home/blackbox/Downloads/DigisparkArduino-Linux64/Digispark-Arduino-1.0.4/hardware/tools/avr/bin/…/lib/gcc/avr/4.3.2/…/…/…/avr/bin/ld: Region `text 'overflowed by 878 bytes

FastLED 3.0 + arduino 1.0.4 + gcc 4.3.2 seems to work. So either FastLED grew or Arduino did. Are there known problems with 1.6.5?

I have noticed that gcc 4.8 generates larger files - also be aware that noise has a 256 byte table that will eat up program space as well.

I don’t know about the libraries between 1.0.6 and 1.6.5 - I wouldn’t be surprised if they changed as well. As for FastLED being larger - all that gets compiled in is what you use (or what you use uses/references). I’d have to do dumps on the pair of generated object files to break down where the space is going.

What LEDs were you building for?

For some reason I didn’t get any notifications on this post.

I’m using a strip of ws2812b. I was able to piece together my old build chain before I crashed and everything worked (the first comment on this thread). Once I get home and get the kids in bed I’ll poke around at this and publish my results.

Looking at the output of building NoisePlusPalette in 3.1:

  • 512 bytes are used by the 8 palettes (cloud, forest, heat, etc…)
  • 138 bytes used by setMaxRefreshRate (new to 3.1)
  • 154 bytes used by countFPS (used to disable dithering if fps is below 100fps)
  • the noise functions themselves are fairly large at 350 bytes for fillnoise8 and 890 bytes for inoise8_raw
  • the ws2812 output function is 982 bytes
  • 257 bytes are used by the noise lookup table
  • The compiler is insisting on including nscale8x3_video twice, which is 160ish bytes instead of 80ish

Here’s a list of the largest space using things, sorted, with sizes in bytes in hex:

00000032 init
0000003c ClocklessController<(unsigned char)3, 6, 6, 11, (EOrder)66, 0, false, 10>::clearLeds(int)
00000040 CloudColors_p
00000040 ForestColors_p
00000040 HeatColors_p
00000040 LavaColors_p
00000040 OceanColors_p
00000040 PartyColors_p
00000040 RainbowColors_p
00000040 RainbowStripeColors_p
00000044 .hidden __udivmodsi4
00000048 delay
00000048 micros
0000005a nscale8x3_video(unsigned char&, unsigned char&, unsigned char&, unsigned char)
0000005a nscale8x3_video(unsigned char&, unsigned char&, unsigned char&, unsigned char)
00000060 SetupBlackAndWhiteStripedPalette()
00000084 PixelController<(EOrder)66>::init_binary_dithering()
0000008a CFastLED::addLeds(CLEDController*, CRGB*, int, int)
0000008a CFastLED::setMaxRefreshRate(unsigned int, bool)
0000008e __vector_4
0000009a CFastLED::countFPS(int)
000000b2 ClocklessController<(unsigned char)3, 6, 6, 11, (EOrder)66, 0, false, 10>::showAdjTime(unsigned char const*, int, CRGB&, bool, int)
000000d0 SetupPurpleAndGreenPalette()
000000de SetupRandomPalette()
000000ec mapNoiseToLEDsUsingPalette()
000000f2 CFastLED::show(unsigned char)
000000f8 ColorFromPalette(CRGBPalette16 const&, unsigned char, unsigned char, TBlendType)
00000101 p
00000108 setup
0000014c hsv2rgb_rainbow(CHSV const&, CRGB&)
00000158 ChangePaletteAndSettingsPeriodically()
0000015e fillnoise8()
000001d0 void fill_gradient(CRGB*, unsigned int, CHSV, unsigned int, CHSV, TGradientDirectionCode)
0000037a inoise8_raw(unsigned int, unsigned int, unsigned int)
000003d6 ClocklessController<(unsigned char)3, 6, 6, 11, (EOrder)66, 0, false, 10>::showRGBInternal(PixelController<(EOrder)66>&)

Anyway - noise and palettes both want to use a bunch of program memory (and the code to use/manipulate them, even more). You could probably save some program space by using the controller directly and not using the FastLED object, e.g.

#include<FastLED.h>
#define PIN 4
#define NUM_LEDS 20
CRGB leds[NUM_LEDS];
WS2812<PIN, GRB> ledController;
void setup() { ledController.init(); }
void loop() {
// lblah blah blah
ledController.show(leds, NUM_LEDS,255);
}

A compile of a ‘sketch’ using noise, sin, and cos (building a fillnoise matrix and sampling it given the angle of the poi):

arduino 1.0.4 + FastLED 3.1 - 5,468
arduino 1.0.4 + FastLED 3.0 - 5,476
arduino 1.6.5 + FastLED 3.1 - 6,144

Since I’m not using anything from Arduino I should stick with 1.0.4. I should really just remove Arduino completely and the bootloader to free up space for new palates.

What did you use for the code size analysis?

Objdump - Swiss Army knife object file parser and disassembler - it’s how I tell how much gcc is fucking with my code :slight_smile: