Problems with attiny85, -Os, Arduino IDE 1.6.4

[jtatum]

My sketch is targeting a Gemma, but I'd guess this affects Trinket as well. I initially thought FastLED 3.0.3 just didn't work on this platform until I saw issue #43. The solution for me was to edit the Arduino IDE's platform.txt in /Applications/Arduino.app/Contents/Java/hardware/arduino/avr and change compiler.cpp.flags from -Os to -O1. It seems like whatever compiler change caused issue 43 is now in the mainline Arduino IDE.

Like that issue, timing was broken to the point where it couldn't drive Neopixels and the size is quite a bit smaller with -O1 than with -Os.

[focalintent]

I should see if there's things I can do with compiler directives to prevent this. Some of this is that gcc's optimizer likes to re-arrange the asm code for WS2812 and friends. It's an irritating bit of behavior by gcc.

[timvancromvoirt]

Oh thank you so much! I tried running Fastled 3.0.3. on a bare attiny85 but it didn't work. All the LEDS were full bright white. Now I changed the line you suggested: from -Os to -O1. And now it works! Great stuff, thank you so much again!

[MattStarfield]

This fix worked for me as well. My setup:
Arduino IDE 1.6.4
Win 7 x86
Adafruit Trinket (attiny85)
FastLED 3.1
NeoPixel Stick (8 LEDs)

I was getting full white on all LEDs with a faint trace of the Cylon pattern running. You could actually see the Cylon pattern better in the reflection off the table than looking at the NeoPixel Stick since the bright white LEDs "blew out" your eyes.

After changing compiler.cpp.flags from -Os to -O1 in platform.txt, the Cylon sketch ran as expected - no more blinding white!

As a side note, the Cylon sketch takes about 1:45 to compile- probably an unrelated issue. the -O1 fix did not help the slow compile time.

[focalintent]

Yeah - someone else is reporting slow compile times on windows - unfortunately, I suspect this is a bug with the windows avr-gcc compiler - the compile times under os x are about 10 times faster. (The compile times under windows 10 on the one windows machine I have in my home here are also faster than this - but still slower than the mac)

[DSeiford]

I changed the compiler settings as well and it does seem to take much longer to compile with that setting. At least it works!

This change fixed my issues with getting TM1803 LED strips to work with fastLED and the newer IDE on Windows.

[jtatum]

I was also seeing incredibly slow compile times under OS X, an issue I didn't see with the neopixel library. Sorry, I wish I were smart enough about avr and gcc to figure out why.

[focalintent]

When using ws2811 leds on AVR there is a lot of very detailed and involved and tuned asm code to allow for things like scaling, color correction, and dithering to happen with 0 overhead.

On my Mac, this adds about 20s to the compile time for each time you call addLeds for ws2811. So if you are doing 8 lines on AVR you're looking at minutes of compile time (and really, at that point you should be using a teensy3/3.1)

When you say slow compile times, it'd be useful to have an actual time (for some people 20s is slow, for others it isn't slow until you hit minutes), as well as what code you are trying to compile.

[MattStarfield]

btw Daniel, thanks for all your work with this and how engaged you are in these issues forums! FastLED is an incredible library!

[shockwaver]

I had this exact issue with a bare ATTiny85 - switching the compiler flag fixed it up.

[pattydl]

Success! Thanks very much. The compiler fix worked.

[focalintent]

Short version: Finally tracked down and fixed the issue (so folks won't need to make the compiler flag switch anymore) and am pushing the fix into the FastLED3.1 branch right now (and this was one of the major issues blocking pulling 3.1 over to master).

Long version (for folks who are interested):

GCC 4 appears to behave differently with functions and register allocations depending on whether or not a function is a "leaf function" aka, doesn't call any other functions. For the atmega32u4, the showRGBInternal function in the heart of the avr clockless code is such a leaf function (yes, there are function calls in there, but they're all marked always inline, so they end up in the internals of the function as well). This allows use of the full set of registers.

For functions that aren't leaf functions, gcc appears to try to minimize the number of registers a function uses, to allow called functions to use registers and minimize time spent saving/loading registers (roughly).

So, how do this affect the ATTiny? Well, the ATTiny85 has no hardware multiply opcode, and one of the functions that showRGBInternall 'calls' (to be inlined) has a multiply operation in it. Since the ATTiny85 has no multiply opcode, this turns into a call to a function. Et. voila! showRGBInternal is no longer a leaf function and now gcc starts inserting a whole bunch of unnecessary register move instructions interleaved with my code to try to re-use registers aggressively.

The fix is to replace that call for attinys with an unrolled version of scale8 that doesn't use any multiplies.