0
\$\begingroup\$

When using SPI, is there a common way of ensuring that when sending 8-bit words, that the sender and receiver know what is the start and end of a byte?

I'm guessing the best way is to assume that some period of no clock pulses from the master should be interpreted as a sort of reset, so the slave should assume any incomplete bytes/words should be abandoned, and the shift register reset? Is there some standard length accepted as a reset, either in multiples of some clock frequency, or some absolute time period?

\$\endgroup\$
  • \$\begingroup\$ Most (all)? dedicated SPI controllers only run the clock during data transfer. Why can that not synchronise you? \$\endgroup\$ – Peter Smith Jul 4 '16 at 16:03
  • 3
    \$\begingroup\$ Have you examined how your devices treat the select signal? \$\endgroup\$ – Ignacio Vazquez-Abrams Jul 4 '16 at 16:16
  • 3
    \$\begingroup\$ The chip-select/slave-select pin is pretty much always used for this purpose. \$\endgroup\$ – Tom Carpenter Jul 4 '16 at 16:51
  • 1
    \$\begingroup\$ @Mark With the SS (or CS) line. The devices I've used required the master to pull SS high, shift data, then pull SS low for a certain time, during which the contents of the shift register would be interpreted as a command and replaced with the result (which could be shifted out by pulling SS high again). \$\endgroup\$ – immibis Jul 5 '16 at 0:32
  • 1
    \$\begingroup\$ @Mark "If SS is de-asserted prematurely" then what happens for any other hold time violation? You get unpredictable behaviour. "If a device doesn't clear its bit counter on SS" doesn't make sense because the devices do not have bit counters. "Or if the master starts transferring when the slave is not yet ready?" - the slave is always ready to transfer data when SS is high unless you have a hold time violation. \$\endgroup\$ – immibis Jul 5 '16 at 0:49
2
\$\begingroup\$

The SPI master and slave sync based on the slave select signal. They should stay synced by always counting the bits in lock step after the initial slave select.

enter image description here

The SPI protocol depends on master and slave being able to remain in sync. If they get out of sync, then there is a deal-breaker problem someplace that needs to be fixed. Good places to look are noise and level problems on the signal lines, or software implementation bugs, or buffer overruns.

\$\endgroup\$
  • \$\begingroup\$ They SHOULD stay synced. And anything that causes them to go out of sync is a serious bug. But I think the OP is saying that it HAS gotten out-of-sync, and wants to know how to recover. If so, then what he really needs to know is how it went out in the first place, and how to fix it. \$\endgroup\$ – Mark Jul 5 '16 at 0:24
  • \$\begingroup\$ @Mark agreed. edited to reflect. thx. \$\endgroup\$ – bigjosh Jul 5 '16 at 3:53

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.