Number of LEDs limited to < 86

[AnthonyJQQ]

Did not work with Prismatik on my Mac- apparently, something must be causing an issue with serial coms. This sketch worked however:
'// Uses Adalight protocol and is compatible with Boblight, Prismatik etc
// "Magic Word" for synchronisation is 'Ada' followed by LED High, Low and Checksum
//
#include <FastLED.h>

///// User definitions /////

// Define the number of LED Controllers
#define NUM_LEDS 135

// Define SPI Pin
#define DATA_PIN 4

// Baudrate, higher rate allows faster refresh rate and more LEDs (defined in /etc/boblight.conf)
#define serialRate 115200

// Adalight sends a "Magic Word" (defined in /etc/boblight.conf) before sending the pixel data
uint8_t prefix[] = {'A', 'd', 'a'}, hi, lo, chk, i;

// initialise LED-array
CRGB leds[NUM_LEDS];

void setup()
{

// Uncomment one of the following lines for your leds arrangement.
// FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);

  // FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
  // FastLED.addLeds<SM16716, RGB>(leds, NUM_LEDS);
  // FastLED.addLeds<LPD8806, RGB>(leds, NUM_LEDS);

  // FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
  // FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
  // FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);

// initial RGB flash
LEDS.showColor(CRGB(255, 0, 0));
delay(500);
LEDS.showColor(CRGB(0, 255, 0));
delay(500);
LEDS.showColor(CRGB(0, 0, 255));
delay(500);
LEDS.showColor(CRGB(0, 0, 0));

Serial.begin(serialRate);
Serial.print("Ada\n"); // Send "Magic Word" string to host

}

void loop() {
// wait for first byte of Magic Word
for(i = 0; i < sizeof prefix; ++i) {
waitLoop: while (!Serial.available()) ;;
// Check next byte in Magic Word
if(prefix[i] == Serial.read()) continue;
// otherwise, start over
i = 0;
goto waitLoop;
}

// Hi, Lo, Checksum

while (!Serial.available()) ;;
hi=Serial.read();
while (!Serial.available()) ;;
lo=Serial.read();
while (!Serial.available()) ;;
chk=Serial.read();

// if checksum does not match go back to wait
if (chk != (hi ^ lo ^ 0x55))
{
i=0;
goto waitLoop;
}

memset(leds, 0, NUM_LEDS * sizeof(struct CRGB));
// read the transmission data and set LED values
for (uint8_t i = 0; i < NUM_LEDS; i++) {
byte r, g, b;
while(!Serial.available());
r = Serial.read();
while(!Serial.available());
g = Serial.read();
while(!Serial.available());
b = Serial.read();

//Change Variables to match output if strand is mismatched or try changing order of rgb in controller definition at top

// LED variables r and g swapped to match output of my LED strip-AJ
leds[i].r = g;
leds[i].g = r;
leds[i].b = b;
}
// shows new values
FastLED.show();
}`

Just make sure to uncomment the LED type that you are using.

[dmadison]

Could you clarify what you mean by 'did not work'? Does the sketch compile?

[AnthonyJQQ]

Sure, sorry for being vague. It compiles just fine, but there is no control via Prismatik using your source code. The LED strip just did not emit any colors using your code. Loading the above code and compiling it worked great, with the LED controllable right away. I used the same port, same Arduino, and same computer when using your code vs the one here.. I uploaded the above code so that you could compare them to try and find the error. I am running Mac OSX Sierra 10.12.4 and Prismatik software 5.11.2 (revision 46ca39e )

[dmadison]

Strange... the two memset() calls seem to break the code if the number of bytes in the LED array is greater than 255. I'll need to look into this a little more.

[AnthonyJQQ]

Why not try to remove the timeout section of your code (lines 180-185)?

[dmadison]

Try the latest version on the development branch, see if that works for you.

[dmadison]

That commit appears to solve the issue, at least on my setup. I'm still not sure why it was happening, though. As far as I see the behavior of the mode variable shouldn't change with the keyword, because the program never exits that function. It must be because flagging it explicitly as static changes its place in memory (moving the variable to global also fixes the issue), though I don't see where a memory error could occur.

If anyone knows for sure why this is happening using version 1.1.0, please let me know.

The commit is included in the latest release. If you could test it when you get a chance and report back, I would appreciate it. In the meantime I'm going to close this issue as solved. Feel free to re-open it if you're still having trouble.