Communication Protocols in Embedded Systems
Communication protocols are central to how we understand and develop embedded systems and devices. A communication protocol is a defined system that allows two or more entities in a communications system to talk to each other. Communication protocols define the rules of communication, syntax, semantics, and how the system will recover from errors. Just like humans can communicate with others using different languages, communication protocols facilitate data transfer between hardware, software, or a combination of the two.
There are many different types of communication protocols used in computer hardware today. Commonly known examples include USB (Types A and B, and the recently released Type-C), Ethernet, and Bluetooth. A communication protocol establishes rules that govern the transmission of data and information between separate hardware and/or software systems. A protocol addresses factors such as:
- Data formats for data exchange
- Address formats for data exchange
- Address mapping
- Routing
- Detection of data transmission errors
- Acknowledgements of received data, failed data transfers, or other status changes
- Direction of information flow
- Sequence control
- Flow control
Communication protocols can be wired (requiring a physical interface to transmit data) or wireless (requiring no physical interface to transmit data). Wired protocols can facilitate internal communication (between devices on the same bus), or external communication (between devices on different buses)
If your embedded systems project involves programming a microcontroller to interface with peripheral devices on a PCB, you will need to choose a wired communication protocol that effectively facilitates internal communication for your device. The most common communication protocols that can fulfill these criteria for integrated circuits are the I2C (inter-integrated circuit) protocol and the SPI (serial peripheral interface) protocol. It’s important to understand their differences in order to choose the best protocol for your project.
In this week's blog post, we're taking a deep dive into the I2C vs SPI debate. We'll break down the features and benefits of both the I2C and SPI protocols, explain the difference between I2C and SPI, and give our best recommendation for how you should choose between the I2C vs SPI communication protocols for your next embedded device engineering project. Let's start with a basic overview of each protocol.
What is the I2C Protocol?
The I2C communication protocol was first created by Philips Semiconductor in 1982, and since 2006, developers and embedded engineers have been permitted to implement the protocol without paying any licensing fees.
I2C is a two-wire communication protocol that is commonly used to connect low-speed devices like microcontrollers, I/O interfaces, A/D and D/A converters, EEPROMs, and other peripherals in embedded systems. One of these wires, known as SCL (Serial Clock) carries the clock signal, while the other wire, known as SDA (Serial Data) allows master and slave devices on the bus to send and receive data. The I2C protocol allows for multiple slave devices to be connected to a single master device, or for multiple masters controlling one or more slave devices.
In general, the I2C protocol is best applied on projects where simplicity of design and low manufacturing costs are more important than speed. The standard data transfer rate associated with the I2C protocol is just 100 kbps, although speeds of up to 5 Mbps are possible with certain types of devices that are configured to use I2C in "fast mode" or "ultra-fast mode".
What is the SPI Protocol?
The SPI protocol was developed by Motorola in the mid-1980s, with the earliest SPI microcontrollers modeled after the Motorola 68000 microprocessor, which enjoyed widespread use in early Macintosh computers, arcade games like the Atari ST, and laser printers.
SPI is a four-wire communication protocol that can be used to connect microcontrollers to a versatile range of devices on the same serial bus, including temperature and pressure sensors, A/D and D/A converters, memory devices, LCDs, and more. The four-wire configuration represents a very logical approach to facilitating data transfer on the serial bus. Each of the four wires corresponds to a specific logic signal:
- SCLK (Serial Clock): The Serial Clock wire carries the clock signal from the master device to other devices on the serial bus.
- MOSI (Master Output, Slave Input): The MOSI wire carries data output from the master device to the slave devices on the serial bus
- MISO (Master Input, Slave Output): The MISO wire carries data output from the selected slave device to the master device or micro controller on the serial bus
- SS (Slave Select): On an SPI bus, there must be one master device, but there can be multiple slave devices. The master device can exchange data with all of the slave devices, but the slave devices can only send data to the master - not to each other. The master device uses the Slave Select wire to select which slave device on the bus it will be communicating with before sending a data transmission.
The SPI protocol was developed to enable high-speed initialization of device peripherals on the same integrated circuit as the microcontroller. In general, the SPI protocol is best applied on projects where speed is more important than minimizing the cost of production and when there are no constraints in using additional wires needed to facilitate SPI communication. You may also want to explore the differences between UART and SPI for embedded systems.
Comparing I2C and SPI (I2C vs SPI) Protocols
Now that we've clearly defined the I2C vs SPI protocols, let's take a closer comparative look and see what similarities they share and how they're different.
I2C vs SPI Communication Protocols - What’s the Difference?| Feature | Description | I2C Protocol | SPI Protocol |
| Wires | The number of wires required for each communication protocol to function. | 2 | 4+ |
| Speed | The maximum speeds available for each protocol. | 100 kHz standard speed
400 kHz fast mode 1 MHz fast mode plus 3.4 MHz high speed mode 5 MHz ultra-fast mode |
The SPI protocol has no maximum speed. Speeds in excess of 100 MHz have been achieved. |
| Power | The amount of power required to run each protocol. | Draws more power than SPI | SPI protocol is better suited for low power applications |
| Pricing/Cost | Cost of implementation for similar projects | I2C is cheaper to implement because there is no need for chip select or arbitration logic | SPI protocol is costlier to implement because it requires more on-chip real estate |
| Clock Stretching | Clock stretching is a feature where slave devices can modify the main bus clock when needed. | When a slave device cannot process data quickly enough, it can slow down the clock with clock stretching to slow the bitrate and help it keep up. | Slave devices in SPI protocol do not use the clock stretching feature. |
| Noise Immunity | Noise immunity describes how well a device or system can function in the presence of noise. | Less susceptible to noise. | More susceptible to noise. |
| Configurations | What configurations of master and slave devices are supported by the protocol? | Multi-master protocol, allows any number of master and one or many slave devices | Single-master protocol, must use one master device and either one or many slave devices |
| Data Verification | Can the protocol detect errors? Does it verify the receipt of data by slave devices after the master device communicates? | Uses the acknowledge bit after each byte, ensures that sent data is received by the slave device | No standardized method for verifying whether data was correctly received or not, does not support acknowledge bit |
| Message Size | What message size is supported by the protocol? | I2C communication uses messages that are separated into frames. A 7- or 10-bit frame routes the message and data is transmitted in 8-bit frames separated by acknowledge bits that verify receipt of the data. | SPI communication works using shift registers. Messages can be 8-bit, but twelve or sixteen-bit data transmissions are also possible. |
| Duplex | Does the protocol allow for bi-directional, simultaneously communication between devices? | Half duplex mode – individual wires can communicate data in both directions, but not at the same time | Full duplex mode – individual wires can simultaneously communicate data in both directions |
Advantages and Limitations of I2C and SPI
Summarizing the comparisons between I2C and SPI, there are multiple benefits and limitations in using each for your own design.
I2C is beneficial for its simplicity and ease of adding extra devices onto the bus. Because I2C only requires two wires to communicate, this protocol is well-suited for boards with many devices. In turn, this helps reduce the cost and complexity of the circuit. Additionally, I2C offers flow control and error handling.
However, I2C uses slave addressing and acknowledgements within its communication scheme, which can be a disadvantage in certain instances where it adds additional complexity and overhead.
SPI on the other hand, is superior when it comes to speed. SPI devices use push-pull drivers that offer superior speed and signal integrity when compared to the open drain lines employed in the I2C protocol. Additionally, SPI supports full-duplex communication where both the master and slave can send data at the same time via the MOSI and MISO lines.
Unlike I2C however, adding additional devices to the bus can increase the board complexity. This is because each slave needs its own Slave Select line, so the number of wires needed to communicate increases with each device.
Choosing Between I2C and SPI
By now, you should have enough information to decide between I2C vs SPI communication protocols for your embedded device engineering project. If you can afford the additional cost, it's often better to go with the SPI protocol unless you have a compelling reason to choose I2C. These could include factors like:
- The project requires transmission distances of longer than 10 meters where noise and interference are significant factors
- The project requires multiple master devices, a configuration not supported by SPI protocol
- On-chip real estate is at a premium and you would prefer to have just two wires rather than four, as with the I2C interface protocol.
Once you've chosen between the I2C vs SPI protocols for your embedded systems project, you'll need to invest in the right diagnostic tools that can reduce your time-to-market and validate the correct performance of your product.
Tools to Help with I2C and SPI Developments
Total Phase offers numerous development tools for both I2C and SPI protocols, including host adapters and protocol analyzers.
I2C and SPI Host Adapters
Host adapters allow engineers to program devices as well as emulate master and slave devices to test and validate systems.
The Aardvark I2C/SPI Host Adapter is a general-purpose host adapter that can be used as an I2C or SPI master or slave device. As an I2C master and slave, it can support up to 800 kHz. As an SPI master it can support up to 8 MHz and as an SPI slave it can support up to 4 MHz.
The Cheetah SPI Host Adapter was designed as a high-speed programming device. It can quickly program SPI-based EEPROMs and Flash memory. As an SPI master, it can signal up to 40 MHz.
The Promira Serial Platform is Total Phase’s most advanced serial device. Through its field-upgradeable design, users can select from a range of I2C and SPI applications that provide varying levels of speeds and other functionalities to fit a variety of project requirements. As an I2C device, users can signal up to 3.4 MHz as a master or slave; as an SPI device, users can signal up to 80 MHz as a master and 20 MHz as a slave.
I2C and SPI Protocol Analyzers
Protocol Analyzers allow engineers to monitor and debug communication on the bus between devices.
The Beagle I2C/SPI Protocol Analyzer allows users to non-intrusively monitor an I2C bus up to 4 MHz and an SPI bus up to 24 MHz.
For more information on our tools, including additional features and pricing details, contact our sales team at sales@totalphase.com.