Serial communication II: SPI and I²C

A UART needs no clock wire, but it pays for that with tight timing tolerances and low speed. For chips on the same board, a shared clock is cheap, and two synchronous serial buses dominate. The serial peripheral interface, SPI, uses separate data lines in each direction and a chip-select line per device, and runs at tens of megabits per second. The inter-integrated circuit bus, I²C, uses only two shared wires for any number of devices, with addresses and acknowledgements built into the protocol, at a few hundred kilobits per second. Between them they connect almost every sensor, memory, display controller, converter and power-management chip in embedded systems. This lesson explains both, how to choose between them, how to size I²C pull-up resistors from the bus capacitance, how to estimate transaction times, and how to make both buses robust.

On the NS-4, the radar module streams raw frames to the microcontroller over SPI, and a temperature sensor and a 32 KB ferroelectric memory share an I²C bus. Two problems wait for Jonah. The NS-5 will classify vehicles from radar frames on the node, which needs eight times the SPI throughput. And field units occasionally lock up the I²C bus after a brownout, so that the temperature reads fail until the next full power cycle.

SPI: signals and transfers

SPI connects one controller to one or more peripherals with four signals: a serial clock driven by the controller; controller-out peripheral-in, carrying data to the peripheral; controller-in peripheral-out, carrying data back; and an active-low chip select for each peripheral. Older documents call the controller the master and the peripheral the slave, and the data lines MOSI and MISO. The controller pulls one chip select low, toggles the clock, and on each clock edge both sides shift one bit out and one bit in. SPI is therefore inherently full duplex: every transfer exchanges bytes in both directions, and to read, the controller must send something, often zeros or a dummy byte.

SPI has no protocol beyond this. There are no addresses, no acknowledgements and no error checks; the meaning of the bytes is defined entirely by each peripheral's datasheet. A typical peripheral expects a command byte, sometimes followed by an address, and then data in or out while chip select remains low. Raising chip select ends the transaction and often triggers an action, such as starting a conversion or committing a write.

The four SPI modes combine clock polarity, whether the clock idles high or low, with clock phase, whether data are sampled on the first or second edge of each clock cycle. Modes 0 and 3 are the most common. A wrong mode often appears to almost work, with data shifted by one bit, so that values come out doubled or halved or with the top bit missing. Bit order is another setting: most devices send the most significant bit first, unlike a UART. Word size, usually 8 or 16 bits, and the minimum delays between chip select and the first clock edge complete the configuration.

SPI speed and throughput

SPI clocks of 10 to 50 MHz are common, limited by the peripheral, the microcontroller's SPI block and, above all, the board. At high clock rates, the round-trip delay through the controller's output, the trace, the peripheral's clock-to-output delay and back must fit inside half a clock period for the controller to sample the returned bit correctly. A peripheral with a 15 ns clock-to-output delay and a total trace and buffer delay of 10 ns limits reads to about 20 MHz. Writes are less constrained because the data travel with the clock.

Throughput also depends on how the processor feeds the bus. Writing each byte from a polling loop leaves gaps between bytes while the code checks flags; at 16 MHz a byte takes only 0.5 µs, so even a short loop overhead halves the rate. DMA, as lesson 7 explained, keeps the shift register busy continuously. Many controllers also support quad SPI, with four data lines, for external flash memories, multiplying throughput by four for memory-mapped code or data.

/* Read one radar frame by SPI with DMA. The controller must transmit to receive, so a
   second DMA channel sends a constant dummy byte while the first collects the samples. */
static uint16_t frame[2048];
static const uint16_t dummy = 0;

void radar_read_frame(void)
{
    gpio_clear(RADAR_CS);
    spi_send16(SPI1, RADAR_CMD_READ_FRAME);
    dma_setup(DMA_RX_CH, &SPI1->DR, frame, 2048, DMA_MINC | DMA_16BIT | DMA_TCIE);
    dma_setup(DMA_TX_CH, &SPI1->DR, &dummy, 2048, DMA_16BIT);   /* no MINC: same word */
    spi_enable_dma(SPI1);
}

void DMA_RX_IRQHandler(void)               /* frame complete */
{
    dma_clear_flags(DMA_RX_CH);
    while (SPI1->SR & SPI_SR_BSY) { }       /* wait for the last bits to finish */
    gpio_set(RADAR_CS);
    frame_ready = 1;
}

I²C: two wires, many devices

