What happens if an interrupt appears while writing in SPI?

[romanrdgz]

I'm using official CCS libraries fat.h and mmcsd.c to read and write files to a SD card.

I use an interrupt for serial communications so I can send commands to my ucontroller. I use a command to tell the uc to start writting into the SD some data once each second. another one is a command for stop writting.

I have never seen any error, but I guess that the interrupt at the serial port when receiving a character of the STOP command could happen in the middle of a SPI writing, leading to some errors.

Why don't any errors appear? How is SPI working in this libraries? I don't understand why it works. Can anyone please explain to me?

[Ttelmah]

Multiple things:
First, even if an interrupt did affect SPI_WRITE, it wouldn't matter. SPI is _synchronous_. Both data and a clock are sent. You can stop sending 'mid bit', and have a longer clock, and things carry on as normal.
Second though, assuming you are using the hardware SPI, the whole 'point' of this, is that the _hardware_ does the transmission and reception. Once triggered to send a byte, it does this at the programmed rate, no matter what else the code is doing.
This is the delight of using the hardware peripherals. Much more important with the serial port, where data is _asynchronous_, without a clock input, and so the 'software UART', will have problems if something else happens at the same time, while the hardware UART again will merrily continue.

Best Wishes

[romanrdgz]

I had thought the same about the hardware SPI, but my project tutor didn't thought I was right. Glad to hear I was

Thanks for your help, and for the explanation about the longer clock, which has made me much clearer how SPI works and how UART doesn't.

[RF_Developer]

Another point to remember is that it can be difficult to know whether you are using the hardware and when the compiler has implemented a software emulation of SPI, I2C and UART. I strongly suspect a lot of folk think they are using the hardware when in fact, because they've "over" specified the configuration, the compiler has gone for the software version. Generally the more the programmer specifies, the more likely the compiler is to go software. Even specifying the default IO pins may well be enough.

Also an interrupt will not be serviced precisely when the hardware ask for it. There is latency (delay while the processor gets ready to process the interrupt), overhead in the compiler's interrupt vectoring code, and hold off time while interrupts are disabled, which once again can happen when the compiler wants it without the user being fully aware of it. If you get the "Interrupts disabled during call to prevent re-entrancy" message then some or all interrupts will be held of at times. That doesn't mean the interrupt is forgotten about, it means its delayed, and the ISR will be executed later than expected. You may "miss" interrupts if its delayed long enough for the hardware to "give up". For eample if you don't respond to UART receive before the nect character arrives, you will miss one or more characters and the UART will raise an overrun error.

Hardware peripherals reduce processor overhead, reduce timing jitter and uncertainty, run faster, can do true full duplex (send and receive at hte same time) and are a better option most ways round. Software emulations can provide greater flexibility (e.g. non-standard numbers of bits in SPI, enables, e.g. for RS485) but are slower, need more code, can ony operate one at a time, can use non-standard IO ports. However they can provide that vital extra bit of extra IO.

RF Developer