SPI basics

[akis]

The SPI involves the pins MOSI, MISO, SCK and SS. I have only used when trying to upload new software on the Arduino/Atmega328 via the common USBasp programmer.

This connection is a 1-to-1 allowing the USBasp to communicate with the Atmega328.

I have seen displays and other hardware also using the SPI (MOSI, MISO, SCK, SS) and was wondering can you chain those devices so you can have multiple? I understand the SS pin allows the master to select the slave device, does that mean that all other devices go open circuit on the MOSI/MISO/SCK lines unless their own SS is selected?

[suicidaleggroll]

MOSI, SCK, and SS are always inputs on the slave devices.  MISO is the only one that is an output, and it's tri-stated when SS is high so that other slaves can drive the line.

[akis]

Thank you. On a similar note what are the key differences/advantages of the 3 main interfaces: SPI - I2C and Serial (Tx/Rx) ?

As far as I can see,

I2C can be chained with only 2 wires at 100KHz or 400KHz half duplex.
SPI can be chained with 4 wires - what speeds ?
Serial cannot be chained and can go as fast as 115Kbits /sec full duplex?

Have I got it right?

[6thimage]

I2C has addressing built into the protocol - so you only need 2 wires, even if you have 10 slaves on the bus.

SPI can achieve very fast speeds - definitely MHz (I've done 25 MHz before), the exact limit depends on the devices. However, SPI normally requires slave select lines, so 10 slaves results in 10 slave selects and 13 wires in total. It is possible to chain SPI devices, but this is very dependant on the devices.

Serial not very fast and practically everything that supports it supports I2C and/or SPI, but it is very simple (no addressing) and can be easily debugged (using a USB serial converter).

[suicidaleggroll]

Another advantage of UART is that there is no master.  Nothing has to be addressed, nothing has to be given a clock so it can report in.  It's asynchronous, the device on either end can push out data whenever it wants.  This makes it very flexible.

With I2C or SPI, the slave has to sit there and wait to be called upon before it can say anything.  With SPI you have to load in garbage data to the transmit buffer in order to run the clock to pull in data from the slave, and if you want to say anything to a device, even if the device doesn't respond to that command, you have to deal with garbage bytes pulled into the receive buffer during the transmit (and the associated Rx interrupts, etc.).  With UART, if you want to say something, you say it, and if the Rx interrupt fires it's because you were sent something, it's not just a garbage-filled byproduct of running the clock to transmit.

If I had to choose one word for each of them, it would be:
SPI - fast
UART - simple
I2C - expandable

[0xdeadbeef]

Chaining devices ("daisy chain") is possible with most but not all SPI devices. Most devices have a shift register and will just shift data "through" a device. These are chainable which means you can use multiple devices with just one chip select. Usually this is done only for identical devices, but theoretically, it could be used for different devices as well. Could get tricky though.

To set up the chain, the serial data out from the CPU has to be connected to the serial data in of the 1st slave, the 1st slave's serial data out to the serial data in of the 2nd slave and so on until the last slave in the chain connects its serial data out to the serial data in of the CPU again.
Generally, whatever data you would send within one chip select cycle must now contain the data for all the slaves. Indeed you can add additional data at the beginning which then is shifted through all the slaves and finally is shifted to the CPU's serial data in again. Can be used as linecheck.

Simple example: when you have two chainable devices where each needs one configuration byte and outputs one data byte, you will need to send two bytes from the CPU within a chip select cycle. After 16 clock cycles, the 1st byte will be in the shift register of the 2nd slave and the 2nd byte will be in the shift register of the 1st slave in the chain. In the CPU's receive buffer, there will be 1st the data byte from the 2nd slave followed by the data byte from the 1st slave in the chain.

[westfw]

Chaining devices ("daisy chain") is possible with most but not all SPI devices. Most devices have a shift register and will just shift data "through" a device.

Is that true?  Don't most "bidirectional" SPI things (memories, IO expanders, microcontroller-based slaves, etc) shift out their "response" while shift in a "command" (or "don't care") byte?  (and doesn't that generally interfere with "chaining"?)

You CAN chain arbitrary numbers of dumb shift registers and use SPI to read/write them all, but that's more of a special case (and the firmware has to know how many things are in the chain.)

[0xdeadbeef]

Most of the SPI devices I use at work are daisy chainable. Like >90% no matter how complex. This includes also stuff that is commercially available. E.g. the H-Bridge ST L9958. All of them are bidirectional.
And no, this is not a contradiction.

Imagine it like this: there is one internal shift register that has the size of the command/data words. Usually 16bits. When the CS signal is pulled, the IC writes the data word (from the last command)  in the shift register (one step). Now with each clock cycle, one bit of this data is shifted out to the IC's serial data out pin while one bit is shifted in from the IC's serial data in pin. When the CS is released again, the IC copies the value from the shift register to its command register of whatever. Until this happens, it doesn't care at all what is inside the shift register.

Assuming a 16bit word, it takes 16 cycles to shift out the data while the new command is shifted in. Now if you continue clocking within the same CS cycle, this shifting is just continued. There is no data lost as it's always one bit in and one bit out.
So if there are two ICs in the chain, the data (out) from the 1st IC would be inside the shift register of the 2nd IC after 16 cycles, while the data out of the 2nd IC is already in the receive buffer of the CPU.
If you add another 16 cycles, the data out from the 1st IC (which was temporarily inside the 2nd IC) will also arrive in the CPU's receive buffer.

There are of course ICs which don't support daisy chaining. This is generally considered bad design where I work but there might be specific reasons for it.
Usually the manual/data sheet mentions something like "daisy chain capability". Sometimes it's also more hidden in phrases like "If more than 32 bits are clocked in on pin SDI during a read operation, the data stream on SDI is reflected on SDO from bit 33 onwards".

[spudboy488]

Maybe the devices you use are 90% daisy chain-able but not for the rest of us. 99% of the devices I use are NOT daisy chain-able. I use mostly parts that I can write to and read from (EEPROM, port expanders, DDS, A/D converts) so they use the "classic" SPI definition. I was burned in a design where I used an D/A converter that was daisy chain-able. I had the converter data output tied to the system MISO line. Everything worked until I sent something to the A/D. The MISO line was stuck at whatever the last bit was that was clocked out of the converter.

As mentioned, always read the datasheet to find out how the part acts. I would bet that 99.9% of the parts that you can read back from are NOT daisy chain-able.

[Jeroen3]

Since SPI uses a Chip Select signal, it will be easier for the master protocol if you use star or bus topology. JTAG is daisy-chain-able by standard, SPI is not.

UART is simple, but only supports two nodes, get RS485 if you want more (which is uart, with a different driver circuit).

I2C/TWI is addressable, but slave devices often have address selections by pulling a pin high or low. Watch out for address conflicts. I2C was designed for Inter IC communication by Philips, as the name suggests.

There is also CAN bus, which is a more complicated 8 byte frame bus with address or id broadcasting network. It features checksums, priorities and retransmits on failure by hardware, it also guarantees that the message is received by at least 1 node. It's not that fast though, but reliable over distance.

[Dragon88]

However, SPI normally requires slave select lines, so 10 slaves results in 10 slave selects and 13 wires in total.

But not 13 GPIO pins from the uC. 74HC138 and 74HC154.

[Jeroen3]

The art is to also have the IO expander on SPI. So daisy chaining the expander to the the star-topology of the other perpherals. Or something like that...

[mikerj]

There is also CAN bus, which is a more complicated 8 byte frame bus with address or id broadcasting network. It features checksums, priorities and retransmits on failure by hardware, it also guarantees that the message is received by at least 1 node. It's not that fast though, but reliable over distance.

There is also the 1-Wire bus, Lin bus and probably dozens of lesser used or bespoke serial bus systems in use.

[6thimage]

However, SPI normally requires slave select lines, so 10 slaves results in 10 slave selects and 13 wires in total.

But not 13 GPIO pins from the uC. 74HC138 and 74HC154.

Very true, but you still require extra components and you have more traces to route on your board.

[0xdeadbeef]

Maybe the devices you use are 90% daisy chain-able but not for the rest of us. 99% of the devices I use are NOT daisy chain-able. I use mostly parts that I can write to and read from (EEPROM, port expanders, DDS, A/D converts) so they use the "classic" SPI definition. I was burned in a design where I used an D/A converter that was daisy chain-able. I had the converter data output tied to the system MISO line. Everything worked until I sent something to the A/D. The MISO line was stuck at whatever the last bit was that was clocked out of the converter.

As mentioned, always read the datasheet to find out how the part acts. I would bet that 99.9% of the parts that you can read back from are NOT daisy chain-able.

As explained, a daisy chain doesn't affect the bidirectional communication in any way. Actually a daisy chain can only work if the slaves have a serial data out - which is usually only the case if they also send something. Else the SDO would be only there for the chain. So while I wouldn't bet how many SPI devices on the market are daisy-chainable, for sure >90% of the chainable devices are bidirectional.

Just show that daisy chaining is common practice and supported by many device of many vendors, some links quickly found when searching for "daisy chain spi":
http://www.maximintegrated.com/en/app-notes/index.mvp/id/3947
https://www.infineon.com/dgdl/TLE8110+-+Preliminary+Application-Note+-+SPI+and+Daisy-Chain+-+Rev.0.2.pdf?fileId=db3a30431be39b97011be46d29f50024
http://www.ti.com.cn/general/cn/docs/lit/getliterature.tsp?baseLiteratureNumber=snaa070&fileType=pdf
http://www.intersil.com/data/an/an1340.pdf

[spudboy488]

Two of the examples you cited were DACs and the third was an EPOT. As I mentioned, daisy chaining will not work if you are attempting to read something back from the device.

Bidirectional communication will not be effected ONLY if the last device on the daisy chain is NOT connected to the system MISO line.

[0xdeadbeef]

Nope. As explained several times, the SDO of the last slave can of course be connected to the SDI of the master.
That's common practice, there is nothing complicated or dangerous about it.
The examples were not selected specifically, they were just meant to show that daisy chaining is nothing exotic but widely known and supported.

[westfw]

Is the CS behavior you describe typical?  I'm used to new data appearing on MISO long before CS is raised.  For example, here's a section from a random SPI EEPROM (25LC640):

The device is selected by pulling CS low. The 8-bit READ instruction is transmitted to the 25XX640 fol- lowed by the 16-bit address with the three MSBs of the address being “don’t care” bits. After the correct READ instruction and address are sent, the data stored in the memory at the selected address is shifted out on the SO pin. The data stored in the memory at the next address can be read sequentially by continuing to pro- vide clock pulses. The internal Address Pointer is auto- matically incremented to the next higher address after each byte of data is shifted out. When the highest address is reached (1FFFh), the address counter rolls over to address 0000h allowing the read cycle to be continued indefinitely. The read operation is terminated by raising the CS pin (Figure 3-1).

That would NOT be compatible with chaining, right?

(OTOH, this looks like an efficiency hack for memories, so it can read/write multiple bytes with a single "command"), and might not be typical of  other devices.)

