Color me surprised:
While I understand that random8() is purely for dealing with 8-bit values (as much of FastLED’s color calculations are), I wasn’t expecting it to result in a larger binary.
Do you have anything else that you’re using/calling that’s also calling random()? If so - then then what you’re seeing is the cost of adding random8() to the code - I did a quick check here. With RGBCalibrate:
no random - 3144 bytes
random - 3636 bytes
random16 - 3202 bytes
random8 - 3226 bytes
The surprise is that random 8 results in 24 more bytes than random16!
No, I replaced everything to random8() then back to random() …
do the build with random - then send me your foo.cpp.elf output and then do the build with random8 and send me your foo.cpp.elf output - I want to look at the decompiles and and see what’s going on there.
random8 calls random16 for its base randomness, and depends on it.
Even if random8() uses random16(), that should still be less than the Arduino random() as that’s a long type.
Ah - you’re still calling randomSeed, which in turns calls srandom and so on down the chain. So your “change to random8” build still has the random code in it as well.
So what’s the equivalent?
random16_set_seed
That made a difference … 8574 with random8().
Wow, the srandom call as part of randomSetSeed brings in a lot of infrastructure, doesn’t it?
I did some work for the dithering branch/fastled2.1 - but I still have some more ideas how to bring the compiled code for FastLED down even further (as well as some hooks to support people getting it even smaller, still 
Evidently it does. But now I’m replacing all my random() calls in the full program to random8() or random16() (where needed), and replacing the randomSeed() and once again, it’s growing in size … Urgh. Going to have to do this systematically, one by one, see where it’s getting bloated.
I take the output of:
avr-objdump t with\ random.cpp.elf | grep ‘text’ | cut -c24 | sort -n
and paste it into the form on http://demangler.com -
and now I have a list of demangled method & data names, sorted by size.
Some are functions, some are lookup tables. Here’s a subset of the output from one of the things you sent me:
00000030 USB_RecvControl(void*, int)
00000032 SendInterfaces()
00000032 USB_Recv(unsigned char)
00000032 Serial_::peek()
00000038 HID_Setup(Setup&)
00000040 USBDevice_::attach()
0000040a loop
00000042 HID_SendReport(unsigned char, void const*, int)
00000042 cdcInterface
00000044 random(long)
00000046 Serial::read()
00000050 Serial_::write(unsigned char)
00000054 Print::write(unsigned char const*, unsigned int)
00000065 _hidReportDescriptor
00000068 USB_Recv(unsigned char, void*, int)
00000070 analogRead
00000078 CFastLED::show(unsigned char)
00000080 asciimap
00000086 Keyboard::release(unsigned char)
00000088 USB_SendControl(unsigned char, void const*, int)
00000090 __vector_23
00000124 AVRSoftwareSPIOutput<(unsigned char)6, (unsigned char)12, (unsigned char)0>::writeBytesValueRaw(unsigned char, int)
00000266 LPD8806Controller<(unsigned char)6, (unsigned char)12, (EOrder)10, (unsigned char)0>::show(CRGB const*, int, unsigned char)
00000292 __vector_11
00000362 LPD8806Controller<(unsigned char)6, (unsigned char)12, (EOrder)10, (unsigned char)0>::showColor(CRGB const&, int, unsigned char)
(hmmm, bitbang’d spi is being a little bit too aggressive about inlineing, I bet I can shave off a good 500+ bytes for you later tonight)
Ok, riddle me this. The full POV code right now compiles into 23,382 bytes. I already swapped out randomSeed() for random16_set_seed(). Everywhere I changed random() to random8() has been a positive in the sense that it’s shaving off bytes. However, when I try to change the following, it increases again:
split = random(4);
while (split == prevSplit) split = random(4);
Like I said, with those two lines as is, the full code compiles into 23.382 bytes. If I replace them for random8():
split = random8(4);
while (split == prevSplit) split = random8(4);
It grows to 23,446, or an additional 64 bytes. Why’s that?
Same with this. Changing:
fill_solid(&(leds[0]), 48, colors[random(6)]);
to
fill_solid(&(leds[0]), 48, colors[random8(6)]);
increases by 36 bytes.
Two things are happening there - one is that random8 is likely being inlined into your code - which is why the code increase.
The other is there’s likely something in your full pov code that’s still referencing random, which is why it isn’t going down. If you send me the .elf file from the full POV code I can, again, go through it and see what’s eating up space where.
(It looks like Project Options | Output format lets you choose elf output).
Huh, fascinating, it’s inlining the bitbang’d version of writePixels, even though there’s nothing in place telling it to. Hey, GCC! That’s not very friendly for code size optimizations.
I replaced all forms of random to random8 (or random16), there’s no reference to Arduino’s long random anymore.
Again, send me your elf file. I think something that you’re referencing or that atmel studio is compiling in is still referencing it.