1
\$\begingroup\$

I have a question regarding SPI communications. I feel like I have a good understanding fundamentally of how SPI works. However, I'm often confused when implementing the slave select line of SPI.

Is the slave select line on a microcontroller, in general, enhanced via hardware? That is, is there anything different between a slave select output and an output controlling an LED? Do microcontrollers allow certain I/O to be toggled faster when used for SPI?

\$\endgroup\$
5
\$\begingroup\$

No difference, as far as drive strength or transition speed are concerned.

Some uC's I've worked with don't even have a dedicated SS pin. You can implement it in code using whichever pin is convenient.

However, some microcontrollers will toggle the SS line for you (without you having to toggle the pin in code). This can reduce the dwell time between SPI transactions, decreasing the total time elapsed during multiple-transaction transmissions.

Also, if you are designing an SPI slave device, it is very convenient to use a uC that has a dedicated SS pin, which is used by the uC's internal SPI module.

The STM32F1 ARM-based microcontrollers, for example, have a dedicated SS pin for each of their SPI busses, with the option to disable the SS functionality and free up the pin for general use.

\$\endgroup\$
  • \$\begingroup\$ There's even uC's that handle multiple CS pins automatically in hardware (seen up to 16) if you queue the right transactions, but I suppose that's too advanced a topic here ;-). \$\endgroup\$ – Asmyldof Aug 17 '16 at 23:41
  • \$\begingroup\$ And some also support leveraging external demultiplexers to enable n io pins to drive 2^n chip selects. \$\endgroup\$ – alex.forencich Aug 18 '16 at 3:00
  • \$\begingroup\$ @Asmyldof and alex.forencich, do you have any examples of such devices or series? \$\endgroup\$ – Mels Aug 18 '16 at 10:59
  • \$\begingroup\$ @Mels Put a list of Atmel XMega and SAM devices up and throw a dart at it. And also several if not many other brands. \$\endgroup\$ – Asmyldof Aug 18 '16 at 16:45
  • \$\begingroup\$ Just a note - it can be a right pain in the ass if the SS line is controlled by the SPI peripheral of an MCU, as many IC slaves require specific SS control that this 'feature' will not allow. In this case, it is up to the developer to disassociate the SS pin with the peripheral and reassign it as a general IO. \$\endgroup\$ – Ed King Aug 23 '16 at 8:44
6
\$\begingroup\$

It depends on the microcontroller. In most SPI peripherals that I have seen the slave-select management is doing the exact same thing as a GPIO. I tend to use the GPIO interface in these cases as it allows for more flexible routing.

But I've also seen SPI controllers that do more advanced stuff like managing the SS lines per transfer packet. That comes in very handy if you communicate with multiple slaves on the same SPI bus via DMA. You just send out the data via DMA and the controller will do all the switching between slaves at the correct time without needing any CPU attention.

Other notable things I've seen:

  • Slave Select logic which just latches the state-change and delay this request it until the internal transfer FIFO is empty. This is very useful if you're just doing writes and don't care about the MISO data. You just write out your bytes to the SPI bus, de-assert the Slave Select and you're done. No risk in breaking the last byte because you've switched Slave Select to early.

  • Slave Select logic that allows for various SPI related protocols like TI-SSI, I²S etc.

  • Slave Select logic that automatically inserts an idle-bit between each transfer unit. Not sure why they do this as it makes SPI unusable for lots of SPI flash chips (Yes, I'm looking at you, NXP).

\$\endgroup\$
  • 1
    \$\begingroup\$ Of course I didn't read your answer before commenting above :/. Your last point is also present in some ARM ref designs and (as such?) some TI ARMs \$\endgroup\$ – Asmyldof Aug 17 '16 at 23:44
  • 1
    \$\begingroup\$ @Asmyldof Yes, when I researched the idle bit issue I came across a post from an NXP employee who said that this behavior is mandated by ARM. On the other hands there are plenty of ARM cores out there where SPI works as expected. For the NXP controllers you can fortuantely work-around the idle-bits by configuring TI-SSI transfers and use an GPIO for Slave Select. \$\endgroup\$ – Nils Pipenbrinck Aug 18 '16 at 0:17
  • 1
    \$\begingroup\$ Indeed, ARM makes mostly unsensible and highly specialised peripherals (more and more well known out in the world as well). I am happy every time I see companies like Atmel just implement their own highly clever designs on the ARM cores they make. \$\endgroup\$ – Asmyldof Aug 18 '16 at 7:13
3
\$\begingroup\$

As others have said, typically there is no difference in the pins electrically. However some have a dedicated SS pin, and some of those require the use of it if they have capability to be a slave device. The SS pin may be linked internally to some function of the SPI module.


ATMega and ATTiny devices that have SPI hardware do indeed have an SS pin which has special purpose. In this case if the hardware SPI module is enabled, it can only be a slave if the SS pin is set to be an input. In slave mode the SS pin is used to tri-state the MISO pin to allow it to be used in a multi-slave system, so the pin must be an input during slave mode.

For master mode in this case, the pin direction requirements vary between parts. On some parts it must remain an output (but can be user controlled as GPIO) in order to stay in master mode. On other devices, it can be either an input or an output - however in these devices, if configured as an input, the pin must be held high in order to stay a master. The latter option allows for multiple masters by switching into slave mode the moment the SS pin is pulled low.

\$\endgroup\$
  • \$\begingroup\$ This is very interesting because this is what primarily inspired my question. It makes sense that the SS pin on the microcontroller would be required if its acting as a slave since the pin must act like an interrupt. However, if the microcontroller is acting as a master, why is it necessary to even bother with the SS pin? Couldn't you potentially have the microcontroller act as an SPI controller and then use the SS pin as general GPIO? \$\endgroup\$ – Izzo Aug 17 '16 at 23:04
  • 1
    \$\begingroup\$ @Teague for ATMega's you can use the SS pin as GPIO when operating in Master mode, but only if it is kept as an output. It can't be used as an input while being a master. \$\endgroup\$ – Tom Carpenter Aug 17 '16 at 23:09
  • 1
    \$\begingroup\$ @Teague in fact, see my update. The above comment is not entirely accurate - some devices allow it to be an input, but it still has special meaning. \$\endgroup\$ – Tom Carpenter Aug 17 '16 at 23:16
1
\$\begingroup\$

Microcontrollers often have special hardware to handle CLCK, MISO and MOSI. This allows for a faster SPI transfer (and saves some CPU cycles). But the select is one-per-slave, and needs to be changed only twice during a transaction, so it makes more sense to use aq GPIO for this purpose, and that is how the uC's I have seen work,

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

For more advanced protocols using the SPI hardware (most notably I2S) the SS pin is generally controlled by hardware. In the case of I2S it is often used as the LRCLK.

The SS pin is quite often specially linked with the SPI hardware in such a way that when running in slave mode the SS pin can automatically control reception of data, and even raise interrupts when it changes state.

\$\endgroup\$

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.