FastLED 3.1, Arduino IDE 1.0.6, Arduino MEGA2560, and NEOPIXELS are yielding an error.

fastled-support
gplus
(Jon Burroughs) #1

FastLED 3.1, Arduino IDE 1.0.6, Arduino MEGA2560, and NEOPIXELS are yielding an error. It appears that the Green channel is stuck ‘on’. At first I thought it was a bad LED, so after grabbing one that is confirmed to work, I still get the same effect. CRGB::Black is green, but CRGB::Red is red+green. The exact code runs perfect on an Arduino Micro.

(Jon Burroughs) #2

FastLED 3.0 is operating as expected. No issues on the Green channel.

(Daniel Garcia) #3

What pin are you using on the Mega? I suspect this may be related to a combination of pin access timing costs and the interrupt handling code (which 3.0 doesn’t have).

(Jon Burroughs) #4

Pin 8 for the LEDs, hardware SPI for the radio (ce 9, cs 10).

(Jon Burroughs) #5

Oh, and another weird tid-bit. It seems that my millis() is running faster than expected on the MEGA, both actually, 1280 and 2560.

Last night, I had code to just flash the LED on pin 13, without blocking delay. The interval of flashing was 1000. On a Micro, it operated as expected, but on the MEGA’s it was almost 4x faster…what and why is this happening?

(Daniel Garcia) #6

I bet the Mega’s timer is setup differently than the micro for counting millis.

(Jon Burroughs) #7

@Daniel_Garcia I have researched the web with no avail as to why my millis() timer is almost 4x fast than that of a Micro. I can’t find any documentation that would explain this. I have tried searching for the arduino.h and cpp files to start looking, however my noob-ness is holding me back on finding the file itself.

Anyways, regarding the ‘green’ channel error, did you happen to find an explanation for this?

(Daniel Garcia) #8

That’s because on the 3.1 branch - FastLED is managing the millis timer (in wiring.c) and I suspect something is done differently on the mega for setting up/managing the timer that I’m not accounting for yet.

I haven’t had a chance to investigate this on the mega yet (I’m still not 100% sure where mine is, but I’m pretty sure it is around here somewhere).

(Robert Atkins) #9

That’s interesting, because I updated the code on the gf’s 36x18 WS2812B panel to FastLED 3.1 and had the same result. Using pin 9 on a Yún (so a Leonardo for all intensive porpoises.) Thought I might have run out of RAM or something but ran out of time to investigate.

(Daniel Garcia) #10

You’re using 2k of ram just for LED data, you may be running out of memory :slight_smile:

Honestly I think I’m just going to roll back the interrupt handling code on avr - ~100 cycles is too few for most people to write interrupt handlers for and trying to continue to support it is going to cause more problems than it solves.

(Robert Atkins) #11

What are you talking about, I have a whole 832 bytes to play with on the Leonardo’s 32u4 :slight_smile:

(Daniel Garcia) #12

More like 556 bytes (36183 == 1944 - the 32u4 has 2.5k ram) - and that’s not including runtime ram that’s used by the rest of the library, or any other ram used by everything else that you are doing (like, say, your call stack :slight_smile:

(Jon Burroughs) #13

@Daniel_Garcia I think I have the millis() issue figured out, and it’s not my fault…this time.

I have working with a NRF24 network, using the Mirf library. One the receivers, there is a single Neopixel for visual feedback to ensure the correct animation mode was sent. So, NUM_LEDS = 1;

On the Micro and the Mega2560, I started experiencing a faster than normal millis() increment when using this:
void blink_() {
unsigned long currentMillis = millis();
if(currentMillis - previousMillis >= 1000) {
previousMillis = currentMillis;
if (ledState == LOW){ ledState = HIGH; leds[0] = CRGB::Blue; }
else { ledState = LOW; leds[0] = CRGB::Black; }
}
}

The math is always correct when I serial.print() currentMillis and previousMillis . Except that the visual feedback of the LED is not correct with real-time. 1000 millis increments is not equal to ~1 second.

So, changing the NUM_LEDS has an effect on the passing of time according to the millis() timer. 100 leds is close to 1 second intervals, but you can clearly see the lag on the Arduino after a minute. 255 leds causes time to go by too slow. 1 led causes time to speed by at almost 3x too fast.

(Jon Burroughs) #14

@Mark_Kriegsman Can you look at my post above? How can I diagnose this better?

(Mark Kriegsman) #15

I’m with @Daniel_Garcia on this one: I think we need to try to recreate it on an actual Mega and see what’s up. Have you tried it with the older v2.x version of FastLED?

(Jon Burroughs) #16

Well, I don’t have an archive of the old library. But, I guess my point was unclear in the above post. I was able to recreate the effect of BOTH the Micro and Mega today. The millis() problem seems to be global for me, no matter what platform I use.

(Daniel Garcia) #17

Again, for a variety of reasons, I’m disabling (by default) the interrupt allowing code on AVR and removing the FastLED custom version of wiring. The library, for avr should go back to a rough approximation of time passed and manually upping the millis counter (which is going to have its own levels of loss - but hey at least I attempt to account for it :slight_smile:

This change was checked in on 3.1 last night.

(Mark Kriegsman) #18

Old versions are available on github, I believe.

(Jon Burroughs) #19

OK, the newest pull of 3.1 fixes the issue.

(Mark Kriegsman) #20

Thanks for the report; glad you’re up and going.