I²C uses two lines, serial clock SCL and serial data SDA, shared by every device on the bus. Both lines are open-drain: devices can only pull them low, and pull-up resistors return them high. This wired-AND arrangement means any device can hold a line low without conflict, which the protocol uses for acknowledgements, clock stretching and arbitration between controllers. Each peripheral has a 7-bit address, set by its manufacturer and often partly by pins, so up to about 112 devices can share a bus after reserved addresses. Standard mode runs at 100 kHz, fast mode at 400 kHz and fast-mode plus at 1 MHz.

A transaction begins with a start condition: SDA falls while SCL is high. Normally SDA may change only while SCL is low, so a change while SCL is high is a unique marker. The controller then sends the 7-bit address and a direction bit, 0 for write and 1 for read. On the ninth clock, the addressed peripheral pulls SDA low to acknowledge; if no device responds, SDA stays high, a not-acknowledge, which tells the controller the device is absent or busy. Data bytes follow, each acknowledged by the receiver. A read usually begins with a write of the register address, then a repeated start, which is a start without a preceding stop, and the address again with the read bit. The controller acknowledges every byte it reads except the last, then sends a stop condition: SDA rises while SCL is high.

Pull-up resistors and rise time

Because I²C lines are pulled high only by resistors, rising edges are exponential curves whose time constant is the pull-up resistance times the total bus capacitance, made up of each device's pin capacitance, the traces and any cable. The I²C specification defines rise time from 30 percent to 70 percent of the supply, which for an RC curve is 0.8473 times the time constant. It sets a maximum rise time of 1,000 ns in standard mode and 300 ns in fast mode, and a maximum bus capacitance of 400 pF. That gives an upper limit on the pull-up resistance. The lower limit comes from the current a device can sink while holding the line below the low-level threshold: at least 3 mA at 0.4 V in standard and fast modes.

# I2C pull-up range versus bus capacitance, and the rise time of a chosen resistor
VDD, VOL, IOL = 3.3, 0.4, 3e-3
modes = {"standard 100 kHz": 1000e-9, "fast 400 kHz": 300e-9}
r_min = (VDD - VOL) / IOL
print(f"R_min = {r_min:.0f} ohm (sink-current limit, all capacitances)")
for cb_pf in (50, 120, 200, 400):
    cb = cb_pf * 1e-12
    row = f"Cb = {cb_pf:3d} pF:"
    for name, tr in modes.items():
        r_max = tr / (0.8473 * cb)
        ok = "ok" if r_max > r_min else "impossible"
        row += f"   {name}: R_max = {r_max/1000:5.2f} kohm ({ok})"
    print(row)
R = 2200
for cb_pf in (120, 200):
    print(f"2.2 kohm at {cb_pf} pF: rise time {0.8473*R*cb_pf*1e-12*1e9:.0f} ns")

R_min = 967 ohm (sink-current limit, all capacitances)
Cb =  50 pF:   standard 100 kHz: R_max = 23.60 kohm (ok)   fast 400 kHz: R_max =  7.08 kohm (ok)
Cb = 120 pF:   standard 100 kHz: R_max =  9.84 kohm (ok)   fast 400 kHz: R_max =  2.95 kohm (ok)
Cb = 200 pF:   standard 100 kHz: R_max =  5.90 kohm (ok)   fast 400 kHz: R_max =  1.77 kohm (ok)
Cb = 400 pF:   standard 100 kHz: R_max =  2.95 kohm (ok)   fast 400 kHz: R_max =  0.89 kohm (impossible)
2.2 kohm at 120 pF: rise time 224 ns
2.2 kohm at 200 pF: rise time 373 ns

The table shows why long or heavily loaded buses are hard. At 400 pF, the fast-mode limit falls to 885 Ω, below the 967 Ω sink-current limit, so no resistor works and the bus cannot run at 400 kHz. Options then include slowing to standard mode, splitting the bus with a buffer or multiplexer, using a bus accelerator that actively drives rising edges, or choosing devices rated for fast-mode plus, which can sink 20 mA. The pull-up current is also a cost on battery-powered nodes, although it flows only while a line is low, so its average depends on traffic.

I²C transaction time

I²C's simplicity costs time. Each byte takes nine clocks with its acknowledge, and every transaction adds addresses, register pointers and start, repeated-start and stop conditions. Peripherals may also hold SCL low, called clock stretching, while they prepare data, which pauses the controller. These overheads make transaction times worth estimating before a design relies on them.

# Approximate I2C transaction times: each byte costs 9 clocks, each start/stop about 1 clock
def i2c_time(f_scl, nbytes, nstarts=1):
    clocks = 9 * nbytes + nstarts + 1      # starts (including repeated) plus one stop
    return clocks / f_scl
