6
\$\begingroup\$

I'm planning out hardware for a project and would like to drive at least 2 displays, each using the SPI interface.

What I dont understand is why there are dedicated pins for the CS line (at least on Raspberry PI and Arduino). the selector. As I understand, the SPI device only listens if that signal goes low. Wouldn't any GPIO Do?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Never used Rasberry PI, but I worked on TI micros and they do have a dedicated CS line for their SPI interface. That's because they have inbuilt SPI drivers. So don't have to write the whole code to send/receive data via SPI*. You just have to put data on the tx buffer of SPI. that's why you need a dedicated CS pin. If you gonna write your own SPI drivers for Rasberry PI, you won't need a dedicated CS line. Any GPIO would work if you configure that pin in your SPI drivers. \$\endgroup\$
    – varun
    Commented Sep 17, 2020 at 19:26
  • 1
    \$\begingroup\$ @varun while hardware SPI chip select does depend on their being a hardware SPI engine, a hardware SPI engine doesn't typically require using hardware and not software select. The only place it can get a little tricky is where some core system functionality like an SPI-NOR flash used as a filesystem uses hardware SPI; I think in actuality typical kernel driver code can deal with the chip select type on a per-target basis, but it gets enough more complicated I've typically stayed with the hardware SPI model in those cases. \$\endgroup\$ Commented Sep 17, 2020 at 20:01

3 Answers 3

6
\$\begingroup\$

Yes, in theory "any GPIO" would do; this is called "software chip select"

But many SPI host engines also offer a "hardware chip select" option to control a dedicated pin from the SPI engine itself, which is a hair more efficient and keeps the software simpler. (It might also tie in with alternate uses of a synchronous serial engine, for example I2S where the "chip select" becomes more of a left/right channel toggle).

You should be able to use "software chip select" in your Raspberry-pi based project; likely you can do so through the SPI driver though that depends a little on precisely which one you are using.

To take things to an absurd extreme, you could even use something like a 74HC139 3-of-8 decoder to drive your chip selects from fewer GPIOs; but in real systems you'd typically run into fan-out loading and related signal integrity issues before you ran out of GPIOs, though you could add bus buffers...

A last caution: it has been claimed the SD cards operating in SPI mode are ill-behaved not-quite SPI peripherals, so you may want to avoid having anything sharing an SPI bus with one. Of course on a pi, your main SD card is local, and for an auxiliary you should consider a higher-bandwidth USB connection anyway.

For what it's worth, I struggle to recall ever using hardware chip select in an MCU project, but I've almost always used it with Linux hosts, both because the driver made it easy, and because the SPI often also had another role such as providing a flash file system, for which the default configuration already used hardware select, and while hybrid solutions are possible a uniform one will be simplest.

\$\endgroup\$
1
4
\$\begingroup\$

SPI slaves need a dedicated CS input pin, as it controls the hardware of SPI peripheral to either receive or ignore transmissions on bus.

SPI masters typically can use any GPIO pin to control which slave is active, but if SPI master has a overly complex SPI peripheral that supports hardware CS timing control, then it is usually a dedicated CS output pin.

\$\endgroup\$
0
1
\$\begingroup\$

SPI is a 4 pin protocol: SS - Slave Select; SCK - Master driven Clock; MOSI - Master Out Slave In; and MISO - Master In Slave Out. Controllers have hardware to implement the SPI protocol to drive these dedicated lines as required.

Slaves can be connected in series or parallel. In parallel, all MOSI lines and all MISO lines are connected together. 8 clocks will transfer a byte between the master and any slave. But the penalty is additional SS lines for each additional slave are required, which are software driven. 2 slaves 5 pins, 3 slaves 6.

In series, master MOSI goes to 1st slave MOSI, 1st slave MISO goes to 2nd slave MOSI, etc. This forms a big ring buffer. No additional pins are required, but the penalty is the ring buffer adds eight clock cycles for each slave to transfer a byte between master and slave. 2 slaves and 16 clocks are required to send byte between master and second slave, but only 8 clocks to send byte between second slave and master.

\$\endgroup\$
2
  • \$\begingroup\$ With your claimed "series" case seem to be confusing SPI and something like JTAG which is chain based. SPI doesn't work like that; you could create things which would, but they wouldn't be SPI but rather your own unique synchronous serial interface. In particular, ordinary SPI periphals do not support the sort of MOSI->MISO passthrough which such a scheme would require. \$\endgroup\$ Commented Sep 18, 2020 at 4:38
  • \$\begingroup\$ You have good points how to connect devices in series or parallel. Just as a detail, the devices have to explicitly support connecting in series, and some do work, but for example SPI flash chips can't be put in series. Some SPI devices cannot be put directly into parallel either, because their MISO pin is always output, but that is rare and usually explicitly mentioned. And it is more common that SS pin is not driven out by hardware, but under software GPIO control, though modern high performance MCUs do support hardware SS control. \$\endgroup\$
    – Justme
    Commented Sep 18, 2020 at 4:51

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.