Choosing Between I2C and SPI for Arduino Peripheral Communication

The Integration Dilemma: Pin Count vs. Throughput

When adding sensors, displays, or memory modules to an Arduino, you often face a choice between I2C (Inter-Integrated Circuit) and SPI (Serial Peripheral Interface). Choosing the wrong protocol can lead to a project that is either bottlenecked by slow data transfer or physically impossible to wire due to a lack of available GPIO pins.

The core decision rests on whether your priority is simplicity of wiring (I2C) or raw performance (SPI). If you are connecting a simple temperature sensor, I2C is usually sufficient. If you are driving a high-resolution TFT display or reading a high-speed Analog-to-Digital Converter (ADC), SPI is required.

Protocol Comparison Matrix

Feature	I2C (Wire)	SPI
Wire Count	2 (SDA, SCL)	4+ (MOSI, MISO, SCK, SS)
Communication	Half-Duplex	Full-Duplex
Addressing	7-bit Software Address	Hardware Slave Select (SS)
Typical Speed	100 kHz to 400 kHz	1 MHz to 10+ MHz
Hardware Needs	Pull-up resistors required	Direct push-pull connection

Evaluating Trade-offs

Wiring and Scalability

I2C uses a shared bus. You can connect dozens of sensors to the same two pins (SDA and SCL) as long as each device has a unique address. This makes it ideal for projects with many low-speed peripherals.

SPI requires a dedicated Slave Select (SS) pin for every device. If you connect five SPI devices, you need five separate SS pins in addition to the three shared clock and data lines. This can quickly exhaust the available pins on smaller boards like the Arduino Nano.

Data Throughput and Reliability

SPI is significantly faster because it can send and receive data simultaneously (full-duplex). This is critical for streaming data or updating screens. However, SPI lacks a built-in acknowledgment system; the master sends data and assumes the slave received it.

I2C is slower (half-duplex) but includes an ACK/NACK (Acknowledge/Not-Acknowledge) bit for every byte. This provides a basic layer of verification that the peripheral is actually responding.

Physical Constraints

I2C is sensitive to bus capacitance. Because it relies on pull-up resistors to pull the line high, long wires (typically over 10-20cm) can distort the signal, leading to communication errors. SPI is generally more robust over slightly longer distances, though it is still intended for short-range PCB communication.

Implementation Example: I2C Sensor Setup

To implement I2C, use the Wire library. This example assumes an Arduino Uno (5V) and an I2C sensor compatible with 5V logic. Warning: If using a 3.3V sensor, you must use a bidirectional logic level shifter to avoid damaging the peripheral.

// Required Library
#include <Wire.h>

const int DEVICE_ADDR = 0x48; // Example I2C address for a sensor

void setup() {
  Wire.begin(); // Join I2C bus as Master
  Serial.begin(9600);
} 

void loop() {
  Wire.beginTransmission(DEVICE_ADDR);
  Wire.write(0x01); // Request register 0x01
  Wire.endTransmission();

  Wire.requestFrom(DEVICE_ADDR, 1); // Request 1 byte
  if (Wire.available()) {
    byte data = Wire.read();
    Serial.println(data);
  }
  delay(500);
}

Verification and Diagnostics

To verify the connection, run an "I2C Scanner" sketch. This iterates through all 127 possible addresses and reports which ones return an ACK. If the scanner finds no devices, check the following:

• Pull-up Resistors: Ensure 4.7kΩ or 10kΩ resistors are connected from SDA and SCL to VCC. Many breakout boards include these, but bare chips do not.
• Wiring: Verify SDA is connected to A4 and SCL to A5 (on Arduino Uno).
• Common Ground: Ensure the peripheral and the Arduino share a ground (GND) connection.

Rollback Procedure

If the I2C bus hangs (stops responding), it is often due to a slave device holding the SDA line low. To recover:

1. Disconnect power from the Arduino and peripherals.
2. Check for short circuits between SDA/SCL and GND.
3. Power cycle the system. If the hang persists, use a logic analyzer to identify which device is failing to release the bus.