cases = {
    "temperature read: addr+W, reg, rpt start, addr+R, 2 data": (4 + 1, 2),
    "memory write of a 64-byte record: addr+W, 2 addr bytes, 64 data": (67, 1),
    "memory read of 64 bytes: addr+W, 2 addr, rpt start, addr+R, 64 data": (68, 2),
}
for name, (nbytes, starts) in cases.items():
    t100 = i2c_time(100e3, nbytes, starts)
    t400 = i2c_time(400e3, nbytes, starts)
    print(f"{name:66s} {1e6*t100:7.0f} us at 100 kHz  {1e6*t400:6.0f} us at 400 kHz")

temperature read: addr+W, reg, rpt start, addr+R, 2 data               480 us at 100 kHz     120 us at 400 kHz
memory write of a 64-byte record: addr+W, 2 addr bytes, 64 data       6050 us at 100 kHz    1512 us at 400 kHz
memory read of 64 bytes: addr+W, 2 addr, rpt start, addr+R, 64 data    6150 us at 100 kHz    1538 us at 400 kHz

A temperature read takes about 120 µs at 400 kHz, and writing a 64-byte record about 1.5 ms. Ferroelectric memory accepts writes at bus speed; an EEPROM on the same bus would add a 5 ms internal write cycle after each page, during which it ignores its address, and firmware must poll it with address-only transactions until it acknowledges again. The NS-4 writes one record per vehicle at worst a few times per second, so either memory is fast enough, but the ferroelectric part also tolerates far more write cycles, which matters for a counter that may write ten million records over its life.

Making I²C robust

The lock-up that Jonah is chasing is a well-known I²C failure. If the microcontroller resets in the middle of a read, perhaps from a brownout or the watchdog, a peripheral may be partway through sending a byte and holding SDA low for a 0 bit. The controller, freshly reset, sees SDA low and believes the bus is busy, or it tries to send a start condition and fails. The peripheral, which never saw the clocks finish, waits forever. Only a power cycle of the peripheral clears it, and the NS-4's sensor is powered from the always-on rail.

The standard cure is bus recovery at startup. Before enabling the I²C peripheral, firmware configures SCL as a GPIO output and SDA as an input, and toggles SCL up to nine times until SDA is released high. Each clock lets the stuck peripheral shift out one more bit; after at most eight data bits and the acknowledge slot, it releases SDA. Firmware then generates a stop condition by hand and hands the pins back to the I²C peripheral. Jonah adds this to the NS-4 boot sequence, and the field lock-ups stop.

/* I2C bus recovery: clock out a peripheral that is stuck holding SDA low. */
void i2c_bus_recover(void)
{
    gpio_mode(I2C_SCL, GPIO_OUT_OD);
    gpio_mode(I2C_SDA, GPIO_IN);
    for (int i = 0; i < 9 && !gpio_read(I2C_SDA); i++) {
        gpio_clear(I2C_SCL); delay_us(5);
        gpio_set(I2C_SCL);   delay_us(5);
    }
    /* generate a stop: SDA low then high while SCL is high */
    gpio_mode(I2C_SDA, GPIO_OUT_OD);
    gpio_clear(I2C_SDA); delay_us(5);
    gpio_set(I2C_SDA);   delay_us(5);
    gpio_mode(I2C_SCL, GPIO_AF_I2C);
    gpio_mode(I2C_SDA, GPIO_AF_I2C);
}

Other robustness measures matter too. Every I²C operation needs a timeout, so a missing or failed device produces an error, not a hung main loop; the NS-4's driver gives each transaction 10 ms. Not-acknowledge responses should be counted and reported. Devices with fixed addresses can collide, so address planning belongs in the schematic review. Long I²C runs off the board, for example to a sensor in another enclosure, pick up noise and add capacitance; differential bus extenders or a different interface are better there. Systems with several controllers on one bus rely on I²C's arbitration: a controller that sends a 1 but sees a 0 knows another controller is driving, and backs off. SMBus and PMBus, used in power supplies and battery packs, are closely related to I²C, adding timeouts, packet error checking and standardized commands.

Choosing between SPI and I²C

SPI is the choice for throughput and simplicity of timing; I²C is the choice when pins are scarce and many slow devices share a bus. Many products use both, as the NS-4 does. A third family, single-wire buses and newer two-wire standards that add in-band interrupts and higher speeds, appears in some sensors and mobile designs, but the principles of addressing, acknowledgement and rise time carry over.