It seems that the code in Adafruit_NeoPixel.cpp may be dependent on compiles options

[bogado]

When compiling using platformio that allows you to tweak the compiler options it seems that the compilation breaks if the -Os is not used. It seems that the assembler code on lines 959 and 588 both end up in the linking stage.

This happens when I remove the -Os and add -O2 to the compilation on avr-gcc tool chain that is distributed with platformio, at this moment this is avr-gcc (GCC) 4.9.2.

$ platformio -f -c vim run --verbose | tail -n -1
/tmp/ccYgbgRp.s: Assembler messages:
/tmp/ccYgbgRp.s:1523: Error: symbol `head20' is already defined
/tmp/ccYgbgRp.s:1538: Error: symbol `nextbyte20' is already defined
/tmp/ccYgbgRp.s:1583: Error: symbol `head40' is already defined
/tmp/ccYgbgRp.s:1608: Error: symbol `nextbyte40' is already defined
lto-wrapper: avr-g++ returned 1 exit status
/home/bogado/.platformio/packages/toolchain-atmelavr/bin/../lib/gcc/avr/4.9.2/../../../../avr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
*** [.pioenvs/protrinket5/firmware.elf] Error 1
============================================== [ERROR] Took 0.69 seconds ==============================================
Environment protrinket5	[ERROR]
============================================== [ERROR] Took 1.42 seconds ==============================================
Environment huzzah     	[SUCCESS]

The same code compiles fine with the huzzah esp8266 toolchain for the feather huzzah8266, even when using just the -O2 flag.

[ladyada]

probably! we use arduino IDE - for other IDEs there may be differences. if you can submit a non-breaking PR for a platform.io fix, that would be awesome!

[Laserdance100]

I just ran into this issue. This might be closed, but it is NOT solved. I'm actually having it with Arduino IDE but that is in fact GCC related.

This is fairely straight fwd. At high optimisation level, it copy part of the assambly functions used to make the impulsions for writing on the leds several times, and it copy the labels head20, nextbyte20, head40 and nextbyte40 several times, hence the error.

To avoid this, one has to use the notation %= of GCC, which will render all copied labels unique.
I'll make the PR.

I had a speckled colors issue, while doing a text scroll from right to left on a 5x8 RGBDuino shield, a step each 100ms. When the pixel were updated the "on pixels" did merge together for a while that was very perceptible. Adding a 10ms "all black" instant before each left shift didn't help. Using -O3 on the whole project completely solved the issue.

Here are some pictures, courtesy of my fairphone2 crap camera, rolling shutter effect included:

In fact it was less worse than in those images. I could only see that the very inner part of the pixel (not the full pixel like below) was still emitting with a very reduced brightness. But it felt like the text was letting leftover sparks while moving. Which was quite undesirable.