8
\$\begingroup\$

As far as I know, SPI transmission for an SPI slave works like below:

  1. Master selects a slave using SS pin
  2. Master and slave send data to each other simultaneously
  3. Master starts clock and data transmission at the same time (there is no clock before write operation)
  4. Master stops transmission any time it wants (by stopping write operation and clock generation), even if slave has more data to send.

Is there any SPI slave configuration which allows slave to transmit data without permission of master?

I'm just thinking out loud. Assume that there is only one slave and a continuous clock is provided by master etc.

Even if assumed statement is true, don't master and slave lose byte synchronization (i.e. receives bit stream) since there is no start-stop bits for SPI?

I'm asking such a question because I've read the following section from this document.

2.2 SPI Example

The attached SPI example illustrates the use of the USART in synchronous mode. USART1 is configured as slave, whereas USART2 is master. The following transactions take place:

  • Data transmission from master to slave.
  • Data transmission from slave to master.
  • Data transmission from master to slave and from slave to master simultaneously.

The document gives SPI example but realizes the example using USART devices. And I get that a USART slave can start a transmission without permission of master.

I couldn't find the source code that is referenced by the document.

\$\endgroup\$
  • 4
    \$\begingroup\$ The slave, by definition, cannot initiate a transaction (it may be able to interrupt the master to get a transaction started though). \$\endgroup\$ – Peter Smith Aug 9 at 15:54
  • 5
    \$\begingroup\$ Unidirectional data transfer in traditional SPI is just someone ignoring the state of the line going in the other direction. Writes, reads, and bidirectional transfers aren't really any different. In fact for example many SPI peripherals will clock out a status word during the first word, before they even know what is being requested, since it costs next to nothing to do so and allows a quick status polling. \$\endgroup\$ – Chris Stratton Aug 9 at 15:58
17
\$\begingroup\$

No, with SPI, all communications are driven by the master device. You are correct that the master cannot simply provide a continuous clock; there would be no way to detect the byte boundaries.

A slave device will often have a separate output pin to signal to the master that it has data available. This pin is connected to an input on a microcontroller and is often used as an interrupt.

Then, the device can assert the pin, causing the microcontroller to spin up the SPI bus.


For more detailed information, please read on :) This is a slightly-modified version of an explanation found here:

The slave device can only communicate when it is provided a clock from the master. This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.

When you send an SPI command from the master, two transmissions actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.

But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.

Then you need to provide an additional eight clocks to allow the slave to return the actual value. In many code implementations, this is done by sending a "dummy byte" to the slave.

Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.

That describes the general case. There can be additional complexities. For example, some slave ICs will actually output some sort of status byte at the same time they are receiving a command from the master. So, in this case, the master shouldn't discard the first received byte.

\$\endgroup\$
  • 2
    \$\begingroup\$ "the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately. \$\endgroup\$ – Aaron Aug 9 at 20:33
  • \$\begingroup\$ @Aaron Good to know! People keep getting more and more clever :-) \$\endgroup\$ – bitsmack Aug 9 at 23:13
7
\$\begingroup\$

No, master is the one that arbitrates the chipselects and drives the clock. A slave will always only listen to clock and chipselect. Data transfer can be full duplex still. There are some implementations where the clock can be continuous, but it does not matter much as the chipselect is used to synchronize the byte boundaries anyway. But then there are multimaster systems, so basically you can have some mechanism for the devices to decide who is slave and master. Or just include a separate "interrupt" wire for the slave to signal the master that it has a data packet for the master.

\$\endgroup\$
  • \$\begingroup\$ Could you add an example of a multimaster system? \$\endgroup\$ – davidcary Aug 16 at 2:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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