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?

  • \$\begingroup\$ Slaves are, by their very nature controlled by the master and cannot initiate communications; they are asked to respond by the master. \$\endgroup\$
    – Andy aka
    Commented Jan 14, 2022 at 9:02
  • 1
    \$\begingroup\$ Yes of course the rpi has this. For example in python GPIO.add_event_detect is an option. What language are you using on the pi? \$\endgroup\$
    – Jeroen3
    Commented Jan 14, 2022 at 9:40
  • \$\begingroup\$ @Jeroen3, got it, thanks. I am using Python. \$\endgroup\$ Commented Jan 14, 2022 at 17:51

2 Answers 2


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.


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.

  • \$\begingroup\$ Valid point about interrupt handlers often not being practical to send a response instantly and thus, defeating the purpose. \$\endgroup\$
    – Rev
    Commented Jan 17, 2022 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.