Interrupts disabled during call to prevent re-entrancy

[shirke]

Hi,
I got a warning: Warning#216 Interrupts disabled during call to prevent re-entrancy: (@SPI_XFERM16_2). I have read that I have to put #inline before the function, but I don't know how can I put that before the SPI_XFER. Do you have any idea?
_________________
shirke

[Ttelmah]

#inline is _not_ a solution for this here.

Think about it for a moment. This implies you are trying to do SPI transfers both inside the interrupt and outside. Now imagine what happens if the chip is in the middle of an SPI transfer in the external code, and the interrupt occurs?. You'll have the routine in the interrupt trying to send data to a peripheral that is already busy sending data in the main code.
Disabling the interrupts ensures this does not happen.

Much better though to 'rethink'. If your interrupt code needs to talk to the SPI, then could you send the main transfers 'via' the interrupt code. Or could the communication that you are doing in the interrupt be done in the main, by setting a flag in the interrupt.

You can't use the same piece of hardware 'at the same time' in two places. The compiler is preventing this from happening (hurrah), but you need to think out a proper solution and only talk to the peripheral in one place. If you 'inlined' the SPI code, it'd just make the problem worse...

[shirke]

I understand that this is for safety, but this is an external Interrupt what occures every 500us and the spi communication needs only about 250us. So it is not possible to call the spi recursively.
_________________
shirke

[Ttelmah]

If SPI is used in the interrupt, and an external transaction has started, the code is going to have to wait for the external SPI transaction to have completed. This is what disabling the interrupt does.... No, you can't use the hardware 'recursively' (possible exceptions if using something like a PIC24, and DMA for the transfers - then though you would talk to the DMA peripheral and let this do the transmission).
It also seems very unlikely that you can do a single SPI transfer. Normally you would need a complete 'transaction' with chip select, address transmission, then data, the deselection. Interrupts should be disabled for the whole transaction - you need to do this.
Consider doing the SPI transactions using a buffering system, and then just send the data to this from both sources.
It's not 'for safety', it's to allow the hardware to work...

Updated this:
Think what would happen if (for instance), you had the printer port on the PC, and had code printing to this, and then did an interrupt that also printed you this. You'd get printouts like:

"Message from the maFrom the interruptin code."

Effectively garbage.

Now you can print from multiple sources in the PC, and this is not done by using the hardware 'recursively', but instead by adding the print spooler. Instead of the code talking to the hardware directly, it talks to the print spooler, which handles the printing as 'jobs', and always lets each job complete, before starting the next. Now if you wanted something like this for the SPI, then you'd have to write it. You'd need a buffer, and instead of just storing the SPI data, you'd have to add the idea of a transaction to what is stored. Then when the code reaches the end of a transaction, it de-selects the SPI device, and if no more transactions are waiting, turns off the SPI interrupt. When you want to send data to the SPI device, you'd send a new transaction to the buffer and enable the SPI interrupt. You'd disable the SPI interrupts when actually writing to the buffer, but only then for a few uSeconds.