I read online that to start an SPI transaction to an SPI supported device, the SS (slave select, aka chip select) line must be set to low for the entire transaction then be brought high at the end to end transaction. If I make a circuit containing only one SPI device, will I need to lower the SS line send command then raise ss line everytime or can I tie the ss line low and send unlimited commands? The device I am using is ISD1700 sound chip.
\$\begingroup\$
\$\endgroup\$
4
-
3\$\begingroup\$ In general yes, the SS pin lets the slave device know when the transaction starts and ends. Without it there is nothing to ensure it stays in sync. It may work but if it ever gets out of sync it will not regain it. \$\endgroup\$– Kevin WhiteCommented Dec 5, 2016 at 3:43
-
4\$\begingroup\$ @kevinWhite actually many SPI devices need that SS transition to kick off an internal state machine. The datasheet for your particular device should give you the answer, but if you've already got it, why not try it? \$\endgroup\$– akohlsmithCommented Dec 5, 2016 at 4:01
-
1\$\begingroup\$ @akohlsmith - I agree, I am saying that you DO need the SS not that you can get away without it. Even those devices that don't require it to perform internal operations can get out of synchronism with the master. The only manufacturer that have seen that recommend not using the SS is Analog Devices for some of their devices where they have multiple functions assigned to pins such that the SS may not be available. I don't see how that can be reliable and I have heard complaints where the device requires a reset to bring back into sync. \$\endgroup\$– Kevin WhiteCommented Dec 5, 2016 at 4:18
-
\$\begingroup\$ I agree with @akohlsmith. And if you want to answer the question I will up vote. Here is my argument: I periodically communicate with a device over SPI. But, there is an interrupt driven feature which also need the SPI to the same device. Using the SS pin I should be able to interrupt the current SPI transaction with out finishing it. Giving me access to the SPI device faster when servicing the interrupt. \$\endgroup\$– st2000Commented Dec 5, 2016 at 4:22
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
2
[ @Kevin and @akohlsmith should post their comments as answers.
This is to expand on their comments. ]
SPI1 doesn't prescribe the exact behavior of the SS (slave select line2). This behavior is dependent on the implementation of each individual device. I have seen devices that can operate with the SS permanently aserted. I have also seen devices that require falling and rising edges on the SS.
Although it doesn't say that explicitly that the SS must be toggled,
the design guide (p.31) says that SS starts and ends the SPI transaction. It would be prudent to assume that SS has to be toggled for the SPI transaction to come through.
1 SPI is more of a custom, rather than a standard.
2 CS (chip select) is another name for slave select.
answered Dec 5, 2016 at 4:20
-
6\$\begingroup\$ This is a very good answer. Many/Most SPI target devices are fully dependent on the SPI_CS line to initialize the bit capture state machine internal to the part to synchronize between the initiator and target devices. There are a few devices that are able to re-sync simply by recognizing sync or opcode patters on-the-fly on the MOSI signal line. But these are in the minority and anyone designing a system using SPI devices is recommended to provide for a SPI_CS to each target device even if that means using extra circuitry and/or GPIOs with the initiator device to provide that capability. \$\endgroup\$ Commented Dec 5, 2016 at 5:41
-
\$\begingroup\$ No need to add another answer, yours captures what @kevinwhite and myself were saying. :-) \$\endgroup\$ Commented Dec 5, 2016 at 17:37
\$\begingroup\$
\$\endgroup\$
2
It entirely depends on the slave device.
If the protocol for the slave device includes some kind of framing, whether that's with fixed-length packets, start/stop bytes or a header which specifies the packet length, then the slave device may be able to operate without a chip select. I have a SPI flash memory chip in the board I'm currently working on which appears to be perfectly happy with or without the chip select. It can be permanently wired to 0V (enabled) with no problems.
This actually caused us some problems, because a contractor had set up some of the low-level I/O including the SPI, and we (and they!) didn't realise they'd not got the chip select working. It wasn't until I had to extend their SPI work to add another SPI device on the same bus that I found we didn't actually have chip selects!
Conversely, many slave devices do need chip selects to frame the data, and sending more bits/bytes than the expected packet without releasing the chip select at the end will be seen as an invalid transfer and rejected. DACs will often load the new value onto the output on the chip select rising-edge. ADCs similarly will often use the SPI transfer to start (and sometimes time) the conversion, so they need the chip select falling-edge as their trigger.
Your datasheet doesn't actually say anything about how to drive your particular chip over SPI, and I'm not motivated enough to google it. Exercise left for reader... ;)
-
\$\begingroup\$ I'm just gonna tie SS low and pray it works since the datasheet for the device I got from the internet only states that (according to the pin definition table in the datasheet) SS is used to enable the device. It also states that if SS is high, then the other SPI lines will be in high impedance state. fingers crossed. \$\endgroup\$– user116345Commented Dec 6, 2016 at 7:23
-
\$\begingroup\$ @Mike I discovered some motivation this morning, so I googled "ISD1700". The first two links were two PDF files. The first one was the datasheet you linked to; and the second one was the design guide which says exactly how to drive the chip. The design guide says (section 10.2, page 31): "A SPI transaction is initiated on the falling edge of the SS~ pin." So no, the datasheet says you can't get away with what you're planning. And I don't want to be too snarky here, but if you had JFGI and read the top two links that came up, you could have answered your own question. \$\endgroup\$– GrahamCommented Dec 6, 2016 at 10:44
\$\begingroup\$
\$\endgroup\$
2
Without knowing anything specific about the SPI slave device, no, you can't just tie SS low.
Many devices use the leading edge of SS to reset their internal logic to the start of a new transaction. For example, memories might interpret the first two bytes as address, then subsequent bytes as data. Some memories don't perform the physical write until SS is de-asserted.
For some devices with the right protocol, you might be able to get away with it. However, it won't work with most devices out there.
answered Dec 5, 2016 at 12:02
-
\$\begingroup\$ Several years late on this one. And I'm here because I was looking for answers too. Very good information that you added Olin, and good information from others too. I think the issue was mainly with the interpretation of the words 'chip select' or 'slave select' - which if one was forced to assume something, then the assumption would simply mean activate that device and turn off all other slave devices that might otherwise interfere with the communications between slave and master. A fair and logical 'assumption'. It's nice that this topic is cleared up right here in this thread. \$\endgroup\$– KennyCommented Oct 11, 2019 at 6:45
-
\$\begingroup\$ Another following question from this topic could be ----- if the chip select/chip enable pin should not be permanently 'enabled', then exactly when should the spi slave device be enabled and disabled? For example - do we disable the slave device after the completion of each command sent to the slave? \$\endgroup\$– KennyCommented Oct 11, 2019 at 6:56