0
\$\begingroup\$

I have one doubt regarding SPI. I am very new to this module. I know that communication is initiated by asserting the CS(high to low) in SPI. And then in every clock based on polarity and phase the data is transmitted/sampled. My doubt is once data has been transferred and CS is asserted again(low to high), does the clock pulse still continues or clock pulse is only there till the communication is maintained. The image shown is the waveform while trying to test SPI communication. The Master SPI shift register is of 16bits. I am transferring four 16 bits of data during the CS low period(i.e. when CS is enable). But during each clock I am getting 16 small incomplete waveform. I know this is wrong. Could someone give me the resolution or suggestion to rectify this.

enter image description here

I am expecting something like this, although it transfers two data of 8 bits each at 8 clock pulse, I want to transfer 4 data each at 16 bit clock pulse. When I increase my data buffer from 4 to 5, I get 5 square pulse, and each pulse having 16 jitters.

enter image description here

Please reply.

\$\endgroup\$
  • 1
    \$\begingroup\$ The master may continue to pulse the clock with CS# deasserted. The slave device must ignore the state of CLK and MOSI while CS# is deasserted. This makes it possible to put multiple slaves on an SPI bus by running separate CS# lines to each slave. \$\endgroup\$ – DoxyLover Jul 7 '15 at 19:32
  • \$\begingroup\$ @DoxyLover:I think the clock which is generated is not a correct one. I think each clock pulse(sqaured one) should have 16 on/off signals. Can you please suggest what can be possibly done for getting it correct. Is this because baud rate setting issue? Do I need to lower the baud rate. Please reply.(In the above pic I am not getting clock proper high/low signal, which should be there based on which data is sampled/shifted) \$\endgroup\$ – Akshara Prasad Jul 8 '15 at 2:55
  • 1
    \$\begingroup\$ I think you are confused. The clock pulses off/on/off (or visa versa depending on clock polarity) once for each bit transferred. To transfer 16 bits requires 16 individual pulses on the clock line. Your comment about "16 waves in each clock square" is none sense. Each "square" as you call it is transferring 1 bit. That's how SPI works. \$\endgroup\$ – DoxyLover Jul 8 '15 at 5:02
  • 1
    \$\begingroup\$ Looking at your diagram, I'd say the "waves" you're seeing is just noise and probably has no effect on the operation of the clock. \$\endgroup\$ – DoxyLover Jul 8 '15 at 5:04
  • \$\begingroup\$ @Akshara Prasad: as SPI is a synchronous protocol (i.e. one that provides a clock signal in addition to the data) you don't have to care about baud rate (as long as it is within the max. supported rate). \$\endgroup\$ – Curd Aug 24 '17 at 13:39
1
\$\begingroup\$

It ends whenever the master says it ends. If the master is a MCU, see the MCU's datasheet for its behavior.

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

An SPI Slave device is selected by its very own CS* (active-low) signal. If the Slave's CS* pin is high, it is required to ignore any clock pulses that go past. If the CS* pin is low, it must clock data in and out as the clock pulses dictate.

This allows you to have multiple SPI Slave devices connected to an SPI Master device.

For that matter, you are allowed to have multiple SPI Master devices sharing one or more Slave devices. The Masters are required to coordinate their usage of the SPI clock and chip select lines, so that they don't both try to use the lines at the same time. SPI does not discuss or mandate the synchronization mechanism.

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

The SPI Master will hold the clock high/low until the communication is initiated by the master, at which point the master pulses low/high to initiate and pulses for the duration (low to high, low to high, etc.) of the communication. Once communication is done, the master pulls the clock high/low and it remains high/low until the master initiates communication again.

Unfortunately, I do not have the waveforms to confirm this, however I was working with SPI a few months ago and confirmed that this was the case in my scenario.

EDIT: After seeing your image I realized I was confusing SCLK with CS/SS. So what I said holds true for the clock in my situation. Now the CS/SS is necessary when using more than one slave device. The master will hold the line low for the selected slave while it communicates and then when done pull it high again. Each slave needs its own CS/SS line in order to select them individually or one line to select all slaves at the same time.

This might help:

https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi

\$\endgroup\$
  • 1
    \$\begingroup\$ that means... once communication is done clock remains in its idle state (which can be either low or high) until the next communication. Is it? \$\endgroup\$ – Akshara Prasad Jul 7 '15 at 18:06
  • 1
    \$\begingroup\$ A typical SPI master will leave the clock in the idle state between the end of one byte and the start of the next. In SPI modes where data is output on the leading edge of the clock, the state of MOSI after the last clock edge is for some reason often not clearly specified. \$\endgroup\$ – supercat Jul 7 '15 at 18:08
  • \$\begingroup\$ Yes that is correct. I suppose the idle state does not need to be high, just whatever the default idle is. \$\endgroup\$ – TronicZomB Jul 7 '15 at 18:08
  • \$\begingroup\$ The state of MOSI between the last clock edge and the time the next byte is loaded (the next "load" clock must be delayed at least half a cycle from that) would be "don't-care" for a purely-synchronous slave, but may be relevant if e.g. a battery-powered device is communicating via opto-isolator and wants to leave the line in a low-power state when there's no reason to do otherwise. \$\endgroup\$ – supercat Jul 7 '15 at 18:13
  • \$\begingroup\$ @supercat: I dint get you when you say "A typical SPI master will leave the clock in the idle state between the end of one byte and the start of the next" My SPI module is of 16bit register buffer. So is it that after 16 bit data transfer, the clock will come into idle state, and again 16 bit transfer then idle as long as CS remains low ? \$\endgroup\$ – Akshara Prasad Jul 7 '15 at 18:16

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.