Mark Kriegsman  I'm having some issues with a custom delay routine.

@Mark_Kriegsman I’m having some issues with a custom delay routine. I’m using it to check for incoming packets after a LEDS.show() command. It seems to be causing issues for the soft SPI (using pins 8 and 9 as I have an Ethernet Shield). If I call the function below after LEDS.show(), the WS2801 becomes unresponsive. Would like to avoid delay() and actually do other work in between LED changes. Any ideas what I might be doing wrong?

boolean msdelay(unsigned long thisdelay) {
unsigned long delaystart = millis();
while(millis() < thisdelay + delaystart) {
if(getUDP()) {
Serial.println(" RECVD");
return true;
}
}
return false;
}

You’re supposed to wait 500us (or perhaps more realistically 1ms) after sending data to WS2801 pixels, so assuming thisdelay is at least that long, your method looks ok to me. There’s also the (unlikely with the println) possibility that getUDP() == True and you’re exiting before then.

So the library right now waits for 24µs, not 500µs. If you want, you can change this line in chipsets.h:

CMinWait<24>  mWaitDelay;

damnit - submitted to soon, any way - change that 24 to 500 to change the delay. However, that means the next time you call LEDS.show() - it may end up delaying for a bit until it is ready to send stuff out.

When I add DMA support, one of the things I will expose is a ready() method that will let you know whether or not the next call to LEDS.show() will run immediately, or if it will have to wait for something else (namely, DMA) to finish before running. This might make it worth exposing a bit sooner.

That did the trick. Thanks! Fast_SPI has made my project so much easier. You guys are awesome!