I2C vs. SPI vs. UART: How to Layout These Common Buses

Zachariah Peterson
|  Created: September 27, 2020  |  Updated: October 27, 2020
I2C vs SPI vs UART for LCD screen

If you’re building a dev board for your project or using a common MCU, you’ll find many protocols for communicating other active components. Standards like USB and Ethernet are built into most controllers for working with computer peripherals. Still, protocols like I2C, SPI, UART, and others are used to interface with downstream MCUs or programmable ICs. The differences between I2C vs. SPI vs. UART buses are simple, and any designer working with an MCU should know how to set up routing and layout for these protocols.

These protocols are slower speed signaling standards, so you almost always won’t need to worry about things like impedance control or transmission line behavior if you are working with these protocols. However, some important design points must be considered when ensuring your bus lines’ signals are read correctly at your receivers. There is also the matter of addressing, but the particular product and your code can handle this point. For now, let’s look at how these three common protocols can be used in your PCB layout and some important points to maintain signal integrity.

Differences Between I2C vs. SPI vs. UART

Everything from 8-bit to 32-bit MCUs will use at least one of these protocols alongside GPIOs for programmability and sending signals to simple peripherals. These three serial protocols are bus protocols; I2C and UART use addressing schemes, while SPI is address-less. Although SPI is address-less, it is a bus protocol and can still be used to select downstream devices to receive data.

I2C Protocol

I2C (pronounced I-squared C, or sometimes IIC for inter-integrated circuit) uses two lines (standard, fast, and fast-plus modes) to control other devices; one line is a clock line (SCL), while the other is a data line (SDA). It comes in three modes, which are summarized in the table below. Note that the rise/fall time values assume the typical series resistors are installed at the I/Os.

Mode

Data rate/clock speed

Max. rise/fall time

Min. rise/fall time

Directionality

Standard

100 kHz

1000 ns

-

Bidirectional

Fast

400 kHz

300 ns

20 ns*

Bidirectional

Fast-plus

1 MHz

300 ns

20 ns*

Bidirectional

High speed

3.4 MHz (100 pF bus)

1.7 MHz (400 pF bus)

120 ns**
240 ns**

15 ns**
30 ns**

Bidirectional

Ultra-fast

5 MHz

50 ns

25 ns

Unidirectional


*Assumes VDD/VCC = 5.5 V. Scales down linearly if VDD/VCC is lower
**Divide these values by 2 for the clock line

Note that ultra-fast mode is the only mode where communication is used for downstream write operations only. This mode is also important as it helps us see when the bus impedance will need to be matched, which in practical terms is almost never. If we take a very conservative 10% limit on the critical line length, we find that the crucial length in these lines is 0.32 m, which is much longer than the size of most boards that will use I2C. If we use the knee frequency for the minimum rise/fall time with a 10% limit on critical length, we come to a much longer value of 0.92 m. We should take the more conservative number of 0.32 m for ultra-fast mode; any I2C line shorter than this value will not behave as a transmission line, and we only need to worry about the termination scheme.

The important points in termination are to select the right pull-up and series resistors. The pull-up resistors and the capacitance of the VDD/VCC line bus form a discharging and charging RC circuit, which is what provides a signal to the receiver when the driver switches. The pull-up resistor values (Rp) for the signal and clock lines must obey the following inequality:

 I2C pull-up resistor value
I2C pull-up resistor value.

 

PCB layout topology for I2C
I2C layout topology.

The bus capacitance is determined using the standard formulas for the VCC bus impedance, which is calculated using the same equations you would use for a transmission line (either microstrip or stripline). You can then solve for the bus capacitance using the impedance and the propagation delay for the line. The series resistors are optional under the I2C standard, although they can be included to protect the devices from voltage spikes and slow down the rise/fall times. Look at page 59 of the I2C standard to determine the right series resistor value to pair with your pull-up resistor value.

SPI Protocol

The SPI protocol is similar to I2C. A total of 4 lines are used in this bus, and components can be arranged in two possible modes. If a single controller device is used to trigger a single downstream device, the topology is simply point-to-point. Triggering multiple devices depends on the number of chip-select outputs provided by the driver (standard mode). The second mode uses daisy-chaining, where a single device-select output successively triggers each device in the daisy chain.

Unlike I2C, the various signaling parameters in SPI are highly configurable. Unless you are running an extremely fast interface, you can approximate the signal level across the interconnect as DC as you’ll be below the critical length for transmission line behavior. You can then use a series resistor to terminate the driver’s low impedance output and ensure maximum power transfer. The RC discharging method with the trace capacitance shown above can control the output current and rise/fall times from your interface.

UART Protocol

The universal asynchronous receiver-transmitter (UART) is similar to I2C. These interfaces have a maximum data rate of ~5 Mbps. UART devices are also easy to work with as there is no clock sent between devices; everything is asynchronous. Note that each UART device’s internal (system) clock must run at some multiple of the baud rate (i.e., each bit is sampled N times). Only two wires are used for communication between a single controller device and a single downstream device.

Note that the data format, signal levels, and baud rate of a UART device are configurable with an external driver circuit. Unfortunately, this also means there are few hard and fast rules for routing and layout of UART devices. Follow the standard high-speed design guidelines for determining when termination is needed by looking at the transition to transmission line behavior (see the article I linked above). A typical termination method to reduce overshoot is a series termination. Note that UART may idle at high or low levels, and pull-up resistors may be needed to set the required idle level; be sure to check your component specifications before adding pull-up resistors.

You can read more about the difference between timing in synchronous and asynchronous buses in this 2018 AltiumLive presentation by Max Seeley.

Summary

If SPI and UART rules seem a bit vague, it’s because you have more freedom to design your interface at the firmware level. Once any of these standards run at fast edge rates, they are susceptible to crosstalk, just like high-speed signaling standards. However, because you have plenty of flexibility in your specification, you can usually design traces to have lower inductance and reduce inductive crosstalk. You have some flexibility in routing these signals and making them very easy to work within your next digital system.

When designing digital systems with common signaling standards, you can design for the differences between I2C vs. SPI vs. UART with the design rules in Altium Designer®. The Layer Stack Manager and the integrated 3D field solver from Simberian uses your board geometry and trace geometry to extract your bus capacitance and parasitics in your signal lines.

Altium Designer on Altium 365 delivers an unprecedented amount of integration to the electronics industry until now relegated to the world of software development, allowing designers to work from home and reach unprecedented levels of efficiency.

We have only scratched the surface of what is possible to do with Altium Designer on Altium 365. You can check the product page for a more in-depth feature description or one of the On-Demand Webinars.

About Author

About Author

Zachariah Peterson has an extensive technical background in academia and industry. He currently provides research, design, and marketing services to companies in the electronics industry. Prior to working in the PCB industry, he taught at Portland State University and conducted research on random laser theory, materials, and stability. His background in scientific research spans topics in nanoparticle lasers, electronic and optoelectronic semiconductor devices, environmental sensors, and stochastics. His work has been published in over a dozen peer-reviewed journals and conference proceedings, and he has written 1000+ technical blogs on PCB design for a number of companies. He is a member of IEEE Photonics Society, IEEE Electronics Packaging Society, and the American Physical Society, and he currently serves on the INCITS Quantum Computing Technical Advisory Committee.

most recent articles

Back to Home