Hi all.  First off I'm loving using the library with a chain of WS2801

Archive FastLED Archive
1

Hi all. First off I’m loving using the library with a chain of WS2801 LED’s (100). I have all the examples working well with my Mega 2560.
The next step I need to make is play music whilst showing some LED animations.
In order to do this I’ve got an adafruit WaveShield - I’ve got the example code working for this too so now it’s time to bring the 2 pieces together.
As the WaveShield uses hardware SPI (a lot of this is new to be so I’m trying to learn a lot) I’ve set different CLK/DATA pins for the LEDs - 31 and 30 respectively on the Mega (I guess this means I’m using software SPI i.e. bit banging?)
Things are working fine though and I have a sketch where I can light LED’s and then play music.
But the real trick is to play music at the same time as writing colours to the LEDs. The WaveShield works on an interupt which allows me to do this:

while (wave.isplaying) {
//do stuff e.g. light some led’s
}

but this is where my problem starts - I get crazy flickering when I try to set some colours on the LED’s in this loop…even if I try to set one LED at a time, along the chain, things don’t seem to go as expected - some LEDs will light and then others will flicker…

Here’s my LED setup:

FastSPI_LED.setBrightness(64);
FastSPI_LED.addLeds<WS2801, 30, 31, RGB, DATA_RATE_MHZ(1)>(leds, NUM_LEDS);

And here’s my wave.isplaying loop:

    boolean showLED = false;
    while (wave.isplaying) {// playing occurs in interrupts, so we print dots in realtime
        //First time in light the lights
        if(!showLED) one_color_all(255,0,255);
        showLED = true;
    }

Any ideas? Is it something do do with SPI or is it do with the frequency of the interupt vs rate at which data is sent to the LED’s??
I’ve really no idea but if anyone has any ideas i’d be most grateful.

Thanks in advance for any help!

2

When doing software spi there are some assumptions the library makes assuming there aren’t other interrupts running. In the first light example there’s a commented out #define for telling the library that interrupts are active (this define needs to be before the include) Note - your interrupt has to run quickly, however. I think you have something like 24-150us before the ws2801s will reset and start listening for new data.

3

Ok - now that I have code, I realized this reference isn’t n the first light code - you need to put the following line:

#define FAST_SPI_INTERRUPTS_WRITE_PINS

before any of the #include statements.

4

Many thanks for getting back Daniel. Adding:
#define FAST_SPI_INTERRUPTS_WRITE_PINS 1
right at the start of the sketch (1st line) certainly helps.

When I try to alternate between setting the strip all pink and all cyan whilst playing music I get some flicker between the transitions but I don’t get the total madness that I was seeing.

My code is now as follows:

while (wave.isplaying) {// playing occurs
if(!pink) {
one_color_all(255,0,255);
pink = true;
} else {
one_color_all(0,255,255);
pink = false;
}
delay(2000);
}
sdErrorCheck(); // everything OK?
}
}
}
}

void one_color_all(int cred, int cgrn, int cblu) { //-SET ALL LEDS TO ONE COLOR
for(int i = 0 ; i < NUM_LEDS; i++ ) {
set_color_led(i, cred, cgrn, cblu);
FastSPI_LED.show();
delay(1);
}
}

As I said there’s flicker between the transitions.

If I change one_color_all so that FastSPI_LED.show(); is called after the array of LED’s is populated I get no flicker but still some random colours on the strip…is this because data is only getting partially written to the strip before the interupt kicks in again?

I should point out that the one_color_all code is from Thomas Eldredge (thanks Thomas - I owe you a beer :slight_smile: ).
I was hoping to use some of his nice animations whilst playing music but perhaps this will be pushing things a bit?

Thanks again for your help.

5

Yup - the interrupt is probably causing the ws2801’s to reset. For a post 2.0 release of the code i’m bouncing around some thoughts on detecting if an interrupt has fired, and if it has, stopping writing early, rather than potentially writing out mis-timed/corrupted data. I’ll try to think about other ways to work around this. Playing nicely with/around interrupts is a challenge. (One reason I can’t wait to play more with the beagle board - where I can push led data out from a dedicated sub-processor core, with no interrupting from what the main processor is doing! :slight_smile:

Also - this is why I want to spend some time exploring options for writing data out using DMA options on systems (Due, teensy3) that have it.

6

OK cool - sounds interesting. I’ll keep my eye out for the code update. In the meantime I’ll just workaround the problem by playing shorter sound clips and animating LED’s either side - should be fine.
When I’m done I’ll also post the result of my project here in case anyone’s interested.
Thanks for all the help Daniel - looks like i owe you a beer too! Very good work sir!