Understanding the SPI Interface: Clock, Data & Oscillators

[bensonli]

From my understanding of how SPI interface works, the clock basically sends out data when it is set to HIGH(or LOW).
So, why does it seem like in pictures of the SPI lines, the setting of HIGH and LOW appears periodically. Can't we just put data onto DATA line, turn CLOCK line on to send, then turn CLOCK line off, and repeat this process? I wrote up a program for a device implementing this, and it seems to work just fine.

Also to clarify, is the CLOCK line supposed to be hooked up to a oscillator or something like that?

 

[berkeman]

From my understanding of how SPI interface works, the clock basically sends out data when it is set to HIGH(or LOW).
So, why does it seem like in pictures of the SPI lines, the setting of HIGH and LOW appears periodically. Can't we just put data onto DATA line, turn CLOCK line on to send, then turn CLOCK line off, and repeat this process? I wrote up a program for a device implementing this, and it seems to work just fine.

Also to clarify, is the CLOCK line supposed to be hooked up to a oscillator or something like that?

Welcome to the PF.

The SPI master device generates the clock SCK and the master sends data out the MOSI line, and the slave sends data out the MISO line.

Can you post a diagram showing the waveforms on those 3 lines to illustrate your question? What is your master device, and what are your slave devices?

http://www.maximintegrated.com/en/images/appnotes/4024/4024Fig02a.gif

 

[bensonli]

Ok. Here is my MATLAB code that basically follows standard SPI protocol. The device I am programming only requires 5 bits to specify its function.

And here is an example of what I am asking. Basically, can the picture not look "nice"?

I am asking because there's seems to be certain time values that are always specfied in datasheets for devices, and I was wondering if I can get away with not caring about them. For example ,

Though it is clear to see what most of the t's are, is it really necessary that I know them?

 

[nsaspook]

The SCK clock signal is how the slave knows when to sample the input data signal SDI for a 1 or 0 't1'/'t2' so it must be there for the device to work. It looks like you are Bit_banging the SPI master data instead of using a hardware device so every bit must be sequenced correctly. There are many SPI modes and types of devices, each with their own way of receiving data. The datasheet is the bible so there are times you need to send 'don't care' bits to complete the receive sequence.

 

[bensonli]

Hmm, could you give an example of using a hardware device?

Also, I was talking about how in datasheets, they define certain times (ike in the picture above), not whether there are start/stop/don't care bits that needs to be send along.

 

[berkeman]

Hmm, could you give an example of using a hardware device?

Also, I was talking about how in datasheets, they define certain times (ike in the picture above), not whether there are start/stop/don't care bits that needs to be send along.

You don't show SCK in your diagram. Can you add it in?

And yes, the times specified in the protocol and datasheets are important. Read some about "setup time" and "hold time" for synchronous logic -- that should help you get started...

 

[meBigGuy]

Assuming SS is true,

On the rising edge of sclk data is changed (say, by the master), and on the falling edge of sclk the data is sampled (say by the slave). That is how the communication works. One bit sent and received on each clock cycle. You cannot avoid sclk transitions on every bit sent. It is what tells the other side that the data is to be sampled.

Say I (the master) want to send 100 0's. I set MOSI to 0 and generate 100 cycles of sclk. How would I tell the slave there are 100 bits without sclk?

 

[nsaspook]

Hmm, could you give an example of using a hardware device?

Also, I was talking about how in datasheets, they define certain times (ike in the picture above), not whether there are start/stop/don't care bits that needs to be send along.

Sorry, missed your reply. The datasheet timing spec are usually for the minimum times for gates and clocks. If you need to run the device at the fastest possible speed they are important but usually you can clock data at much slower speeds (while still maintaining the correct sequence) unless the clocks are needed internally to be at least some minimum speed by the slave device. That information will also be on the datasheet.
http://ww1.microchip.com/downloads/en/DeviceDoc/21034F.pdf

2: Because the sample cap will eventually lose charge, effective clock rates below 10 kHz can affect linearity performance, especially at elevated temperatures. See Section 6.2 “Maintaining Minimum Clock Speed” for more information.

 

[Alec Dacyczyn]

