7 replies to this topic

[Bendage]

About all I know of SPI are the pins used and a needed cable select pin per component to be interfaced. What I do not know is how it works in layman's terms. 1. How to use the SPCK clock pin. How does it work? I know it controls the rate at which messages should be sent but what is really happening? 2. What does it mean to send data on the rising/falling edge? 3. How do bytes get sent over the MISO and MOSI pins? What is really happening? How does it work? 4. How to FULLY use the SPI and SPIConfig classes in the Micro Framework to their full potential? 5. What is "Bit Banging" and what is really happening? Can you use other pins? 6. What is the difference in using these classes opposed to "Bit Banging" to interface with SPI? Maybe give a simple real world example of a scenario on how/when to use it. Thank you.

[Mario Vernari]

Hello Bendage.
Well, the SPI is maybe the simplest peripheral interface that a microcontroller has. Instead of answering you by following the numeration, I'll try to explain how the SPI internally works.

The SPI allows to exchange data between two devices: one's role is master, and the other's is slave. The master's role is to generate the clock and alert the slave about the data exchange.
If you remember, on PCs there was the "parallel port", as well as the "serial port". At first glance, the difference was the number of pins on their connectors. Thus, the "serial-way" allows a less number of wires to transfer data.
Also a radio connection is a kind of "wire". Think it as a pipe, where the water is flowing through. Thus, on the air you can't use a "parallel" communication because the "wire" (pipe) is just one.

