Interrupts are wieldly, and I was wondering if there was a snippet of code

Archive FastLED Archive
1

Interrupts are wieldly, and I was wondering if there was a snippet of code to adhoc stop fastled, and then restart again.

Obviously there would be visual clashes (random LEDs, pausing animations, blackout etc) but this might be more desirable than commands ignored, or weird data.

2

What do you mean “stop fastled, and then restart again”?

Note that on ARM platforms (as well as the ESP8266), while writing out 2812 data, many of them allow for a brief enabling of interrupts in between writing out each LED’s data - and if the interrupts take to long, it will attempt to re-write the frame once or twice. In the worst cases, this will show up as leds towards the end of the strip updating at a far lower frame rate.

This is simply not doable, at all, on AVR. Not enough clock cycles (combined with the ms timer firing an interrupt once every millisecond that always takes too long, meaning you can never write more than about 33 leds worth of data out before getting the frame cut off).

The problem is, it takes as little as 5µs for the WS2812 to latch and stop passing data through, and instead read data. So, if you’ve paused for more than 5µs for any reason, then the next bit of data that gets written out is going to go to the first led, not whatever led you were at when you paused.

If you’re going to do things that need interrupts - use an ARM based platform (preferably something faster like a teensy 3.x), or use LEDs that don’t require disabling interrupts (e.g. APA102). Or switch to using other components that don’t require interrupts to do their work.

3

Ack, fair enough. The Bluetooth is kinda taking with fastled and the atmel at the moment, but it responds maybe 1/3 times.

A pause / restart of animations wouldn’t be an issue to the product

Thanks though

4

Again - the problem on AVR is that the SYSTICK interrupt, which fires once per ms means that you wouldn’t ever be able to write out a strip longer than 33 ws2812 leds. It’s not about the timing of animations - it’s about actually writing out the led data. If you don’t mind frames occasionally being cut short (so the ends of your leds basically update at a lower frame rate) then switch to an arm based platform where this is supported (and it is supported because it is reasonable to do so at the hardware level, unlike on AVR)

5

i know that you’re gonna hate me… but i’ve found a “contractor” workaround!

whilst the leds i’m using are ws2812 (and i cant find any other versions (they’re a ring of 5050’s) and the bluetooth is pretty standard using interrupts, and i promise ill find a better microcontroller… :slight_smile:

but in my code;

bluetooth.listen();
while (bluetooth.available() > 0) {

dataLow();

char inChar = bluetooth.read();

  // if its a character, add it to the string
  if (isDigit(inChar)) {
    inString += (char)inChar;
  }

  // if the string is longer than 2, truncate and return nothing
  if(inString.length() > 2) {
    inString[2] = '\0';
  }

  // if the serial recieves bluetooth end of line /n print string data out
  if (inChar == '\n') {
    Serial.print("String: "); Serial.println(inString.toInt());
    program=inString.toInt();
    inString = "";

    dataHigh();

  }

}

and painfully,

void dataLow () {
// drop the power on the data pins for the leds
digitalWrite(DATA_PINA, LOW);
digitalWrite(DATA_PINB, LOW);
Serial.println(“DATA_PINS - LOW”);
}

void dataHigh () {
// turn the power back on for the leds
digitalWrite(DATA_PINA, HIGH);
digitalWrite(DATA_PINB, HIGH);
Serial.println(“DATA_PINS - HIGH”);
}

so i basically drop the power on the data pins for the leds strips… read the bluetooth data, process the data, re-enable the power to the data for the leds.

i know this isn’t brilliant, but in my small process (32 leds) its working quite decently.

most of the programs work (mostly low level addition of numbers to move a single led, most of the fades work, in fact, i think the only thing not working is (as explained before) the palette work).

:open_mouth: