Assuming I’m doing it right by:
#define FORCE_SOFTWARE_SPI 1
then it didn’t seem to work with Ken’s “IRremote.h”.
Am using pin 12 for the LED’s and pin 9 for IR on an UNO.
I tested it by enabling/disabling FastLED.show() in my loop. When disabled, received IR codes were consistently correct. When enabled, the received IR codes all over the map.
I guess his routines take more time than allowed.
I will take a look at what IRRemote is doing. If an interrupt takes more than 40us I don’t do anything to block that interrupt, I just stop writing the LED frame. However, I do have to disable interrupts for 30us periods at a time and if his code needs to respond to interrupts in under 30us then it will still have problems even with this.
By the way you don’t have to use force software spi, in fact you shouldn’t ever use it. For one - that only affects led chipsets using spi for communication, aka have both a clock and a data line. For another, it basically tells the library “even if there is hardware spi available on the pins you are using, don’t use it and bitbang instead” which, unless you are debugging problems with the hardware spi subsystem you never want to do.
Oh, also just to be sure, are you using the FastLED3.1 branch?
Downloaded/installed it right after your original message. Triple checking is always a good idea though. . . . Re-downloaded 3.1, re-installed, re-start Sublime/Stino, set to full compilation, same results. Test program is at http://pastebin.com/LrTts4wY