Keep in mind the Clock line idles HIGH and drops LOW to tell the receiver that it is seeing good data and should latch it. After the receiver has has adequate time to register the bit then the Clock return to HIGH to tell the receiver to resume ignoring whatever is happening on the DATA line. The SYNC may be used as an enable pin (useful if you have multiple SPI devices and would like to use the same pins for CLK and DAT) or it may be used to mark the beginning and end of a transmission session. The subtle behaviors vary from device to device (why that is no true SPI standard); so read the datasheet carefully.

Here is some working Arduino code from a project I did;

//Write 16 bits to the DDS chip
void write_dds16(uint16_t data)
{

digitalWrite(SPI_CLK, HIGH); // idles low because device funkiness
delayMicroseconds(1);
digitalWrite(DDS_SYN, LOW); // begin transmission
//delayMicroseconds(1);​

for(byte i = 16; i ; i--)
{

// big-end out first
digitalWrite(SPI_DAT, byte((data & 0x8000) >> 15) );
digitalWrite(SPI_CLK, LOW);
data = data << 1;
delayMicroseconds(1);
digitalWrite(SPI_CLK, HIGH);
delayMicroseconds(1); ​

}

digitalWrite(DDS_SYN, HIGH); // end transmission
delayMicroseconds(10);
digitalWrite(SPI_CLK, LOW);​

}

For-Loop looks a little weird. It must have been 3:00AM when I wrote that.

 

[meBigGuy]

The active clock edges can change based on implementation, but I'll assume that for master and slave, posedge change, negedge capture.

WHat Alec says is basically true, but I'd like to mince words. When the clock edge goes high, the sender is supposed to immediately change the data. The data needs to be valid a specified setup time before the clock goes negative. Since the master is in change of both data and clock when sending, then it can wait as long as it likes before actually changing the data, then afterwards make the clock go negative to cause the slave to sample. But, that is not a good practice. The slave on the otherhand needs to change the data as soon as possible after the rising edge because the master can drive the clock negative at any time. The slave has no control over the clock.

There is no concept of "ignore the data when high". Only "sample the data on the negative edge of clock". Data can be ignored when the clock is high or low. Only the edges have an effect. Again, I assumed posedge change, negedge sample.

The timing numbers are important. Times that determine the max data rate for a posedge change system are:

1. Source worstcase posedge to valid data vs. receiver worstcase data setup before negedge. This sets the maximum clock frequency.

2. The receiver has a requirement for the minimum hold time after the negedge. The fastest source must guarantee its data remains valid for that required time. That usually isn't an issue unless one wants to really squeeze the clock low time.

3. slaves usually have min required clock high and clock low times

There are also times specifying min SS deassertion time, and SS to and from clock transition, etc. You should understand them all. Violating any of them will cause failures.

Generally if you are bit-banging, the processor cycles are slow enough that the times will always be met.

 

[Alec Dacyczyn]

Yeah, that's what I was getting at. The essence of SPI is that the receiver latches a bit based on the status of the DATA line at the instant the CLOCK exits its assertive phase. That is about the only detail that you can assume to be consistent across various implementations.

The above code was written for this thing:
http://www.analog.com/media/en/technical-documentation/data-sheets/AD9833.pdf

The timing diagram on page 4 shows the concept quite well. But remember that SPI is not always implemented the same. The AD9833 actually insists that the DATA transition happens distinctly before assertion of the CLOCK signal (it doesn't work if the DAT line is flopping around while CLK is low [EDIT: This is something I discovered from experience]). Always examine the datasheet closely. Most troubleshooting I've done with device-to-microcontroller interfacing was ultimately traced to my overlooking tiny details in timing or sequencing.

[EDIT: SDATA is an high-impedence input-only pin in this device. It doesn't tri-state.]

 

[meBigGuy]

I disagree with your interpretation. The AD9833 merely needs it data stable 5ns before and 3ns after the negedge of sclk. That the drawing shows it stable while clock is low is just the way it was drawn. There is nothing in the datasheet saying it must not flop around all it wants at any other time. The data is clocked into an internal flop when the clock falls, and has no effect at other times.

Also, the fact that they show SDATA being tri-state is bad practice also, since it can cause shoot-through currents unless they specifically design it such that FSYNC clamps the input gate. (which is possible, but I wouldn't tri-state SDATA )