Folks, I have some trouble with a Atmega32u4 breakout board (Leonardo-ish),

fastled-support
gplus
(Maarten Stevens) #1

Folks, I have some trouble with a Atmega32u4 breakout board (Leonardo-ish), and a combination of a WS2801 strip (22 leds) and Neopixel strip (120 leds).

Previously, I only had the 22 WS2801 running in a program based on the Fastled demo, no problem. Added some buttons, etc.

Yesterday, I hooked up the additional 120 leds of the Neopixel strip (WS2811 or 2812b, not yet sure). I address them as WS2811 anyway.

Now the whole program is extremely slow (refreshing every 1-2 seconds or so), and eventually freezes altogether to the point that I can’t address via USB anymore until I unplug and replug.

Any similar symptoms? No idea what causes this…

(Daniel Garcia) #2

What version of the library are you using? What version of the arduino software are you using? What program are you running - can you upload the code for it?

(Daniel Garcia) #3

(removed the duplicate post)

(Maarten Stevens) #4

Fastled library updated to 3.0.3 - didn’t solve
Arduino - 2013 version, need to look that up when I get home

The program is a bit too long to upload. Essentially I am running the demo for the ‘circle’ and each of the graphic modes is slow.

(Daniel Garcia) #5

Your problem is very likely somewhere in the code most likely - please upload the code somewhere so I can take a look at it. 120 leds of neopixels only take 3.6ms to write out. Even 22 ws2801’s only take another 0.5ms - so that’s only 4.1ms/frame to write out the led data, which points to a problem elsewhere in your code. Unfortunately, “running the demo for the circle” doesn’t give enough of a frame of reference for what is going on in your code and I’m not a mind reader :slight_smile: (Which is why i generally prefer code, usually I can spot problems in it pretty quickly - also, it makes it more likely that I can try to re-create your setup here to better dig into what’s going on).

(Maarten Stevens) #6

Sure, will upload once I get home tonight. Probably will try myself as well… you indicate its in the ‘graphics code’ and not so much in the communication with the strips or hardware compatibility (ie. combining two strips).

Just to note, before I hooked up the additional WS2811 strip, everything was smooth and fast.

(Daniel Garcia) #7

Yup, meaning you’re animating 7 times as many leds, and if you have anything in the animation that’s especially inefficient (e.g. something that’s O(n^2) (aka 49 times as long) or worse) that could completely destroy your rendering time.

(Maarten Stevens) #8

I thought, since there is a complete freeze, there would be something different than just longer rendering time…

(Daniel Garcia) #9

You also said things like “Added some buttons, etc.” - which all basically means, until I see your code, I can’t really speak to anything you may be doing anywhere in it - which, again, is why I asked you to upload the code.

Also, there may be other issues - maybe your code is using memory badly and you’re running out of memory.

Perhaps there’s a buffer overflow somewhere where you are writing outside of the valid address range.

Etc…

(Maarten Stevens) #10

figured out the culprit… indeed it seems that addressing 142 leds is too much for a fast response. Addressing all leds through the ‘one_color_all’ function visibly delays all functions that use that functions. It also freezes after calling the function…

As my two led strips have different lengths, I have defined LED_COUNT=0 and LED_COUNT2=120.

void one_color_all(int cred, int cgrn, int cblu) { //-SET ALL LEDS TO ONE COLOR

for(int i = 0 ; i < LED_COUNT; i++ ) {
  leds[0][i].setRGB( cred, cgrn, cblu);
  delay(1);
}
  for(int i = 0 ; i < LED_COUNT2; i++ ) {
  leds[1][i].setRGB( cred, cgrn, cblu);
  delay(1);
}  

}

(Daniel Garcia) #11

You don’t need the delay after calling setRgb either.

(Daniel Garcia) #12

also - what does the definition of your leds array look like - it is possible that you have a buffer overflow in here which will screw up the call stack and send your code shooting off into nowhere (which would look like a freeze).

(Maarten Stevens) #13

#define LED_COUNT 22 //22 leds in the first strip
#define LED_DT 2 //SERIAL DATA PIN
#define LED_CK 1 //SERIAL CLOCK PIN
#define LEDSTRIP2PIN 7 //pin for second led strip
#define NUM_STRIPS 2 //two led strips
#define LED_COUNT2 120 //120 leds in the second strip

