Is there a way to optimize FastSPI to be smaller, for things like the trinket? I tried porting over the code from my LED Tie, which is fairly small, and I found I needed to remove pretty much all the code to get it compile small enough to fit. I’ll pastebin my code if anyone wants to see it, maybe spot something I can do to shrink it.
I suppose it would fit if I removed the bootloader, but then I’d have other issues (like not having a standalone AVR programmer!)
The library is constructed in such a way as to not include any code that you aren’t calling, in large part to keep it smaller. What version of the library are you using? There is one place where we’re doubling up on a block of code that, for the trinket currently, is about 470 bytes each, so I can free up another 470 bytes, give or take, once I fix that duplication.
Also - a bunch of the avr library stuff is pretty large, and gets included, and there isn’t a lot of good way around that. I would be curious to see your code, though - to see if there’s anything else obvious - i’ve been testing with some more verbose trinket code with some complex pattern code and haven’t been running out of space on the trinket yet.
1368 bytes are taken up by arduino library functions - 622 bytes of that is caused by calls being made to new - which happens behind the scenes when you call FastLED.addLeds.
If you want to get around that, you can construct the controller statically yourself, and add it - rather than relying on the library to do it for you (this is one of the advanced usages that I need to write up for documentation).
E.g.
#include<FastSPI_LED2.h>
#define DATA_PIN 4
#define NUM_LEDS 64
CRGB leds[NUM_LEDS];
WS2811Controller800Khz<DATA_PIN> ledController;
void setup() { FastLED.addLeds(&ledController, leds, NUM_LEDS); }
void loop() { … normal stuff … FastLED.show(); }
If you have no other code that’s calling new/delete/malloc/free, then this should shave around 600 bytes off the size of your executable.
Another 84 or so bytes are taken up by the fact that there’s no hardware multiply on the attiny (which is why the current version of the library can’t do the inline scaling) - and there’s a variety of related functions that get compiled in.
Another 278 bytes are taken up by micros/delay/delayMicros.
then something’s strange, is all.
Here’s the basic code, before I started cutting it down. It may be an issue with compiling it on Ubuntu- which is the only way I can get the trinkets to program. Seems to compile to something like 6.8k, and by removing all of the global vars, and the two biggest functions, I got it down to 5.3k. Needs to be less than 5.2k to fit.
… And I can’t compile it at all for an AtTiny target on this machine. Ends up being 7.4k, after cutting out the useless bits, when compiling for an Uno.
Edited Code: http://pastebin.com/68bLsa5p
I think I need to wipe my Arduino install on this machine and start fresh.
Oh man, the floating point math that you’re doing in there is probably pulling in quite a bit of code - because that’s all implemented in software/as library functions.
Replace the calls to random with calls to random8 - smaller, faster code, might help with code size.
Check this out here - http://pastebin.com/1shC9w65
I was able to get it down to 4.4k - making the led controller static took me down from 6.5k to 5.88k. Then replacing calls to random with random8 and randomSeed with random16_set_seed took it down to 5.6k. I then replaced sin with sin16 and got rid of the floats there, and that took you down to 5.3k. Then I got rid of the rest of the floats and the float operations and got it down to 4.4k.
I’m not 100% convinced that I did the conversion from floating point to fixed point math right, @Mark_Kriegsman is the master of that, and I was mostly rushing because I need to head out shortly - but hopefully this shows off some things that you can do to trim down the code size a bit more.
Also, you might need to run the trinket at 16mhz mode, I’m not sure if the problems I saw at 8Mhz are in the shipping code or in the code that i’ve got locally where i’ve been doing some re-working/horking around.
On ATmegas, floating point math is miserable.
On ATtinys, it’s pure poison.
Floating point math on an 8-bit processor (especially with no hardware MULtiply instruction, eg on the ATtiny) makes the code both huge and slow. Use integers and fixed point every single place you can to save precious space and CPU cycles.
Dan is totally on the right track here.