Since there's a clock, the protocol is synchronous. What it means "synchronous"?
Consider you and your friend communicating via a two-tones machine: one tone is for "0" and the other is for "1". Your friend wants to tell you his/her age (supposing you don't know), using the equivalent binary code.
He/she begins to emit the tones in sequence, but...how can you recognize a double "1" from a single "1" without any agreement in advance?
So, you might agree on the duration of each tone (e.g. one second).
Another way could be using another "signal" to instruct you when your friend is changing bit. For instance, he/she raises his hand each bit. In this way there's no a strict relation with the actual time.

So, when both the communicating subject are using the time as synchronization, it calls "asynchronous" transfer. This is how the UART (or USART) works, and it's the same serial as the old PCs have.
Instead, when there's another signal "clocking" the bit change, it calls "synchronous". That's SPI for instance.
Where the number of "wires" is an issue (e.g. radio), the async way is mandatory/preferable because it uses fewer.
For the sync-way you need *at least* two wires: data and clock.

Back to the digital gate logic of the '70: the SPI is a couple of shift-registers. One is for the outgoing data (MOSI=Master-Out Slave-In), and the other is for the incoming data (MISO=Master-In Slave-Out).
A shift-register is composed of 8 cells (typically), as a byte is composed of 8 bits.
When the master wants to transfer a byte to a certain slave, it must first to load the desired byte onto the outgoing register.
Afterward, that byte must be shifted out bit by bit, on the MOSI output. As the example above, each bit shifted out has its clock signal.

NOTE: if you want to know in *deep detail* how the byte-loading and the shifting process work, you can take a look at the flip-flops.

Back to the handy-way used by your friend to tell you about the incoming bits/tones, the "hand" is actually the clock. And the master rises the clock to instruct the slave about the changing bit. So, what you would do as an human is not so different from what is doing a machine.

Let's go to the slave side.
The slave "sees" the clock changing, and that's the signal from the master to distinguish the bits. But...these machines are *really* dumb, yet very fast. In other words, we're *not* in an ideal world, and two signals can have light differences on delay, voltage, etc.
Showcase: the master has sent a "1" and is preparing to shift out a "0" as next bit, using the rising edge of the clock to tell to the slave.
On the time "t" the clock rises (supposely in no time, even any process takes time to do), but there's a very small delay between the signals. Now, from the slave side (being wired), there are two concrete possibilities:

• when the clock rises the data bit is already "0", thus everything would go well, or
• the clock rises, but the incoming "0" is in late...so, how to detect it?

Please, note that for an human the signals moving in a circuit have no time. BTW, the current moves at about 70% of the speed of light. In your PC the data bus is working at 1GHz, thus a signal from CPU to the RAM (e.g. 10 cm) takes about 0.5 ns of run.
The distance is the primary reason for the speed limit.

Okay...the workaround to this ambiguity is using the other edge of the clock.
So, when the master shifts-out a new bit on the rising clock, the slave samples the new datum on the falling clock, and vice versa.
That's all.


Now, briefly about other questions...
In the Wiki there are several articles about SPI, SPI configuration and related. However, you should first learn a bit deeper how the logic behind works. A quick read about flip-flops is worthwhile, IMHO.

Bit-banging. Well, I didn't know what "bit-banging" was before joining this community.
Basically, the bit-bang-way is the simulation of the SPI via software, when your microcontroller doesn't have a real hardware for the SPI. For the Netduino in't absolutely worthwhile, because its SPI is blazing fast.

When the SPI should be used?
As explained, the SPI is a bi-directional parallel-to-serial converter. Whenever you need to glue several chips as they communicate together, you can save ton of wires by taking advantage of a serial bus as the SPI is. Since these chips are pretty close together (centimeters), you can reach even megabytes/sec of data rate at no cost. As soon the wiring is getting longer, the speed must be lowered accordingly. Don't mean the SPI as a way to transfer data on feet (or more) distances.

Hope it helps.
Cheers

[awaiK]

Hi Bendage,

there are some SPI-related topics in the wiki, like this one: SPI

[Bendage]

Mario, Thank you for taking the time to write out an excellent explanation. A couple of questions. Since the interface works in sending bytes that you 'bit shift' is it the interface that builds the byte back up of the code logic behind it that is responsible? Also can you explain the rising and falling edge? awaiK, thank you for the link I did not see that. In my project I am working with an interface that requires a pull-up resistor on the data line. Does it sit between the line, in front of the line (closest to the slave) or behind the line (closest to the master?) Is there a general resistor used like a 10k for example? So the cable select line stays high, you pull it low, send your bytes, receive your bytes and pull it high? The command line sends a bit then fires the clock or vice versa? Is that rising and falling edge?

[CW2]

Since the interface works in sending bytes that you 'bit shift' is it the interface that builds the byte back up of the code logic behind it that is responsible?

It depends: if you use bit-banging the code is responsible for transmitting the data bit after bit and similarly reconstructing the data back from received bits. If you use hardware module, it does it for you automagically, the code just writes and reads the data from SPI transfer register in chunks determined by the size of the SPI register and sometimes configurable data length - e.g. 8-bit microcontrollers have usually 8-bit SPI data register, Netduino microcontroller has 32-bit register but only 16-bits are usable, it allows data lengths from 8 to 16 bits, STM32F microcontrollers have 16-bit SPI register and support 8 or 16 bits transfers etc.

Also can you explain the rising and falling edge?

Rising edge is signal transition from low to high, falling edge is the other one from high to low.

In my project I am working with an interface that requires a pull-up resistor on the data line. Does it sit between the line, in front of the line (closest to the slave) or behind the line (closest to the master?) Is there a general resistor used like a 10k for example?

Is this supposed to be SPI interface? Because usually it does not require any pull-ups, they are mandatory for other interfaces like I2C or 1-Wire. The value for the resistor is usually recommended by device vendor in the datasheet or a typical value is suggested in the interface specification. Value between 1k and 10k is often used, but you should choose one based on your particular device and connection, to balance between speed and current consumption.

So the cable select line stays high, you pull it low, send your bytes, receive your bytes and pull it high? The command line sends a bit then fires the clock or vice versa? Is that rising and falling edge?

When the SPI transmission begins the master starts toggling the clock line (rising and falling edges) and changes the state of the data output (MOSI) line so the data is valid at clock edge given by the SPI configuration. Slave monitors the clock line and when the clock edge occurs it looks at the data line and saves the value into the register. It is crucial to have SPI configured in the same way on both master and slave side for the communication to work correctly - there are four possible modes determinted by clock polarity (CPOL) and clock phase (CPHA) bits. The reception (from the master perspective) happens the same way - slave sets the data on MISO line and master looks at it when the clock transition occurs.

[Bendage]

Thank you CW2. This is starting to make sense. Here is my contribution tip on using the SPI class... BE CAREFUL WITH THE CLOCK RATE! I set mine to 500mhz instead of khz and I bricked my board over and over again (about 30 times before I realized it). I am a pro at MFDeploy now and Chris did not get much sleep last night trying to get me up to speed.

[Arron Chapman]

@Bendage, Thank you for asking these questions, were getting some good responses which will greatly help people like me.

@Mario & @CW2 Thanks to both of your for your answers, but I'd like to make a small-ish request. Would you guys update and improve our wiki page for SPI with some of this rather nice information. Also, if either of you (or both) would take a stab at Bendage's I2C question, I know there are a few people who would benefit (myself included ).

I'm going to suggest some code samples as well, though for SPI I may do those myself.

[Mario Vernari]

Okay, let me some time to arrange the SPI content, then I'll stick it on the Wiki. Thanks all.