create a small delay in a Linux interrupt handler

Question

I'm working on an interrupt handler with a hardware design group and we're trying to figure out where a bug is. I'm reading a chip over the SPI bus at 5khz. The chip loads 4 bytes and triggers a data ready pin.

My interrupt handler wakes up and read 4 bytes off the SPI bus and stores the data in a buffer. Strangely enough though, every 17th read gives 4 bytes of all 0's, which is not right. One of the options we're exploring is that the chip isn't always actually ready when it sends the data ready signal.

So, I know I can't sleep in an interrupt handler, but I'd like to try and introduce a delay of 10 or 20 microseconds. Right now I have a for loop which counts to 100,000 then processes the interrupt. I haven't seen any changes, so I thought I might see if someone has a better technique for busy waiting. Or at least a better way of figuring out how many loop iterations I should go through, as I'm not sure how long this takes, or if the compiler is simply optimizing out the whole thing.

Sloat

Connect a digital analyser to the SPI lines. See if erroneous data is really being returned after data ready. Unless you better isolate the root cause of the problem, you could thrash about with delays etc. for ever. – Revolving

Answer 1

I dont know if you have access to any pseudorandom number generation libraries on your embedded device, but doing large number multiplication followed by mod will definately take some cycles. Instead of simply adding 1 (which is very fast at the hardware level and the compiler can optimize it to shifting since you're doing it a static number of times) use a random number seed (does the system have access to a time clock?) if available and do large number multiplication, modulus or factorial operations, negative number division also takes forever. Remember, division takes the longest at the hardware level. Use that to your advantage.

Scone

Answer 2

I assume your compiler will strip out a simple loop.

You should use volatile.

volatile unsigned long i;
for (i=0;i< 1000000; i++) 
  continue;

I assume also that this will not remove the problem or help you.

I can't believe, that a SPI peripheral has such a bug.

But it's possible that you read to slow the data from the SPI-Fifo.
So some of the received data will be dropped.

You should check the error flags of the SPI module and check the RX-empty RX-fullflags of the SPI.

Saretta