Four words, "global brightness for free".

Four words, “global brightness for free”. Or how about “Here’s Release Candidate 1”
http://waitingforbigo.com/2013/05/31/fastspi_led2_release_candidate/

You did this on purpose, didn’t you? Now that I’m going to bed … Some people, no consideration for others wanting to play but needing to sleep. :slight_smile:

Hey, the sun is coming up where I’m at now, though, to be fair, I was hoping that it would be more of a morning surprise for people :slight_smile:

It’s only 2:45am here … So yeah, I’m off to bed. Thanks for posting it though. I’ll start playing with it later today.

I just swapped it it this morning. So far it’s been seamless. Being able to rely on millis() again is a joy! I’m also using multiple (7) strands so little things like being able to create and play() them is nice. Now I’m beginning to start digging around to see what else is in there.

Ok, so how does one set multiple strings on different pins now? With the previous release, I was doing

WS2801Controller<11, 13, 10, 16> LED1;
WS2801Controller<7, 9, 6, 64> LED2;
WS2801Controller<5, 8, 4, 64> LED3;
WS2801Controller<A5, 3, 2, 64> LED4;

With the new release, I’m seeing

LEDS.addLeds<WS2801, 11, 13, …

Changing that to LEDS1.addLeds… LEDS2.addLeds … etc.,

results in undeclared errors for LEDS1, LEDS2, etc., etc … So yeah, I’m missing something here.

That’s because LEDS is a single master controller that you add an arbitrary (well, up to 8-10 for now - there’s a memory management issue I want to deal with before allowing more, first).

#define NUM_LEDS_PER_STRIP 75
CRGB leds1[NUM_LEDS];
CRGB leds2[NUM_LEDS];
setup() {
LEDS.addLeds<WS2801, 11, 13>(leds1, NUM_LEDS);
LEDS.addLeds<WS2801, 9, 6>(leds2, NUM_LEDS);
}

… LEDS.show(); …

will do a show on all the strips together.

You could also just do one array

#define NUM_LEDS_PER_STRIP 75
CRGB leds[NUM_LEDS_PER_STRIP * 2];
setup() {
// set up the first controller on led 0 for NUM_LEDS_PER_STRIP leds
LEDS.addLeds(leds, 0, NUM_LEDS_PER_STRIP);
// set up the second controller on led NUM_LEDS_PER_STRIP for NLPS
LEDS.addLeds<WS2801, 9, 6>(leds, NUM_LEDS_PER_STRIP, NUM_LEDS_PER_STRIP)
}

basically, that second form of addLeds takes an array of leds, an offset into that array, and a count of leds in the array for that controller to write to.

No need for ‘struct CRGB leds1[NUM_LEDS];’ anymore? I can omit the ‘struct’?

Yup. Fewer letters for you to type :slight_smile:

Yee-to-the-hah. POV code no longer works. :slight_smile: Time to start rewriting from scratch I guess. :slight_smile:

Which part of it isn’t working?

It works on a single string, but the staggered code fails miserably. One string does what it’s supposed to, the other just becomes a n all white flashing frenzy. Let me try something here …

All white flashing frenzy is often a sign of having clock/data wired backwards, at least for me

… and yet it works with the old library?

Can you show me the addLed lines you’re using?

Ok, this fails. The leds1 string works as expected, leds2 string is just flashing white. And yes I did already try to flip the connections - it won’t work at all if the connections are reversed.

#include “FastSPI_LED2.h”
#define NUM_LEDS 32

struct CRGB leds1[NUM_LEDS];
struct CRGB leds2[NUM_LEDS];

void setup() {
delay(2000);
LEDS.setBrightness(64);

LEDS.addLeds<WS2801, 5, 8, BGR>(leds1, NUM_LEDS);
LEDS.addLeds<WS2801, A5, 3, BGR>(leds2, NUM_LEDS);

// Also tried adding the DATA_RATE_MHZ(1) option, same result.
}

void loop() {
for(int i = 0; i < 3; i++) {
for(int iLed = 0; iLed < NUM_LEDS; iLed++) {
memset(leds1, 0, NUM_LEDS * sizeof(struct CRGB));
memset(leds2, 0, NUM_LEDS * sizeof(struct CRGB));

  switch(i) {
    // You can access the rgb values by field r, g, b
  case 0:
    leds1[iLed].r = 128;
    leds2[iLed].r = 128;
    break;

    // or by indexing into the led (r==0, g==1, b==2)
  case 1:
    leds1[iLed][i] = 128;
    leds2[iLed][i] = 128;
    break;

    // or by setting the rgb values for the pixel all at once
  case 2:
    leds1[iLed] = CRGB(0, 0, 128);
    leds2[iLed] = CRGB(0, 0, 128);
    break;
  }

  // and now, show your led array!
  LEDS.show();
  delay(10);
}

}
}

Ok, I feel dumb now … I figured it out. Remember in the previous release there was an issue with the analog pins not being what they should be … Yeah. I’ll just leave you with that. :slight_smile:

Ah! Are the analog pins lined up right, now?

Yep, looks that way.

DATA_RATE_MHZ() min and max are … ?