SPI port pin  - Page 1
Forum section: electronics / general

author: gogoman
author_rank: Regular Contributor
timestamp: May 19, 2019, 03:09:35 am
content: Hi a previous design ties the SPI chip select permanently low through a resistor, the design works.I don't believe this is the best practices, Is this a problem or a ticking time bomb.thank

author: ataradov
author_rank: Super Contributor
timestamp: May 19, 2019, 03:25:30 am
content: Depends on the chip and the project. It is likely to be fine.If the project is long running, I would implement a watchdog of sorts. Like read some ID register from time to time, and if you don't get a coherent result, reset the system.But if SPI chip does not have a reset, then you may need to implement a recovery procedure, like clock things manually until devices are synchronized again.PS: I'm assuming the CS is tied low on the slave (always selected), and the master simply does not control the CS pin.

author: ejeffrey
author_rank: Super Contributor
timestamp: May 19, 2019, 03:41:06 am
content: Some devices require chip select to operate properly, others are ok being permanently selected. The benefit of having a separate chip select line is that it provides message framing. This avoids the master and slave getting out of sync. If you don't implement chip select you need some way to bring the slave into a known state. That could be a reset line, but that has other side effects that may or may not be acceptable.

author: gogoman
author_rank: Regular Contributor
timestamp: May 19, 2019, 05:15:48 am
content: Quote from: ejeffrey on May 19, 2019, 03:41:06 amIs it possible to have to have the Chip select derived from the start bit of the data?thanks

author: ataradov
author_rank: Super Contributor
timestamp: May 19, 2019, 05:24:12 am
content: Quote from: gogoman on May 19, 2019, 05:15:48 amNot really. How would it know when to de-assert the CS?What is your actual chip?And if you have an option to setup some circuitry to derive the CS from the start bit, why not just properly connect the CS in a first place?

author: mikerj
author_rank: Super Contributor
timestamp: May 19, 2019, 11:58:20 am
content: Quote from: gogoman on May 19, 2019, 05:15:48 amAn SPI slave will need its chip select asserted before the first bit is clocked in.

author: NorthGuy
author_rank: Super Contributor
timestamp: May 19, 2019, 12:44:12 pm
content: Quote from: gogoman on May 19, 2019, 05:15:48 amIf you can switch to UART, you don't need the CS pin.

author: gogoman
author_rank: Regular Contributor
timestamp: May 19, 2019, 02:50:11 pm
content: Thanks for the input

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: May 19, 2019, 03:39:16 pm
content: For the record: even though some implementations deviate, the basic idea of SPI is that it can be implemented with a shift register. Typically, devices that are designed exclusively to use SPI move their output data into the shift register at the active CS edge and load their input data from the shift registers at the inactive edge. And while the CS is active, each clock period moves the shift register one bit from SDI to SDO, so one new bit is read from SDI and one bit is shifter out at SDO.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 19, 2019, 04:56:11 pm
content: Just to add to the confusion: some slave devices don't even care about /CS state at all. They use it as an enable for SDO so you don't get collisions, but they're essentially always listening to SCK+SDI. This means they have no way to reset how many clock cycles they've been shifted to, and your only recourse (following the manufacturer-approved procedure, though you'll have to dig into the errata to discover this) is to power-cycle the entire device and reinitialize it.But fortunately, most devices aren't this daft.Many do, however, use /CS rising as a trigger to begin processing the data received.So, as always: read the datasheet.Tim

author: IDEngineer
author_rank: Super Contributor
timestamp: May 19, 2019, 04:58:49 pm
content: Quote from: gogoman on May 19, 2019, 03:09:35 amIt works... today.There's a reason that SPI implementations reset upon deassertion of CS. Without that, how do you 1) know when the master and slave are out of sync, and 2) correct that condition when it occurs?I suppose you could implement some sort of timeout based on the absence of clock edges or whatnot, but then it's not SPI - it's a weird hybrid of sync and async serial communications. The beauty of SPI is that it's frequency-agnostic, can resync on every frame, etc.Also, most SPI implementations have this absolutely wonderful address-increment feature whereby you provide a starting address and then, as long as the master keeps clocking, you can read or write contiguous addresses back to back without explicitly specifying an address for each one. This is very efficient for block reads and writes, which are common on many devices. That entire feature is based on deasserting CS, which resets the SPI interface and thus insures the first byte after the next assertion of CS will be interpreted as an address. What happens when CS ispreventedfrom cycling is probably device dependent... after the first ADDR-DATA exchange of two bytes, when CS remains asserted, is the next/third byte considered an address or data?Some devices also use CS to determine whether to run in SPI or I2C mode. I'm working on a Bosch device right now that does exactly that: It looks for edges on CS and switches its interface between SPI/I2C based on what it sees.In short: Holding CS in either state is a terrible design choice. I won't quite say it's wrong, but it has several toes over the line.

author: ajb
author_rank: Super Contributor
timestamp: May 20, 2019, 04:10:47 pm
content: Quote from: IDEngineer on May 19, 2019, 04:58:49 pmThat really depends on the device. If it actually cares about the CS edges, then yes, it's a bad idea, but not all devices do (they might use a separate latch signal, for instance). Like Tim says, always read the datasheet.

author: MarkF
author_rank: Super Contributor
timestamp: May 20, 2019, 04:31:29 pm
content: Are we ever going to find out what the device is that we are talking about?