Engineering Guides
I²C vs SPI for Pressure Sensors — Pick the Right Bus or Hate Your Layout Later
You've picked your pressure sensor. You know the range, the accuracy, the package. Then you see two variants on the ordering page: I²C и SPI. Same sensor. Same price. Different four letters. Here's how to decide — with real numbers, not textbook theory.
The Two-Minute Refresher
Skip this if you've wired up both buses before. If you haven't, here's enough to follow the rest of the article:
- Wires: 2 — SDA (data) + SCL (clock)
- Signal type: Open-drain, pulled high with resistors
- Addressing: 7-bit address per device
- Direction: Half-duplex
- Speed: 100 kHz / 400 kHz / 1 MHz / 3.4 MHz
- Control: Master-initiated; slaves respond only when addressed
- Wires: 4 — MOSI, MISO, SCLK + 1× CS per device
- Signal type: Push-pull CMOS
- Addressing: None — CS line selects the device
- Direction: Full-duplex
- Speed: 1 MHz to 50 MHz
- Control: Master controls clock; no clock stretching
At this point you might think: "SPI is faster, so SPI wins, end of article." Not quite — speed almost never matters for a pressure sensor. Here's why.
The Speed Argument That Doesn't Matter
A typical MEMS pressure sensor takes a reading every 1 to 100 milliseconds — the ADC conversion time dominates, not the bus speed. Even at 1 ms per sample (1 kHz sampling), you're pushing maybe 48 bits per reading. That's 48 kbps.
I²C at 400 kHz transfers ~320 kbps after overhead. SPI at 1 MHz transfers 1 Mbps. Either one is 7× to 20× faster than the sensor's data rate. Unless you're sampling at ultrasonic frequencies — which you're not, because pressure doesn't change that fast — bus speed is irrelevant. The sensor is the bottleneck, not the wires.
Bottom line on speed: doesn't matter. The sensor's ADC is the limiting factor. Decide on other grounds.
Pin Count: The Argument That Actually Matters on Small Boards
| Scenario | I²C pins used | SPI pins used |
|---|---|---|
| 1 sensor | 2 (SDA + SCL) | 4 (MOSI + MISO + SCLK + CS) |
| 2 sensors | 2 (shared bus) | 5 (shared bus + 2× CS) |
| 4 sensors | 2 (shared bus) | 7 (shared bus + 4× CS) |
If your MCU is an STM32 with 80 GPIOs — who cares. But on an ESP32-C3 with 15 usable GPIOs running a display, BLE, two buttons, and an SD card — those 2 extra pins for SPI sting. I²C saves you pins regardless of how many sensors share the bus.
Note: I²C costs you two pull-up resistors. SPI costs none. Two 4.7 kΩ 0402 resistors cost about $0.002 total and take up 2 mm² of board space — not nothing, but close to it.
Bottom line on pins: I²C wins when GPIOs are tight. With a pin-rich MCU, the advantage disappears — decide on other factors.
Multi-Sensor Designs: Where I²C Actually Shines
Three pressure sensors on the same PCB — one barometric reference, one tank level, one pump outlet. With I²C: assign each sensor a different address, wire SDA and SCL in parallel, done. Two traces. Three sensors. Zero extra MCU pins. With SPI: three separate CS lines on top of the shared MOSI/MISO/SCLK — six wires total.
Watch out: I²C devices need unique addresses. Most pressure sensors offer exactly two addresses (a pin strapped high or low). That means you get two sensors on the bus before needing an I²C multiplexer like the TCA9548A — which adds ~$0.50 and a few mm². SPI has no such limit; just add a CS line per sensor.
Bottom line on multi-sensor: I²C wins for wiring simplicity up to two identical sensors. Beyond that, use SPI or an I²C mux — neither is clearly better, it's a layout call.
Noise Immunity: The One Where SPI Pulls Ahead
High-resolution pressure sensors measure changes as small as 0.03 hPa — roughly the weight of a mosquito landing on your desk, translated into an electrical signal. At that resolution, noise matters.
I²C noise characteristics
Open-drain lines with pull-up resistors produce RC ramp edges, not clean CMOS transitions. Pull-up values are a compromise: too strong wastes power; too weak makes rise time sluggish and opens a window for noise coupling. In a noisy environment — next to a motor driver, switching regulator, or anything with PWM — I²C can glitch. The protocol has no built-in error detection beyond the ACK bit (some sensors add a CRC byte to the payload, which helps).
SPI noise characteristics
Push-pull CMOS drivers actively drive both high and low states. Edges are sharp. The CS line gates exactly when the slave should listen — ignoring everything on the bus the rest of the time. Inherently better SNR.
In practice, a clean PCB layout with short traces, a ground plane, and bypass caps will keep I²C happy on most designs. But if your sensor is on a cable a metre away from the MCU, or shares an enclosure with anything that switches amps of current — SPI's noise immunity is a genuine advantage.
Bottom line on noise: SPI is the safer choice in electrically hostile environments. On the same PCB a few centimetres from the MCU, I²C is fine.
Firmware Complexity: The Tiebreaker Nobody Talks About
I²C firmware
A state machine. Start condition → send address + R/W bit → wait for ACK → read/write register pointer → read/write data → stop condition. Every step has a timeout, a retry path, and a "what if the sensor holds SDA low because it's still converting" case. Most MCU vendors provide a HAL. Most of those HALs have edge-case bugs you'll discover at 11 PM.
SPI firmware
Assert CS → shift bytes → de-assert CS. That's it. The sensor doesn't get to say "I'm not ready" by clock-stretching or NAKing. The master controls the clock; the slave responds or stays silent.
Debugging pain: When SPI doesn't work, you probe four lines with a logic analyzer and see exactly what's happening. When I²C doesn't work, you stare at a screen full of NAKs and wonder if it's the pull-up values, the address, the timing, or bus capacitance. An $8 logic analyzer solves both — but I²C will burn more of your time.
Bottom line on firmware: SPI is less annoying bare-metal. With a HAL or library, it's roughly a wash. I²C takes longer to debug when it breaks.
Power Consumption: Both Are Rounding Errors
A 400 kHz I²C bus with 4.7 kΩ pull-ups burns about 0.7 mA while active. SPI burns essentially nothing at the bus level — purely CMOS switching current at these speeds (microamps).
Context: the pressure sensor element and ADC draw ~5 µA at 1 Hz sampling and 0.3 µA in standby. Whether the bus burns 0.5 mA or 0.05 mA for the 2 ms it takes to read a sample — the energy difference is picowatt-hours. Your BLE radio burns more power sending one "hello" packet than the bus choice will save across the sensor's entire operating lifetime.
Bottom line on power: don't choose I²C or SPI based on power. The difference is too small to matter. Decide on pins, noise, or firmware sanity instead.
Decision Flow — Four Questions, No Matrix
1How many identical sensors on one bus?
No advantage either way. Move to Question 2.
Two addresses, two wires. Unless the sensors are far apart — then SPI.
Unless you enjoy reading I²C multiplexer datasheets.
2How far is the sensor from the MCU?
I²C is fine at board level with clean layout.
Or I²C with a differential buffer (PCA9615). I²C was never designed for cables.
Use 4–20 mA or RS-485. You're in industrial transmitter territory.
3What's the EMI environment?
Clean layout with bypass caps keeps I²C happy.
Push-pull drivers and CS gating will prevent phantom readings.
4Are you the one writing the driver?
The abstraction makes the difference negligible. Use what the rest of the board uses.
Fewer states, no clock stretching, no address conflicts.
Most hobbyist sensor libraries default to I²C. Check the library first.
The "Why Not Both" Card
Dual InterfaceSome sensors ship with both I²C and SPI on the same die, selectable via a pin strap or register bit. This is genuinely useful in two scenarios:
Prototyping flexibility
Start with I²C on an Arduino or breakout board because it's easier to wire. When you spin your own PCB, switch to SPI if your layout benefits from it. Same sensor, same firmware logic, just a different HAL call.
Production SKU flexibility
One PCB design, different SKUs. One SKU uses I²C because it shares the bus with a temperature/humidity sensor. Another needs SPI for longer trace runs to a remote sensor board. You don't redesign anything — change a BOM line and a resistor strap.
If your sensor candidate doesn't support both buses, it's not a dealbreaker. But having the option is one of those things you don't appreciate until you're re-spinning a board at 2 AM.
Side-by-Side Summary
| Factor | I²C | SPI | Winner |
|---|---|---|---|
| Wire count | 2 | 4 + 1 per sensor | I²C |
| Speed | Up to 3.4 MHz | Up to 50 MHz | Tie — sensor ADC is the bottleneck |
| Multi-sensor (same type) | Max 2 without mux | Unlimited (one CS per sensor) | SPI beyond 2 sensors |
| Noise immunity | Open-drain, RC edges | Push-pull CMOS, sharp edges | SPI |
| Firmware complexity | State machine, ACK/NAK, timeouts | Assert CS, shift bytes, done | SPI (bare-metal); Tie (with HAL) |
| Debug difficulty | Harder — NAK hunting | Easier — straightforward signals | SPI |
| Потребляемая мощность | ~0.7 mA (pull-ups active) | ~0 mA (no pull-ups) | Tie — delta is picowatt-hours |
| Cable runs | Not recommended >200 mm | Tolerates longer traces | SPI |
| External components | 2× pull-up resistors | None | Tie — 2× 0402 resistors ≈ $0.002 |
TL;DR
Not sure which interface fits your design? Tell us your MCU, your board constraints, and your environment — we'll point you at the right part, usually within an hour.
Get in Touch →