I2C vs SPI: which sensor bus to use
Short answer: I2C uses two shared wires and gives every device an address, so it connects many slow parts, such as temperature, humidity and light sensors, with few pins. SPI uses a shared clock and two data lines plus one chip-select wire per device, and runs much faster, so it suits displays, SD cards, flash memory and fast sensors. For a handful of environmental sensors, use I2C; for anything that moves a lot of data, use SPI; when a part offers both, I2C is usually simpler unless you need the speed.
I2C vs SPI compared for sensor projects: wires and pull-ups, addresses against chip selects, speed, distance, power, and which bus suits each kind of part.
This article covers how I2C and SPI work, the wires each needs, addressing against chip selects, speed and distance, pull-up resistors and power, how to fix address clashes, which parts use which bus, a comparison table, and where UART fits. It does not cover register-level programming of a particular sensor, the I3C bus, or long-distance links, which belong on RS-485 or a radio.
I2C and SPI are the two buses that connect most sensors, displays and memory chips to a microcontroller. I2C runs everything over two shared wires and picks each device by an address; SPI uses a shared clock, a data line in each direction and a separate select wire for every device, and in exchange runs many times faster. Which one to use depends on how many parts you are connecting, how much data they move and how many pins you can spare. This guide explains how each bus works and when to choose it, and the sensors and hardware hub collects the guides on the boards and sensors at either end of the wires. If you are still choosing those parts, start with the overview of IoT sensors.
The short version
| I2C | SPI | |
|---|---|---|
| Wires | 2 shared: SDA (data), SCL (clock), plus ground | 3 shared: SCLK, MOSI, MISO, plus one chip select per device, plus ground |
| Selecting a device | 7-bit address sent on the bus | Pull that device’s chip-select line low |
| Direction | Half duplex: one direction at a time | Full duplex: data both ways on every clock |
| Typical speed | 100 or 400 kbit/s; 1 Mbit/s and above on some parts | Several Mbit/s to tens of Mbit/s |
| Confirmation | Receiver acknowledges every byte | None; the controller cannot tell if anyone listened |
| Extra parts | Pull-up resistors on both lines | None |
| Typical parts | Temperature, humidity, pressure, light, real-time clocks, small OLEDs | Displays, SD cards, flash memory, fast ADCs, radios, fast accelerometers |
How I2C works
I2C, short for Inter-Integrated Circuit, was created by Philips Semiconductors in 1982 for connecting chips inside televisions. Its successor company, NXP, still publishes the specification as user manual UM10204, and Texas Instruments’ application note Understanding the I2C Bus is a readable introduction to the electrical side. Since the 2021 revision it calls the device that runs the bus the controller and the others targets, replacing the older master and slave.
Every device on the bus connects to the same two lines: SDA, which carries data, and SCL, which carries the clock. Neither line is ever driven high. Each device can only pull a line low or let go of it, and a pull-up resistor on each line returns it to the high level when nobody is pulling. This open-drain design is what lets any device signal on a shared wire without two outputs fighting each other.
A transfer starts with a start condition, SDA falling while SCL is high. The controller then sends a 7-bit address and one bit saying whether it wants to write or read. The target with that address answers by pulling SDA low for one clock, the acknowledge bit. Data follows a byte at a time, each byte acknowledged by whichever side received it, and the transfer ends with a stop condition, SDA rising while SCL is high.
Seven address bits give 128 combinations, of which 16 are reserved, leaving 112 for devices. Each part’s address is set by its manufacturer, often with one or two pins that change the lowest bits so that two or four of the same part can share a bus.
The specification defines several speeds: Standard-mode at 100 kbit/s, Fast-mode at 400 kbit/s, Fast-mode Plus at 1 Mbit/s, and High-speed mode at 3.4 Mbit/s. Most sensors support the first two. The bus also has a limit on total capacitance, 400 picofarads in the standard and fast modes, which is what limits how many devices and how much wire it can drive.
How SPI works
SPI, the Serial Peripheral Interface, came from Motorola in the 1980s. Unlike I2C, it never had a single formal standard; it is a convention that chip makers follow, with small variations documented in each part’s datasheet.
The controller drives a clock line, SCLK, shared by every device. Two data lines are also shared: MOSI (controller out, peripheral in) carries data to the device, and MISO (controller in, peripheral out) carries data back. Many newer datasheets use the names COPI and CIPO, or SDO and SDI, for the same lines. Every device also has its own chip-select line, CS, which the controller pulls low to talk to that device; the others ignore the bus while their CS stays high.
On each clock pulse, one bit goes out on MOSI and one bit comes back on MISO at the same time, so SPI is full duplex. There is no address, no acknowledge and no start or stop condition: pulling CS low starts the transfer and releasing it ends it. Two settings, clock polarity (CPOL) and clock phase (CPHA), decide whether the clock idles high or low and on which edge data is read, giving four SPI modes numbered 0 to 3. The controller must use the mode in the part’s datasheet; mode 0 is the most common.
Because every line is driven actively in both directions, with no pull-up resistors slowing the edges, SPI can run far faster than I2C. Many sensors accept clocks of several megahertz, and memory chips and displays go much higher.
Speed, distance and power
Speed. For a temperature sensor read once a minute, the difference is irrelevant: a few bytes at 100 kbit/s take a fraction of a millisecond. It matters for parts that move a lot of data. Refreshing a color display, writing logs to an SD card, or reading an accelerometer thousands of times a second is comfortable on SPI and can saturate I2C.
Distance. Both buses were designed for wiring on a single circuit board or between boards a short distance apart. Long wires add capacitance, which slows I2C’s pulled-up edges until the bus fails, and add delay and ringing that break SPI at high clock rates. A sensor on a lead of a few tens of centimeters usually works; one on the other side of a room does not without help. For real distance, use a bus built for it, such as RS-485, or give the remote sensor its own microcontroller and radio.
Power. I2C’s pull-up resistors draw current whenever a line is held low, which happens on every zero bit and acknowledge. That is negligible for occasional reads and worth thinking about on a node that has to run for years on a battery, where larger pull-up values and short transfers help. SPI has no pull-ups on its data lines. In either case, the bigger saving usually comes from powering sensors down between readings, as covered in powering IoT sensors.
Pins and address clashes
Pins. I2C needs two pins however many devices share it. SPI needs three shared pins plus one per device, which adds up quickly on a small board. On the common development boards, the Arduino Uno has one I2C bus on pins A4 and A5 and one SPI bus on pins 10 to 13, while the ESP32 and the Raspberry Pi Pico each have two of each, and the ESP32 can route them to most pins.
Address clashes. Two I2C parts with the same fixed address cannot share a bus. The usual fixes, in order:
- Use the address pin. Many sensors have one. The SHT31 humidity sensor answers at 0x44 or 0x45 depending on its ADDR pin, and the BME280 at 0x76 or 0x77 depending on its SDO pin.
- Use the second I2C bus if the microcontroller has one.
- Add an I2C multiplexer, such as the TCA9548A, which splits one bus into eight and lets the controller switch between them, so up to eight identical parts can each sit on their own branch.
SPI has no such problem: each device gets its own chip select, so any number of identical parts can share the bus as long as there are pins for their selects.
Pull-ups on breakout boards. Many I2C breakout boards fit their own pull-up resistors. Connect several of them and the resistors end up in parallel, so the combined value drops and the lines are pulled up harder than intended. If a bus with many modules misbehaves, check the combined pull-up value and remove some.
Which bus for which part
Many parts decide for you by offering only one bus.
- Environmental sensors (temperature, humidity, pressure, gas, light) mostly use I2C. Of the three in the DHT22 vs SHT31 vs BME280 comparison, the SHT31 is I2C only, the BME280 supports both I2C and SPI, and the DHT22 uses neither: it has its own single-wire protocol.
- Displays. Small monochrome OLEDs come in both I2C and SPI versions; the SPI ones refresh faster. Color TFT displays are almost always SPI or a parallel interface, because of the amount of data.
- Storage. SD cards and serial flash chips use SPI.
- Motion sensors. Accelerometers and inertial units often offer both. Use SPI when sampling fast, for example for vibration, and I2C for occasional orientation readings.
- Radios and network chips. LoRa modules and many Ethernet controllers use SPI.
- Real-time clocks, port expanders, small ADCs and DACs are usually I2C.
When a part offers both, I2C is usually the simpler choice for a handful of slow sensors because it saves pins and wiring. Choose SPI when you need the speed, when you have several identical parts and no spare addresses, or when a long-running node benefits from not driving pull-ups.
Where UART fits
A UART is the third common interface, and it is often listed alongside these two. It connects exactly two devices, with a transmit line from each to the other’s receive line and no shared clock; both sides must agree on the baud rate in advance. It is the usual interface for GPS receivers, cellular modems, some particulate sensors and the debug console of most boards. When a UART needs to cover distance or connect several devices, its signals go through a transceiver onto RS-485, which is how most industrial instruments are wired.
Troubleshooting
I2C device not found. Run an I2C scanner sketch, which tries every address and lists those that acknowledge. If nothing answers, check the pull-ups, swap SDA and SCL if in doubt, and confirm the sensor’s supply voltage matches the board’s logic level. If the device answers at a different address than expected, check its address pin.
I2C works on the bench, fails in the enclosure. Longer wires have added capacitance. Shorten them, lower the bus speed to 100 kbit/s, or use stronger pull-ups within the parts’ limits.
SPI returns all ones or all zeros. Usually the wrong mode, a chip-select line that is not toggling, or MOSI and MISO swapped. Check the mode in the datasheet first.
One SPI device corrupts another. A device whose CS is left floating may answer when it should not. Make sure every chip select idles high, with a pull-up if the pin is not configured as an output at power-on.
For the parts at the end of these wires, browse the sensors and hardware guides, starting with the IoT sensors overview.
Written by the IoT Crest editorial team. Facts in this article follow the editorial policy: only well-established behavior is stated and no figures are invented.