"Turn" SPI & I²c

From the following address: http://www.byteparadigm.com/applications/introduction-to-i2c-and-spi-protocols/

I²c vs SPI

Today, at the low end of the communication protocols, we find i²c (for ' inter-integrated Circuit ', Protocol) and SPI (for ' Serial peripheral Interface '). Both protocols is well-suited for communications between integrated circuits, for slow communication with on-board PERIPH Erals. At the roots of these, popular protocols we find, major companies–philips for I²c and Motorola for Spi–and D Ifferent histories about what, when and how the protocols were created.

The I²c bus was developed in 1982; Its original purpose is to provide an easy-to-connect a CPU to peripherals chips in a TV set. Peripheral devices in embedded systems is often connected to the microcontroller as memory-mapped I/O devices. One common-on-the-connecting, the peripherals to the microcontroller parallel address and data busses. This results in lots of wiring on the PCB (printed circuit board) and additional ' glue logic ' to decode the address bus on Which all the peripherals is connected. In order to spare microcontroller pins, additional logic and make the PCBs simpler–in order words, to lower the costs– Philips Labs in Eindhoven (the Netherlands) invented the ' inter-integrated circuit ', IIC or I²C protocol that only require s 2 wires for connecting all the peripheral to a microcontroller. The original specification defined a bus speed of up to Kbps (kilo bits per second). The specification was reviewed several times, notably introducing the In 1995 And–since 1998, 3.4 Mbps for even faster peripherals.

It seems the Serial peripheral Protocol (SPI) is first introduced with the first microcontroller deriving from the same a Rchitecture as the popular Motorola 68000 microprocessor, announced in 1979. SPI defined the external microcontroller bus, used to connect the microcontroller peripherals with 4 wires. Unlike I²c, it's hard to find a formal separate ' specification ' of the SPI bus–for a detailed ' official ' description, O NE have to read the microcontrollers data sheets and associated application notes.

Tp.

SPI is quite straightforward–it defines features all digital electronic engineer would think of if it were to quickly de Fine A-to communicate between 2 digital devices. SPI is a protocol on 4 signal lines (* Refer to Figure 1):

-A clock signal named SCLK, sent from the bus master to all slaves; All the SPI signals is synchronous to this clock signal;
-A Slave Select signal for each slave, SSn, used to select the slave of the master communicates with;
-A data line from the master to the slaves, named MOSI (Master Out-slave in)
-A data line from the slaves to the master, named Miso (master In-slave out).

SPI is a Single-master communication protocol. This means, one central device, initiates all, and the communications with the slaves. When the SPI master wishes to send data to a Slave and/or request information from it, it selects slave by pulling the Cor Responding SS line low and it activates the clock signal at a clock frequency usable by the master and the slave. The master generates information onto MOSI line and it samples the Miso line (refer to Figure 2).

