Okay, what gives … The following code does not run:
#include <avr/delay.h>
#include “FastSPI_LED2.h”
#define NUM_LEDS 48
CRGB leds1[NUM_LEDS];
//CRGB leds2[NUM_LEDS];
#define Rmask 0x60
#define Gmask 0x18
#define Bmask 0x06
void setup() {
LEDS.addLeds<WS2801, 11, 13, BGR>(leds1, NUM_LEDS);
// LEDS.addLeds<WS2801, 7, 9, BGR>(leds2, NUM_LEDS);
}
#include “patterns.h”;
void loop() {
uint16_t i,j,k;
#ifdef PATTERN4
for (k=0; k < REPEAT4; k++){
for (j=0; j < (sizeof(image4) / (sizeof(prog_uchar) * NUM_LEDS)); j++) {
for (i=0; i <= NUM_LEDS; i++) {
unsigned char cur = (uint32_t)(pgm_read_byte_near(&image4[i+j*NUM_LEDS]));
unsigned char r = cur & Rmask;
unsigned char g = (cur & Gmask) << 2;
unsigned char b = (cur & Bmask) << 4;
leds1[i] = CRGB(r, g, b);
}
LEDS.show();
_delay_us(STRETCH4);
}
_delay_ms(DELAY4);
}
#endif
}
However, if I comment out the definitions for leds2, it runs (and displays the pattern on leds1 as it should.) What gives?
I tried adding DATA_RATE_MHZ(2), no change.
Ok, I found out that all I need to do for it to work is uncomment the second Controller. I can leave it unused and the code runs, displaying data on the first string which is on the hardware SPI. If I comment it out, it stops working. No activity on the onboard LED (which is connected to the clock pin) … This is running on an Uno.
I’m discovering that the preview release has the same issue. If I just define one controller, regardless of what speed I give it (> 32), it doesn’t work. But if I define a second controller and initialize it but leave it unused, things work. It also doesn’t matter if I define it on the hardware SPI, or if it’s on a completely different set of pins.
All this time I’ve been working with multiple strings and didn’t even bother to try a single string … till now.
Weird - I do almost all my work with single strings and controllers!
I’m travelling/flying today so ill look into more later
Yeah, I’m going to scratch everything I have and just start over, see what
happens. The thing I realized is that since the day I switched to v2, I’ve
always had more than one controller defined, whether I was using it or
not. Last night was the first time I tried running it with a single
controller defined … and it didn’t work, SPI hardware or bitbang. But as
soon as I added a second controller, it works.
But yeah, I’m going to start over today with a clean slate, see if I messed
something up.
Also - you don’t need to explicitly define the pins for things that are hardware accelerated - LEDS.addLeds<WS2801, BGR>(leds, NUM_LEDS); - that will default to using the hardware SPI pins.
Yeah, that’s remnant of when I had multiple controllers defined and to
remind me that I am using the hardware SPI.
Ok, this is definitely something with this specific piece of code. I can run the test sketch on a single string, single controller just fine. But as soon as I put this code on, it doesn’t run. But if I define a second controller on different pins and just leave it unused, then it works.
I can’t figure out what’s going on.
I <= NUM_LEDS - that should be a < - you are probably over writing some block of memory that’s resulting in you getting hung before anything happens.
When you have the second controller and/LEDs, it probably shifts the memory layout enough that things don’t get busted noticeably.
Well, that somehow does fix it, however it raised even more questions: the original code has it as <= … and it works (though they run it on a AT90USB1286, whereas I’m running it on a ATMEGA328P …
It’s luck, basically. You are writing into memory that is not in the led array, also known as a buffer overflow - the source of many of the browser exploits in Internet explorer or flash, amongst others 
(automating finding things like this is part of my day job).
sigh That small issue, combined with the 328p on my Uno giving up the ghost is what has caused me several handful of hair plucked off of my head this morning. I was uploading new code to the Uno, and it was doing everything right during that process … except, it was still showing data that I put up last night. Once I replaced the 328p with a new one, now it works again.
Why must everything fail all at once? Sheesh.
I know the feeling, trust me. I blew out a teensy 3.0 the other night testing TM1829 code because a mistyped line turned all the leds to full brightness and the power draw caused things to go fried
That’s why I always power the strings externally, or separately from the µcontroller.
They were separately powered - 12v vs 5v, still went fried.
Yeehaw … filling all 32K of memory with stuff is fun … NOT. Time to offload the data to a microSD card and read stuff in that way. Woo.
Dan, how did full bright kill the Teensy? (This sounds like a pitfall I have not anticipated).