SPI Bus: theory and implementation
SPI stands for “Serial to Peripheral Interface”, and is a hardware and firmware communications protocol developed by Motorola and later adopted by all. The SPI bus is used only on the PCB. I’m sure some of you will ask: “Why is the SPI bus only used on the PCB? What prevents us from using it outside the PCB area?” The SPI bus was specially designed to exchange data between various IC chips, at very high speeds; say, 180 MHz or even higher. Due to this high speed aspect, the Bus lines cannot be too long, because their reactance increases too much and the Bus becomes unusable. However, if you want, you can use the SPI bus outside the PCB at low speeds, but this is not very practical: the SPI bus requires 3 or 4 communication lines, which is a bit too many, compared to 1 or 2 lines. it is generally needed to communicate efficiently with field devices located outside the PCB.
Anyway, on the PCB the SPI Bus is very good, because we can practically connect to the Bus as many ICs (or devices) as we want. Please excuse me for not providing a picture of the SPI bus, but rest assured you don’t need it – the SPI bus is so simple that you will understand everything in words.
The next question is: “Why is this SPI bus particularly useful?” In addition to exchanging data between various IC chips, the SPI bus is a method of multiplying the pins of the microcontroller. In other words, if you have a little 8-pin microcontroller, you could control a few hundred digital inputs and outputs with that little monster. This is impressive and I am sure that many doubt my words. Let’s explain this.
The SPI bus contains three lines and can be on any general I / O controller pins. These bus lines are: Clock, Data In, and Data Out. Also, each IC connected to the SPI bus needs an individual enable line. Things work like this: suppose we have four devices, A, B, C and D; all of them are connected to the SPI bus lines, and the bus itself is connected to seven pins of the controller: there are 3 bus lines plus the 4 enable lines. When we want to send a message to device C, we first enable its Enable line, then we send the message serially, one bit at a time. At the same time, devices A, B and D do exactly nothing, because they are not enabled.
The beauty of the SPI bus is that it is synchronous, that is, when the controller sends the message to an IC, it can also receive data from that IC at the same time. This particular aspect of the SPI protocol is particularly suitable for microcontroller-to-microcontroller communications.
Now, we have seen a small 8 pin microcontroller that can control 4 devices (ICs) using 7 pins. Considering that a type A, B, C, or D device could have eight or even sixteen I / O ports, this is still far from the hundreds of Inputs and Outputs I promised you. The next beautiful thing about the SPI bus is: one device IC can be serialized with many more of the same type! For example, we could have B1, B2, B3, B4, B5, etc. All Type B # ICs are serialized together and only require 4 microcontroller pins to work; the Enable line is common to all of them. We can then use each type A, B, C and D device as a group of dozens of similar ICs.
The enable speed of each I / O port on the SPI bus is slower when multiplying the microcontroller pins, but always keep in mind that I / O field devices do not necessarily need speeds of, say, 1000 triggers. ON / OFF per second each, simply because most of them can’t handle that speed. However, there are few very clever firmware techniques like the “barrel change” type of functions, which allow us to keep high-speed messages on the SPI bus, even if we have hundreds of I / O. At the same time, the functions of “keg change” allow for better time management within the microcontroller, so you have more time to perform other tasks, it makes sense to me! To conclude, I think it’s clear that we can now, in fact, build hundreds of efficient I / O lines into a small 8-pin driver.
In addition to this general presentation of the SPI bus, you should be aware that almost all ICs implement the SPI protocol in a particular way. For detailed and practical applications, I suggest you visit my website at Corollary Theorems. There you will discover a good tutorial book on how to work with hardware, firmware, including “barrel change” type of functions, and software design in general, and some nice and practical implementations of the SPI bus in particular.
Many microcontrollers have built-in SPI Bus hardware modules, but I was never very interested in their use. What I do, I always design, on the PCB and for a microcontroller, one, two or more custom SPI buses, because my custom implementations are much more flexible. Also, the practical implementation of a custom SPI bus, both in hardware and firmware, is really simple – trust me with this one!
