How can a slave device (microcontroller) communicate with a master device (Raspberry Pi) in SPI communication?

Question

I saw several posts for SPI communication where they only explain that if a master wants to communicate with a slave, it will turn the CS/SS line low for the respective slave device.

In my application, the slave device (microcontroller) needs to send the data to the master device (Raspberry Pi) at irregular intervals. How can I let the master device know that slave wants to communicate? When the master needs to communicate, it will pull the CS/SS line low. Is there anything that the slave can do if it wants to talk to the master?

I saw some posts on this website itself that state that some devices use interrupts to let the master device know that the slave wants to send anything. Does the Raspberry Pi have the feature to detect interrupts from a slave device, or I would need to do polling from the Raspberry Pi side so that it is always ready whenever MCU sends data? Is there any other way?

Answer 1

Polling is a very common way, if you need to periodically update data from a slave device anyway.

As you already mentioned, you can also have a slave signal the master, when new data is ready. The advantage is, that you only actually need to request data when you know that it changed. If you have to transfer a large chunk of data and do not want the master to be busy transferring data all the time, his can be beneficial.
Signaling can be done using normal GPIO pins. If you need a fast response, an input with interrupt support can be helpful.

Answer 2

If there is only SPI bus available, then the host has no way of knowing if the device has something for it, unless the host asks the device status via SPI.

So the host has to keep poling the device status at some suitable rate via SPI.

If there are extra IO pins between the host and the device, then there is no need to use SPI. The device can set a pin to a state that informs the host that the device needs attention. The host only needs to react to the IO pin state in some way which is much faster than querying status via SPI and only communicate via SPI when needed.

Commonly the pin that is used to signal the need for attention are named interrupt pins.

It only means the device wants attention, so the host should interrupt what it is doing and process the device, but only when it is a good time to do so.

It does not mean that a pin called interrupt must generate an interrupt on the host CPU.

In many cases interrupts are useless or even a bad idea. In many cases you can't handle SPI comms in an interrupt handler, as there might already be a transaction on the bus when interrupt is executed and there might be more important things going on to justify dropping everything for transferring data on SPI just to see something which was not that urgent. So at most the interrupt code would just set a flag variable that the device should be polled for status. Which is rather useless as instead of the flag variable the actual IO pin can be read to see that. Where it can make sense is that under some OS the interrupt could wake a sleeping process or schedule a task to handle the device.