Am trying to use both libraries to control a WS2801 based LED display. The latest version of fastspi works with WS2801's on an UNO running 1.0.1. I also have IRremote running as well.
The challenge is that when I try and integrate them, IRremote only returns '0' values. If I comment out FastSPI_LED.show() on line 31 below, IRremote works as expected. Not sure how to approach the authors of these libraries. Will get to debugging, but their code is pretty much over my head at this point. Am open to suggestions.
Here's some sample code using Arduino 1.0.1 and the lastest available versions of their libraries:
#include <FastSPI_LED.h> // The clock is on pin 13, while the data is on pin 11
#include <IRremote.h>
int RECV_PIN = 7; // A nice out of the way pin to connect the receiver to
IRrecv irrecv(RECV_PIN); // Initialize which pin we are receiving on
decode_results results; // Define the variable for storing 'results'
#define NUM_LEDS 32
struct CRGB { unsigned char b; unsigned char g; unsigned char r; };
struct CRGB *leds;
void setup()
{
Serial.begin(9600);
irrecv.enableIRIn(); // Start the receiver
FastSPI_LED.setLeds(NUM_LEDS);
FastSPI_LED.setChipset(CFastSPI_LED::SPI_WS2801);
FastSPI_LED.setDataRate(2);
FastSPI_LED.init();
FastSPI_LED.start();
leds = (struct CRGB*)FastSPI_LED.getRGBData();
}
void loop() {
keyb();
FastSPI_LED.show(); // if I comment this line out, the IR works as expected -------------------------------------
} // end of loop()
void keyb(void) {
if (irrecv.decode(&results)) { // If there is a result . .
Serial.println(results.value, HEX); // Print the value
irrecv.resume(); // Receive the next value
}
} // end of keyb()
Update: Have already enabled debug in the IRremote libraries and I suspect the problem has to do with interrupt conflicts, so I'm going to try and wrap a few things with interrupts(); and noInterrupts();.
Not to mention that throttling show() that hard won't work for the project.
I feel like there must be a way to ignore all interrupts except for when the IRRemote wants to do something, and at those rare instances it's acceptable for FAST_SPI to momentarily 'fail'