(OTTH, I'm also thinking of the typical 8-bit SPI slave microcontroller peripheral, which is going to pass bytes to the firmware one at a time, and not wait for a full N-bit command to be latched on CS/ change.  I guess you COULD write the firmware to allow daisy chaining (assuming everything is byte-based), but it would require attention...)

[0xdeadbeef]

That's an optimization for reading continuous ranges and has no relation to daisy chaining.
Anyway, as daisy chaining has nothing to do with the protocol of the device and is invisible to the device, I can't imagine any case where a device's protocol would conflict with daisy chaining. On thew other hand, the driver on the CPU side must consider daisy chaining of course. Obviously it has to know how many devices are in the chain to know which position in the transmit/receive buffer belongs to which IC in the chain.
Generally, as disussed above: the daisy chain capability of a device is merely related to whether or not it implements a basic shift register between SDI and SDO or not. E.g. software implementations tend not to do this. Some modern VHDL designs where the designer is inexperienced and doesn't know about daisy chaining are also not chainable. The same is usually true for devices which implement multiple serial protocols (e.g. I2C + SPI). A classical SPI only device created by an experiences designer is usually chainable.

[spudboy488]

With all due respect, I just don't buy it. The LT1660 (which was the part that I got burned on) can not have its data out connected to the MISO of the CPU as it holds the line at the logic of the last bit shifted out; no matter what the CS line is at meaning the output is not tri-stated. I will give you that if I had a string of LT1660s and other write-only devices connected daisy chain, that would work. I would also say that if I had that same string, I wouldn't bother brining the data out line back to the CPU as there's nothing to read. That would also allow mixing read/write device on the same SPI bus.

Westfw summed it up nicely:

Is that true?  Don't most "bidirectional" SPI things (memories, IO expanders, microcontroller-based slaves, etc) shift out their "response" while shift in a "command" (or "don't care") byte?  (and doesn't that generally interfere with "chaining"?)

You CAN chain arbitrary numbers of dumb shift registers and use SPI to read/write them all, but that's more of a special case (and the firmware has to know how many things are in the chain.)

Any part that outputs something other than what is input will not work in a dasiy chain. Calling it "bad design" and stating that "for sure >90% of the chainable devices are bidirectional." is just not true.

[0xdeadbeef]

Well, if an IC forces a level on its SDO after the CS was releases, it's not usable in an SPI bus. While it might work like an SPI device, it's not compliant to SPI in a sense that multiple participants with different CS lines can share the same SDI/SDO/CLK lines.
However, even this doesn't affect the ability to set up and use a bidirectional daisy chain (as long the CS of the chain is the only CS on the bus to due the SPI incompatibility of the slave).

Maybe it helps to think of the daisy chain as bit stream. Each clock cycle moves the bitstream bitwise through the chain. Only if the CS line is released, the ICs in the chain "see" what's inside their shift registers. As the bits are clocked one after the other inside the shift register of an IC, the data bits inside the shift register are shifter out of the ICS to either the next IC or the CPU. Simple as cake if you think of it this way.

[spudboy488]

So now let's look at a memory device. Let's say we have 2 of them daisy chained; the output of the first going to the input of the second. The output of the second going back to the input of the CPU. How do I read the second device? How do I read the first device?

Let's do the same scenario with ADCs. How do I read either device?

And again with a port expander and a DDS?

If I select the first device, it will get the read command but the output will be blocked by the second device.

If I select the second device to read, the first device blocks the command to read.

Again, the only way daisy chaining works is if the device outputs what is input to it.

[0xdeadbeef]

As explained several times above you need to mutiply the number of clock cycles per CS by the number of devices in the chain of course.
If you have two devices in the chain and each would need 8 clock cycles (bits) within one CS, you will need 16bit per CS. If you have N devices where each needs M clock cycles (bits), you need N*M clock cycles within the CS instead M.

To give you a practical example: I'm currently working on a project which uses 12 H-bridges in a chain, where each bridge accepts a 16bit configuration command and answers with a 16bit diagnostic word. So for one bridge, you would have 16 clock cycles or 16bit (in/out) within one CS. For the twelve bridge configuration, there are now twelve 16bit-words per CS. For each communication cycle, 12 words have to be arranged in the correct order in the CPU's transmit buffer and at the end of the 12x16bit communication cycle, there are 12 words in the CPU's receive buffer. The 1st word received is from the last bridge in the chain (closest to CPU's SDI), the last word received is from the 1st bridge in the chain (closest to CPU's SDO).

[spudboy488]

And as I've asked several times above, how will daisy chaining work for other SPI devices? I am not arguing the fact that certain devices allow daisy chaining. From our conversation, so far, I agree that there are parts that will work when the output of one is sent to the input of the next. I am still asking how, what you call, the remaining "<10%" work. How will SPI memory devices work? How will SPI port expanders work? How will SPI ADCs work? How will any part that tri-states its output, which is the vast majority of the parts I asked about, when deselected work?

The point I'm still trying to make is that telling somebody that  "Like >90% no matter how complex." are daisy chainable is a false assumption to give.

[suicidaleggroll]

To give you a practical example: I'm currently working on a project which uses 12 H-bridges in a chain, where each bridge accepts a 16bit configuration command and answers with a 16bit diagnostic word. So for one bridge, you would have 16 clock cycles or 16bit (in/out) within one CS. For the twelve bridge configuration, there are now twelve 16bit-words per CS. For each communication cycle, 12 words have to be arranged in the correct order in the CPU's transmit buffer and at the end of the 12x16bit communication cycle, there are 12 words in the CPU's receive buffer. The 1st word received is from the last bridge in the chain (closest to CPU's SDI), the last word received is from the 1st bridge in the chain (closest to CPU's SDO).

I'm still confused.  Most of the SPI devices I've used take the FIRST word after selecting CS as their input argument.  How do you prepare the 11th link in your chain, without CS selected, to deliver this word to the 12th when CS is selected?  You need to select CS, and then the very next 16 clock cycles set the input to ALL 12 devices simultaneously.  How does that happen when it takes 176 clock cycles just to push it through the chain so it's ready to hit device #12?

From how I understand it, before you drive CS, all 12 device's outputs are tri-stated.  This means that device #10's output is tristated, so it doesn't matter how many times you run the clock, nothing useful will be clocked into device #11's input buffer, it'll just be noise.  Then when you drive CS, the next 16 clock cycles are going to deliver device #11's garbage buffer to device #12's input, how is that useful?  When do any of them spit out their output?  How do they know?  You can't deselect CS or again all of the outputs are tristated and nothing is pushed through the chain.  If you keep CS selected, then how does device #6 know that it needs to use the 6th input word after CS is selected as its input, then continue passing the input to the output for another 12 words? then finally it's allowed to send its output, all without CS ever being deselected?

Maybe if you went through a real example...
1) drive CS low
2) clock 8 bits into device #1
3) clock another 8 bits into device #1, which pushes the first 8 bits to device #2, and somehow device #1 knows that it's not supposed to replace these 8 bits with its own output for another 80 some-odd clock cycles
4) profit?

[0xdeadbeef]

The SDO of a SPI slave must only tristate while the device is not selected through CS. This is how the SPI bus is working - it has nothing to do with daisy chaining.
You suppose that an SPI device monitors each bit that is shiifted in. This is usually not the case - it certainly isn't for a device that supports daisy chaining. Indeed as I wrote somewhere above: the slave copies its internal data (that is supposed to be transmitted to he master) to the shift register when the CS is pulled low. While the CS is active, the shift register is merely a shift register. Only when the CS is released, the slave will copy the data from the shift register to its input/command register.