FastLED.addLeds<WS2801, LED_CK, LED_DT, RBG, DATA_RATE_MHZ(1)>(leds[0], 22);

FastLED.addLeds<WS2812B, LEDSTRIP2PIN>(leds[1], 120);

(Maarten Stevens) #14

example of code that flashes white (all good) and then goes to red and freezes (USB inaccessible).

void flashwhite() { //m13
long static timecounter;
if(c>1){c=0;}

if(millis()<timecounter){timecounter=0;}

switch©{

case 0: //all white
one_color_all(255,255,255);
break;

case 1: //all off
one_color_all(0,0,0);
break;

}

if(millis()>timecounter+(thisdelay*16)){c=c+1;timecounter=millis();}
FastLED.show();
delay(thisdelay);
}

(Daniel Garcia) #15

So - this is why I ask people to post their entire program - because when you pick and chose what parts to post, often you are not actually posting pieces that point to where the problem might be getting caused. Even if I make specific comments, what you have pasted so far actually has little to do with them. If you want me to address why things might be slow/not working right in your code, I’m done with this dance until you post the entire program (to either http://pastebin.com or http://gist.github.com - NOT in a comment here, g+ is terrible for going through large blocks of code).

Also - there’s something to be said for accuracy in comments when initially reporting a problem/issue:

“then goes to red and freezes (USB inaccessible).”

In addition to the problems you have in your code with making things slow - this comment tells me that you are drawing too much power - enough that you can’t actually drive the leds anymore (red leds take the least amount of power, so when everything is starved for power, they often still manage to come on) and there isn’t even enough power/draw to drive the UNO anymore. 120 WS2811 leds at full power (aka full white) will draw 36 watts or 7.2 amps. Your typical USB port only supplies somewhere between 0.5 and 2.1 amps at best. You need more power to solve the hanging problem, then you can go back and address the “why is it slow” issues.

(Daniel Garcia) #16

I don’t know why you deleted the last comment you made on here, that was actually part of what I was looking for - when you had

"I’ve defined it as follows:
struct CRGB leds[NUM_STRIPS][LED_COUNT];

Since LED_COUNT=22, and the above function uses LED_COUNT2 = 120, it looks like this is the problem."

yes, you were absolutely overflowing leds - and this is the kind of thing that would’ve taken me about 15 seconds to spot if you had uploaded the code initially when I asked, the first time.

There’s a couple of ways to fix this. One is the way you looked at, having two separate leds arrays:

CRGB leds1[LED_COUNT];
CRGB leds2[LED_COUNT2];

The other is to have one array with all of them:

CRGB leds[LED_COUNT + LED_COUNT2];

in that case, you would change your addLeds lines to:

LEDS.addLeds<WS2801,LED_CK,LED_DT>(leds,LED_COUNT);
LEDS.addLeds<WS2811,LED_PIN>(leds + LED_COUNT, LED_COUNT2);

Which basically says “The first LED_COUNT leds are for the WS2801 and the next LED_COUNT2 leds are for the WS2811.”

If you want an array of arrays, you can do:

CRGB leds[NUM_STRIPS][LED_COUNT2];

this will waste some memory, as if leds[0] is for the WS2801, obviously anything you write to leds[0] after leds[0][LED_COUNT-1] will be ignored. However, that would completely take care of the overflow issues you were having.

(Maarten Stevens) #17

Hi Daniel, thanks very much for your time and help, much appreciated!

The reason I had deleted the last comment, was that I had been working exactly towards the solutions that you propose, only to find that it still didn’t work.

All solutions still lead to the dreaded freeze. The 3rd way (array of arrays with LED_COUNT=120) only makes it freeze up after a couple of flashes white, ie. not immediately after going to all black. So something is still wrong… still looking for it…

(Daniel Garcia) #18

You have multiple sets of problems in this setup, both code (the overflows in your led arrays) as well as power. By testing with all the leds going white you are very likely running out of power - see my previous comment on this - once the leds are trying to drive too much power it will starve your Arduino for power and keep it from running.

(Maarten Stevens) #19

Daniel, thank! Power issue was the problem.
I can run it on max_brightness of 1/4, or on a 18650 at full brightness no problem.

Thanks very much