Could it be that I’m experiencing interrupt conflicts with another library (IRremote)? I posted about this on stackoverflow (see link), and I’m still not sure how to fix it. Is it even possible that the conflicts are with FastLED? If so, can I change the source in a way to resolve these conflicts, e.g. by setting the interrupts to a different timer (I hope that makes sense, I’m new to interrupts)? Any help would be much appreciated 
http://stackoverflow.com/questions/27532208/arduino-irremote-library-weird-behavior
Dunno, but I did write a sketch just today that used FastLED and IR Remote and it worked great.
@Mike_Thornbury
I wish I could say the same. The weird thing is, there appears to be no problem with calling my takeAction() function, which also uses FastLED internally.
IRremote should work ok with 4 pin LED’s such as WS2801 or APA102. It will not work with 3 pin ones, such as WS2811’s or WS2812B’s. In addition, Nico Hood has a very nice IR library you might want to check out on Github.
I’m using 3-Pin WS2812B’s! So what exactly is the reason for it not working? And will Nico Hood’s library fix this? Thanks!
Dan Garcia can provide the best answer, but it’s basically that the WS2812B’s require very specific timing that cannot be interrupted because clock and data use the same pin. The 4 pin strands separate clock and data, so the timing is much more relaxed.
No, Nico’s IR library will not fix that, although it is a good library and smaller than Ken Shiriff’s. Furthermore, if I recall correctly, you should be using FastLED 3.1 latest branch and not 3.0.
The short version is that you can’t have these three things working all at once:
- WS2811/WS2812B leds,
- an AVR-based Arduino board, and
- code that uses interrupts.
And it’s not really a “FastLED” problem – it’s universal when you try to mix these three things. AVR boards just can’t relaistically process interrupts fast enough for the WS2811/WS2812B LEDs to keep working correctly. But if you change any of the three ingredients, things can start working.
If you still want to use WS2811/WS2812B LEDs, and you still want to use an interrupt-based library, then you need to switch to an ARM-based board, like the Teensy 3.1, Arduino Due, or Digispark DigiX. FastLED supports all of those boards.
You may be able to use both WS2812 LEDs and IRremote if you’re careful to ensure IRremote interrupts never runs during FastLED.show(), using something hacky like the below. It’s not optimal because you’re basically resorting to polling for IR:
IRrecv irrecv;
IRsend irsend;
void loop() {
irrecv.enableIRIn(); // setup timers for recv
delay(100); // wait for possible IR input
if (irrecv.decode(&results) {
// decode & use
}
irsend.enableIROut(); // disable ir recv interrupts
FastLED.show(); // drive WS2812s
}
You can pretty well kiss animation goodbye if you do that.
delay(100ms) == 1/10th sec == 10 FPS
So yeah, it might work most of the time, but the animation will be slow.
Idea:
- turn off IR-handling interrupts.
- Install a new custom ISR, triggered by IR signal change (can we do this?), that just sets a flag and returns.
- run animation full blast
- once per loop, check the flag
- if flag is set…
– turn OFF custom ISR,
– turn ON IR-reading ISR
– delay(500) or until IR value is read
– turn OFF IR-reading ISR
– turn ON custom ISR
Since IR remotes send the code repeatedly, you could use the first one just to throw the sketch into IR-reading mode, read the code, and then resume animating.
IR events would make the animation hiccup, but might otherwise work?
Bugger. I wanted to use the code I wrote with the surfeit of Pro Mini boards I’ve got lying around. I guess I will have to use two of them - one to act as a bridge for the remote and one to run FastLED. In one way it seems a waste, but in another, it makes porting IR easier, as I can relate the remote codes to anything I want and use existing routines written for Bluetooth, etc.
I wish there was a cheap non-8-bit avr board supported by FastLED that could replace my nanos and minis. I can’t afford to use ATTiny’s for everything… They cost a bomb to get here. I have a bunch of the little Leaf clones put out by Baite. Having FastLED on those would be ideal.
Wow guys, thanks for all the input! I’m doing this as a (paid) assignment for someone who already wired the entire LED-screen, bought the Arduino, etc… so it’s not that easy to just switch hardware. I’ll just fiddle around with it some more, maybe I can get it to work reasonably well using your suggestions. How difficult would it be to let another AVR chip, say an ATtiny, handle the IR and send the codes via a serial line to the Mega?
It could be done with a cheap $3 chinese Nano or Pro Mini. That’s what I am going to do. The inter-arduino traffic can be handled by software serial.
And from a ‘good form guide’ perspective, before asking for help for your paid job, it’s a good idea to mention that you are getting paid for us to solve your problem for you.
Haha sorry. It’s not a big commercial job. Just a favor in exchange for a really small amount. And from a ‘good form guide’ perspective, telling someone “Dunno, but it works fine here”, isn’t exactly helpful. Please speak for yourself. If the others who were actually helpful agree with him, I’m very sorry and I will take it into account next time I run into a problem like this.
The idea of using a second ‘coprocessor’ for the IR receiver is totally workable!
Good! I just bought a Mega328 to experiment with 
I think this is going to be my new one-line summary of this, amended as above:
“You can’t have WS2811s AND interrupt-driven libraries working together on a single AVR chip.”
Possible solutions, in rough order from easier to harder: change to ARM chip, add a separate IR ‘coprocessor’, change to different LEDs, use RF instead of IR, rethink the whole project.
The one other possible solution is cooler but trickier and definitely more exotic: use the TWO AVR chips present on every Arduino UNO (did you know that?!?) to do two different tasks! See https://github.com/NicoHood/HoodLoader2
Well, apart from that ‘quote’ not being what I said, it’s noted that you are so well supplied with people taking the time to look at your problem and offer guidance that you are in a position to disregard those that don’t meet your high standards.
If you look back, what I did say was that that very day, I had written a sketch that used IR remote and FastLED and didn’t encounter a problem, which would have been at least a pointer in the direction of a solution.
Sorry if that wasn’t a full enough solution to your problem, but I was recounting what I actually knew, rather than speculating from a position of insufficient knowledge.
As an FYI, I won’t bother in the future, so you can rest comfortably in the knowledge that you won’t be forced to read anything that isn’t up to your exacting standards.
I did not at all mind your comment, and I appreciate every effort from anyone. I just don’t think you were in the position to correct me, referring to “us” as solving my problems, as you did not, nor tried to, solve mine. That said, I don’t want to get into discussions like this.
Also, I did not know there were two AVR chips on every UNO… I will look into it 
Thanks so much everyone for thinking this through with me. Hopefully, I’ve got enough to go on for now.