SPI: Linux driver model

4
votes

I'm new with SPI; the Linux kernel provides an API for declaring SPI busses and devices, and managing them according to the standard Linux driver model.

You can find the description of the struct spi_master here: https://www.kernel.org/doc/htmldocs/device-drivers/API-struct-spi-master.html

The description at the link above says that "Each device may be configured to use a different clock rate, since those shared signals are ignored unless the chip is selected". To put the sentence in a contest, I have to say that with "device" they mean SPI slave device, and with "those shared signals" they mean MOSI, MISO and SCK signals.

In fact, in the struct spi_device (https://www.kernel.org/doc/htmldocs/device-drivers/API-struct-spi-device.html) there is an attribute named max_speed_hz that is not present in the struct spi_master. So I can understand on the first part of the statement above: "Each device may be configured to use a different clock rate".

But, what does mean the second part? Does "since those shared signals are ignored unless the chip is selected" mean that I'm allowed to used different clock rates but only one at time by enabling/disabling the slaves with different rates?

Thank you for your help! Regards,

-- Matteo

2
linuxdriverspi
Yes, but this because you only want to talk to one device at a time anyways. Each device takes its 'turn' on the bus. Each device has its own set of commands, max SCLK, etc. So we want to only enable one device at a time. There are probably a few caveats to the this, but I think this is generally true. – rkyser
@rkyser: Why do you say "you only want to talk to one device at a time anyways"? Let's assume a single clock rate for simplicity. Let's take a look at the typical SPI bus on wikipedia. Let's say that slaves have 8bit data registers and master has 24bit data register. Are you saying that I'm not allowed to make all the slaves working together by putting SS1, SS2 and SS3 to zero (assuming slave select is active low)? – Matteo M.
I think this depends on the HW architecture. In the example you gave, if the Master was clocking out 24bits of data, how would any of the Slave devices know which 8bits belonged to it since each Slave was receiving the exact same bits? This architecture would work better for what you are talking about. But, then again, it really depends on the SPI devices are talking to. I'm simply speaking from my limited experience. – rkyser

2 Answers

1
votes

@Matteo M.: I think you actually are not allowed to simultaeously setting SS1, SS2 and SS3 to zero and in this way enabling all three SPI slaves at the same moment in time. The reason is, that the SPI slaves, while receiving data on the MOSI line, simultaneosly send back data on the MISO line. If actually all three slaves would put data on the (shared) MOSI line, really bad things could happen, both regarding the data and the electrical flow.

1
votes

SPI is a very loose "standard", there are not many rules to follow, which is good (and bad I guess). It is good because it is flexible. It is bad because it can be implemented differently depending on the specific hardware you are dealing with. Some devices support only half-duplex communication, which as you know requires coordination of when the bus can be driven. Select lines (chip enable, slave select, whatever you want to call them) provide a handy way to do this without using bits to identify which slave should get a message off the bus.

In the full-duplex mode, where data is dropped onto the bus from the master and from the slave on each clock pulse, the select line could be very much required to prevent bad things, as Wolfgang stated. I want to stress could be required; it is completely reasonable to have perhaps a master processor communicating with other processors that only drive the bus when responding to some specific bit pattern (like for instance, an "address")... More software/firmware? Yeah, but it is not stopping you.

So, if your 8-bit slaves are say, for instance 8-bit DACs you could indeed write the values chunks of the master data register. Independant select lines will enable you to do this without all those slaves driving the bus at once. Yeah, you have to shift the values from each slave into the master register one at a time, but that too is a completely reasonable design.

Unlike some more complex serial protocols SPI is actually really flexible; because it doesn't lock you into max word size or require any of the data you write to the bus to be comprised of things like addresses and offsets and stuff.