Processing SPI transactions using interrupts

interruptsmicrocontrollerpic

I'm wondering what the best way to handle SPI transactions when using interrupts is.

I'm about to write my SPI interface code to an external flash part using a PIC. I'm going to use interrupts and I know that I'll get one after my byte is transferred, and after one is received. A typical 16 bit write transaction will look like this:

REGISTER_ADDRESS_BYTE | REGISTER_ADDRESS_BYTE | DATA_BYTE | DATA_BYTE | MAYBE_MORE_DATA_BYTES

Typically what I do is have a function like this pseudo code:

SendBytes(num_bytes, *ptr_to_bytes, address, init_true, callback_function_address);

Then in my SendBytes(...) I have a state machine with two static variables, one keeps track of the state, the other keeps track of the number of bytes sent. As interrupts come in I call SendBytes(...) again with init_false and step through my state machine for each byte of the transaction. When I'm all done I either stop or call the stored call_back_function.

My question is this a decent way to handle this, is there a better way using interrupts? I just made this up thinking about the problem but I assume others have had to handle this as well.

Best Answer

You didn't mention the PIC variant; SPI peripherals as well as interrupt controllers are different in different PICs. Here is an example of handling similar problem using PIC16:

https://github.com/felis/DMCI-XC8/blob/master/bsp.c#L91

It also shows state machine approach.

Related Solutions

Electronic – dsPIC33, SPI slave, and Timer1 interrupts. What happens

Normally you would set up the SPI peripheral once, then leave it on. The extra handshaking you are doing is preventing you from using the hardware to its full capability. Also doing a busy wait for the master to assert slave select is a bad idea if you ever want the processor to do something else.

Since you are transferring 16 bits of less per message, I would just let the hardware take care of it. Then you can monitor the SPI interrupt flag to determine when new data has been received from the master. If you need to slow down the master for flow control reasons, I would do that outside of the SPI message. I suspect the interrupt is adding latency to your home grown handshaking scheme, and something somewhere isn't quite right and can't tolerate that latency. That's assuming of course that the interrupt doesn't try to touch the SPI hardware or any of its I/O lines.

Electronic – Using multiple external interrupts in PIC

This is C pseudo-code to explain one idea. It uses and exclusive OR to work out which pins have changed and will call your different handlers within the one RBIE interrupt. Depending on how critical the application is you may want to check how the PIC handles situations such as a port changing while the interrupt is executing to make sure you won't miss any events.

int old_port_b;

void isr_handler()
{
    int new_port_b, changed_pins;
    new_port_b = read_port_b();
    changed_pins = new_port_b ^ old_port_b;
    if (changed_pins | 1)
        rb0_hander();
    if (changed_pins | 2)
        rb1_hander();
        // ... etc
    old_port_b = new_port_b;
}

int main()
{
    old_port_b = read_port_b();
    enable_interrupt();
}

Related Topic