So I'm using FastLED 3.1, Arduino 1.6.5, and RFduino 1.7.2.

So I’m using FastLED 3.1, Arduino 1.6.5, and RFduino 1.7.2. I can get some demos working if I specify WS2811_400 as the chipset, though I get an assembler error on others.

I can get the XYmatrix demo working, however, as soon as I call RFduinoBLE.begin() I get zero LEDs lit up. I have tried using the while (RFduinoBLE.radioActive) loop before FastLED.show() as the RFduino docs and others have suggested.

I’ve also tried calling noInterrupts() before FastLED.show() and interrupts() after. I’ve tried it with and without RFduino_ULPDelay() and with various values.

I can include code later, but I’m just running the XYmatrix example sketch included with 3.1. I just changed the chipset to WS2811_400, included RFduinoBLE.h, and added RFduinoBLE.begin() in setup()

What demo gives you an assembler error?

I will double check when I get home, but I believe the Fire and Fire2012 demos give me that when I change the chipset to WS2811_400

I know I got the Cylon demo working as well.

Re-pull the 3.1 branch - I just checked in a couple of changes.

I will when I get home in a few hours. Thanks!

So the latest 3.1 branch makes the fire demo to work, though all of the lights end up bright white.
It makes the Cylon demo stutter for me though, and that was formerly working smoothly.
And when I create a program that is just a loop that fills all pixels with one color, it works the first time, lighting all LEDs, but on subsequent updates, it only changes colors about halfway through, but every 3rd or 4th hue change, it will update the entire string.
Here’s the code: #include <FastLED.h>

#define NUM_LEDS 280
#define DATA_PIN 6

CRGB leds[NUM_LEDS];

uint8_t hue = 0;

void setup() {
//pinMode(6, OUTPUT);
Serial.begin(9600);
Serial.println(“Started”);
FastLED.addLeds<WS2811_400, DATA_PIN, GRB>(leds, NUM_LEDS);
}

void loop() {
noInterrupts();
for(int i = 0; i < NUM_LEDS; i++){
leds[i] = CHSV(hue,255,32);
}

FastLED.show();
delay(100);
interrupts();
hue++;
hue %= 255;
//addmod8(hue,1,255);  //Tried this and kept returning 0?

}

And if you add the line:

#define FASTLED_ALLOW_INTERRUPTS 0

Before #include"FastLED" ?

Ah! Of course! Works beautifully now. Thanks! You have the patience of a saint, Daniel.

Any idea why addmod8 would always return 0 though?

Adding this in the loop gives me endless 0s:
addmod8(hue,1,255);
Serial.println(hue);

@kriegsman can probably better answer that - but that is also unnecessary if hue is an 8-bit value, it will always roll over on its own. (When you add 1 to an 8-bit variable that holds 255 it will wrap around to 0)

Yeah. I noticed that behavior when I accidentally forgot hue %= 255; That’s the default behavior for most microprocessors? It makes sense in terms of binary math, so I get it. Just curious. I’ve been working in Python for the last seven years. This is a refreshing change to say the least.

Oh, wait! addmod8 doesn’t modify it’s values. You need to be saying:

hue = addmod8(hue,1,255);

:slight_smile:

facepalm!