Hi guys have been playing around with fastled v2 and have been loving it.Downloaded

Hi guys have been playing around with fastled v2 and have been loving it.Downloaded v2.1 to try out some of the new examples of the color pallet functions but when i change libraries from 2 to 2.1 Red is not displayed properly it comes out more of an orange color. The 2 pics show the RGB calibrate example running on the same Leds ws2811 running on a arduino uno.Also some times the squares that should be black or unlit light up green. If anyone has any ideas what i am doing wrong i would be gratefully for any help given.

Weird - one of my dev platforms is a neopixel shield running on an arduino - and i haven’t seen color things like this. Squares that shouldn’t be lit up getting lit up green though speaks to a timing issue of some kind. Though, again, not entirely sure why you’d be seeing that.

How many leds do you have hooked up - and how do you have the power and such arranged?

2.1 is a lot tighter on its timing, sometimes for better, sometimes it means that things are a little less tolerant of wiring/power issues.

Your photos show 1Green, 2Red, and 3Blue. Doesn’t that mean the RGB ordering should be switched? Or did you already do that?

In your void setup( ) section,
from … RGB>(leds, NUM_LEDS);
to … GRB>(leds, NUM_LEDS);

hi i have 64 leds connected in my matrix which are supplied form a separate 2 Amp switch mode psu with the grounds common on the arduino board

Where’d you order the pixels from? (And when - early runs of WS2811’s had conflicting information about what the timing was supposed to be - I’m wondering if you have chips that aren’t happy with timing that’s more in line with the WS2812)

Got them om Ebay from a seller called transnova they came mount on a small round breakout board for soldering to.Only got them last month. sorry they are ws2812Bs. Is there anything easy i can tweak in the fastled library to adjust the timing as iam not an expert at programming Thanks.

Not as much with the arduino - in part because it’s hand spaced assembly in the 2.1 library (had to be, to make dithering work at 8/16Mhz).

What version of the arduino software are you using to build/upload the code?

I’m not seeing behavior like this with my arduino uno and WS2812B’s here.

Running 1.5.7 on a Linux mint machine

Have ordered an arduino mega just waiting on it coming I will try it with fastled 2.1 when it arrives

Ah - 1.5.7 made a major change to the compiler that may be messing with the assembler output - I haven’t had a chance to do a full round of testing with it.

Try going back to 1.5.6 or 1.5.5 - http://arduino.cc/en/Main/OldSoftwareReleases - and/or go back to 1.0.5.

It’s going to be a bit before I can look into what got screwed up with 1.5.7 (they went from GCC 4.4.1, released in 2009 and jumped right to 4.8.1, released in 2013 - a lot of changes in between those two versions).

The mega is also a 16Mhz avr, and uses the same code as the uno - if the gcc 4.8.1 compiler in arduino 1.5.7 beta is causing a problem on the uno, it will likely cause a similar problem on the mega.

Ok thanks for your help I will try that later when I get home and let you know how I get on .

I’ve had several issues pop up with the 1.5.x version of the IDE, which is why I stick to the 1.0.x versions. One particular bug that bit me was a missing interrupt on the 32U4 bootloaders. It’s there in 1.0.x but not in 1.5.x … took me days to figure that part out. Sequences that work fine in 1.0.x also broke in 1.5.x due to the compiler change. So yeah, I personally stick to the 1.0.x version and only use 1.5.x for the more exotic (read: newer) boards that are coming out.

Yeah - I had someone report an issue with 1.5.7 earlier, and it turned out that the compiler was severely messing with the assembler output and messing up the timing. Fixing it is going to be a fair bit of work.

Hi Daniel went back to version 1.0.5 and now everything seems to work fine thanks again for a great library and your time

sigh Another 1.5.x “issue” …

In this case, it’s less an arduino/arduino library issue and more a gcc issue.

For some reason, GCC is seeing fit to re-order all of the carefully placed asm statements for driving WS2811’s (along with the interleaving of dithering/scaling/color correction that i have going on in there), as well as being hyper-conservative on register usage.

I haven’t yet had a chance to dig into changes in how gcc handles asm statements to try to figure out how to work around this shit.