Four communication modes is available (MODE 0, 1, 2, 3) –that basically define the SCLK edge on which the MOSI line Togg Les, the SCLK edge on which the master samples the Miso line and the SCLK signal steady level (that's the clock level, HI GH or low while the clock is not active). Each mode was formally defined with a pair of parameters called ' clock polarity ' (cpol) and ' clock phase ' (Cpha).

A Master/slave pair must use the same set of PARAMETERS–SCLK frequency, Cpol, and Cpha for a communication to be POSSIBL E. If multiple slaves is used, that is fixed in different configurations, the master'll has to reconfigure itself EAC H time it needs to communicate with a different slave.

This is a basically all, defined for the SPI protocol. SPI does not define no maximum data rate, no particular addressing scheme; It does not has a acknowledgement mechanism to confirm receipt of data and does is not an offer for any flow control. Actually, the SPI Master has no knowledge of whether a slave exists, unless ' something ' additional are done outside the SPI Protocol. For example a simple codec won ' t need more than SPI, while a command-response type of control would need a higher-level PR Otocol built on top of the SPI interface. SPI does not care about the physical interface characteristics like the I/O voltages and standard used between the devices . Initially, most SPI implementation used a non-continuous clock and byte-by-byte scheme. But many variants of the protocol now exist, which use a continuous clock signal and an arbitrary transfer length.

I2c

I²c is a multi-master protocol that uses 2 signal lines. The signals is called ' Serial Data ' (SDA) and ' Serial Clock ' (SCL). There is no need of chip select (Slave Select) or arbitration logic. Virtually any number of slaves and any number of masters can be connected onto these 2 signal lines and communicate Betwee n each of the other using a protocol that defines:

-7-bits slave Addresses:each device connected to the bus have got such a unique address;
-Data divided into 8-bit bytes
-A few control bits for controlling the communication start, end, direction and for a acknowledgment mechanism.

The data rate have to be chosen between Kbps, and 3.4 Mbps, respectively called standard mode, fast mode and H IgH speed mode. Some i²c variants include ten kbps (Low Speed mode) and 1 Mbps (fast mode +) as valid speeds.

Physically, the I²c bus consists of the 2 active wires SDA and SCL and a ground connection (refer to Figure 4). The active wires is both bi-directional. The I²C protocol specification states the IC that initiates a data transfer on the bus is considered the bus Master. Consequently, at-time, all of the other ICs is regarded to be Bus slaves.

First, the master would issue a START condition. This acts as a ' Attention ' signal to all of the connected devices. All ICs on the bus would listen to the bus for incoming data.

Then the master sends the ADDRESS of the device it wants to access, along with an indication whether the access is a Read or write operation (write in our example). Have received the address, all ICS ' s would compare it with their own address. If it doesn ' t match, they simply wait until the bus is released by the stop condition (see below). If The address matches, however, the chip would produce a response called the acknowledge signal.

Once The master receives the acknowledge, it can start transmitting or receiving DATA. In we case, the master would transmit data. When all was done, the master would issue the STOP condition. This was a signal that states the bus had been released and that the connected ICs could expect another transmission to start Any moment.

When a-master wants to receive data from a slave, it proceeds the same-out, but sets the RD/NWR-bit at a logical one. Once The slave have acknowledged the address, it starts sending the requested data, byte by byte. After each data byte, it's up to the master to acknowledge the received data (refer to Figure 5).

START and STOP is a unique conditions on the bus that is closely dependent of the I²C bus physical structure. Moreover, the I²C specification states that data could only be change on the SDA line if the SCL clock signal are at a low level; Conversely, the data on the SDA line was considered as stable when SCL was in high state (refer to Figure 6 hereafter).

At the physical layer, both SCL and SDA lines is open-drain I/Os with pull-up resistors (refer to Figure 4). Pulling such a line to ground are decoded as a logical zero, while releasing the line and letting it flow is a logical one. Actually, a device on a i²c bus ' only drives zeros '.

Here we come to where i²c is truly elegant. Associating the physical layer and the protocol described above allow flawless communication between any number of devices , on just 2 physical wires.

For example, what happens if 2 devices is simultaneously trying to put information on the SDA and/or SCL lines?

At electrical level, there are actually no conflict at all if multiple devices try to put any logic level on the I²C bus Lines simultaneously. If one of the drivers tries to write a logical zero and the other a logical one, then the Open-drain and pull-up structure Ensures that there'll be no shortcut and the bus would actually see a logical zero transiting on the bus. In other words, with any conflict, a logic zero always ' wins '.

The bus physical implementation also allows the master devices to simultaneously write and listen to the bus lines. This is the able to detect collisions. In case of a conflict between-masters (one of them trying to write a zero and the other one-one), the master that GA INS the arbitration on the bus would even not be aware there have been a conflict:only the master that looses would know–s Ince it intends to write a logic one and reads a logic zero. As a result, a master that looses arbitration on a i²c would stop trying to access the bus. In most cases, it'll just delay its access and try the same access later.

Moreover, the I²C protocol also helps at dealing with communication problems. Any device present on the i²c listens to it permanently. Potential masters on the I²c detecting a START condition would wait until a STOP is detected to attempt a new bus access. Slaves on the I²c bus would decode the device address that follows the START condition and check if it matches theirs. All the slaves. Addressed would wait until a STOP condition is issued before listening again to the bus. Similarly, since the I²C protocol foresees Active-low acknowledge bit after all byte, the Master/slave couple is able t O detect their counterpart presence. Ultimately, if anything else goes wrong, this would mean then the device ' talking on the Bus ' (master or slave) would know It by simply comparing what it sends with what's seen on the bus. If a difference is detected, a STOP condition must be issued, which releases the bus.

Additionally, I²c have got some advanced features, like extended bus addressing, clock stretching and the very specific 3.4 Mbps High Speed mode.

Any i²c device must has a built-in 7 bits address. In theory, this means that there would is only different i²c devices types in the world. Practically, there is much more different i²c devices and it is a high probability that 2 devices has the same address O n a i²c bus. To overcome this limitation, devices often has multiple built-in addresses that the engineer can chose by though external Configuration pins on the device. The I²C specification also foresees a 10-bits addressing scheme in order to extend the range of available devices address.

Practically, this have got the following impact on the I²c protocol (refer to Figure 7):

-double address words is used for device addressing instead of one.
-The first address word MSBs is conventionally coded as "11110" so any device on the bus is aware the master sends a 10 BITS device address.

Actually, there is other reserved the address codes for specific types of accesses (refer to table 1). For details on them, please refer to the I²C specification.

-Clock Stretching

In an i²c communication the master device determines the clock speed. The SCL signal is a explicit clock signal on which the communication synchronizes.

However, there is situations where an i²c slave is not able to co-operate with the clock speed given by the master and NE EDS to slow down a little. This is do by a mechanism referred to as clock stretching and are made possible by the particular Open-drain/pull-up St Ructure of a i²c bus line.

An i²c slave is allowed-to-hold down the clock if it needs to reduce the bus speed. The master on the other hand was required to read back the clock signal after releasing it to high state and wait until the Line have actually gone high.

-High Speed mode

Fundamentally, the use of pull-ups to set a logic one limits the maximum speed of the bus. This is a limiting factor for many applications. This is, the 3.4 Mbps high speed mode was introduced. Prior to using this mode, the bus master must issue a specific "high speed Master" code at a lower speed mode (for example : 1 kbps Fast Mode), which initiates a session at 3.4 Mbps. Specific I/O buffers must also be used to Let the bus to shorten the signals rise time and increase the bus speed. The protocol is also somewhat adapted in such a-on-the-no-arbitration is performed-during the high-speed transfer. Refer to the I²C specification for more information on the high speed mode.

I²c vs Spi:is there a winner?

Let ' s compare i²c and SPI on several key protocol aspects:

-Bus topology/routing/resources:

I²c needs 2 lines and that's it, while the SPI formally defines at least 4 signals and more, if you add slaves. Some unofficial SPI variants only need 3 wires, which is a SCLK, SS and a bi-directional Miso/mosi line. Still, this implementation would require one SS line per slave. SPI requires additional work, logic and/or pins if a multi-master architecture have to is built on SPI. The only problem i²c when building a system was a limited device address space on 7 bits, overcome with the 10-bits Extensi On.

From this point of view, I²c is a clear winner through SPI in sparing pins, board Routing and how easy it was to build an i²c Network.

-Throughput/speed:

If data must be transferred at ' High speed ', SPI is clearly the protocol of choice, over-i²c. SPI is Full-duplex; I²c is not. SPI does not define no speed limit; Implementations often go over ten Mbps. I²c is limited to 1Mbps in Fast mode+ and to 3.4 Mbps in high speed mode–this Las T one requiring specific I/O buffers, not always easily available.

-Elegance:

It is often said that I²c is much more elegant than SPI, and so this last one was a very ' rough ' (if not ' dumb ') protocol . Actually, we tend to think the protocols is equally elegant and comparable on robustness.

I²c is elegant because it offers very advanced Features–such as automatic multi-master conflicts handling and built-in a Ddressing Management–on a very light infrastructure. It can be very complex, however and somewhat lacks performance.

SPI, on the other hand, are very easy to understand and to implement and offers a great deal of flexibility for extensions and variations. Simplicity is where the elegance of the SPI lies. SPI should is considered as a good platform for building custom protocol stacks for communication between ICs. So, according to the engineer's need, using SPI may need more work but offers increased data transfer performance and Almo St Total Freedom.

Both SPI and I²c offer good support for communication with low-speed devices, but SPI is better suited to applications in Which devices transfer data streams, while I²c is better at Multi Master ' register Access ' application.

Used properly, the protocols offer the same level of robustness and has been equally successful among vendors. EEPROM (electrically-erasable Programmable read-only Memory), ADC (Analog-to-digital Converter), DAC (Digital-to-analog Converter), RTC (real-time clocks), microcontrollers, sensors, LCD (Liquid Crystal Display) controllers is largely Availa ble with i²c, SPI or the 2 interfaces.

Conclusions

In the world of communication protocols, I²c and SPI is often considered as ' little ' communication protocols compared to Ethernet, USB, SATA, Pci-express and others, that present throughput in the X100 megabit per second range if not gigabit p ER second. Though, one must not forget what each protocol are meant for. Ethernet, USB, SATA is meant for ' outside the box communications ' and data exchanges between whole systems. When there are a need to implement a communication between integrated circuit such as a microcontroller and a set of Relati Vely Slow peripheral, there is no point at using any excessively complex protocols. There, I²c and SPI perfectly fit the bill and has become so popular, it's very likely, any embedded system Engin EER would use them during his/her career.

"Turn" SPI & I²c