The Inter-Integrated Circuit (I2C) protocol is a widely used communication standard that enables low-speed, short-distance communication between microcontrollers, sensors, and peripheral devices in embedded systems. Developed by Philips Semiconductors (now NXP) in the 1980s, I2C has become a go-to protocol for connecting various components on a circuit board due to its simplicity, efficiency, and flexibility.
In this article, we’ll explore the basics of the I2C protocol, its structure, features, advantages, and common applications.
What is I2C?
I2C is a synchronous serial communication protocol, meaning data is transferred with a clock signal, ensuring that both the sender and receiver are synchronized. It uses just two wires for communication:
- SCL (Serial Clock Line): This line carries the clock signal, which determines the timing of data transmission.
- SDA (Serial Data Line): This line is used to carry the actual data being transferred.
I2C operates in a master-slave configuration. The master device (usually a microcontroller) controls the communication by generating the clock signal (SCL) and sending/receiving data. The slave devices respond to commands from the master and can also send data when requested.
Key Features of I2C:
- Two-wire Communication: I2C simplifies the connection between devices by using just two signal lines, making it an efficient protocol for systems with multiple devices.
- Addressing: Every device on the I2C bus must have a unique address. I2C typically supports 7-bit or 10-bit addressing:
- 7-bit addressing allows for up to 128 unique addresses (from 0x00 to 0x7F).
- 10-bit addressing expands the address range, supporting up to 1024 unique devices.
- Multi-Master Capability: Although I2C is most commonly used in a master-slave configuration, it allows multiple master devices to control the bus. This feature is beneficial in systems where more than one device needs to initiate communication.
- Speed: The I2C protocol supports different communication speeds (data rates), which are as follows:
- Standard Mode: 100 kbit/s
- Fast Mode: 400 kbit/s
- High-Speed Mode: 3.4 Mbit/s
- Data Transfer: Data is transferred in bytes (8 bits) and is clocked in synchrony with the SCL line. Each byte of data is followed by an acknowledgment bit to ensure successful transmission.
How I2C Works
The I2C communication consists of a series of data frames that facilitate the transfer of information between the master and slave devices. A typical data frame includes the following components:
- Start Condition: A start condition is initiated by the master to signal the beginning of a communication sequence. To generate START condition the SDA is changed from high to low while keeping the SCL high
- Addressing: The master sends the address of the slave device it wants to communicate with. The address is sent on the SDA line, and the slave with the matching address will acknowledge by pulling the SDA line low.
- Data Transfer: After the slave acknowledges the address, the master can either send or receive data. Data is transferred in 8-bit bytes, with each byte followed by an acknowledgment bit.
- Stop Condition: After the data transfer is complete, the master sends a stop condition. To generate STOP condition SDA goes from low to high while keeping the SCL high.
- Repeated Start Condition: Typically, an I2C communication begins with a Start Condition (S), followed by the transfer of data, and ends with a Stop Condition (P). However, if the master needs to send additional data to a slave or request further information from the same or another slave, it can issue a Repeated Start rather than a Stop condition. This ensures the bus remains in use and the master retains control without allowing other devices to take over
In summary, the data transfer between devices on the I2C bus consists of the following sequence:
- Start condition → Address + Read/Write bit → Data bytes → Acknowledgment → Stop condition.
I2C Communication Example
Let’s consider an example of a microcontroller (master) communicating with a temperature sensor (slave) over the I2C bus. The master first sends the address of the sensor and then requests the temperature data. The sensor responds by sending the temperature data back to the master.
Here’s how the communication might unfold:
- Master sends a start condition.
- Master sends the address of the temperature sensor (e.g., 0x48).
- Sensor acknowledges the address.
- Master sends a read command to request data.
- Sensor sends the temperature data byte by byte.
- Master acknowledges each byte.
- Once all data is transferred, the master sends a stop condition.
Implementing 12c Protocol using Bit-Banging on Arduino
While hardware I2C is much more efficient and widely used, implementing I2C via bit-banging is a great way to understand how the protocol works at a low level. It also gives you flexibility if you have limited hardware I2C interfaces on your microcontroller or need to control the I2C communication manually. However, keep in mind that bit-banging is slower and more resource-intensive, making it less suitable for high-speed or time-sensitive applications.We’ll create an implementation of the I2c protocol using bit-banging on an Arduino.
// Define the I2C pins
#define SDA_PIN 4 // Define SDA (data) pin
#define SCL_PIN 5 // Define SCL (clock) pin
// Function to set SDA and SCL pins as outputs
void setupPins() {
pinMode(SDA_PIN, OUTPUT);
pinMode(SCL_PIN, OUTPUT);
digitalWrite(SDA_PIN, HIGH); // Initialize SDA to high (idle state)
digitalWrite(SCL_PIN, HIGH); // Initialize SCL to high (idle state)
}
// Function to send a start condition
void startCondition() {
digitalWrite(SDA_PIN, HIGH); // Make sure SDA is high
digitalWrite(SCL_PIN, HIGH); // Make sure SCL is high
delayMicroseconds(5);
digitalWrite(SDA_PIN, LOW); // Pull SDA low to indicate the start condition
delayMicroseconds(5);
digitalWrite(SCL_PIN, LOW); // Pull SCL low
}
// Function to send a stop condition
void stopCondition() {
digitalWrite(SDA_PIN, LOW); // Make sure SDA is low
digitalWrite(SCL_PIN, HIGH); // Pull SCL high
delayMicroseconds(5);
digitalWrite(SDA_PIN, HIGH); // Pull SDA high to indicate stop condition
delayMicroseconds(5);
}
// Function to send a byte of data
void sendByte(uint8_t data) {
for (int i = 7; i >= 0; i--) {
// Set SDA line to the current bit of data
if (bitRead(data, i)) {
digitalWrite(SDA_PIN, HIGH);
} else {
digitalWrite(SDA_PIN, LOW);
}
// Generate the clock pulse (SCL)
digitalWrite(SCL_PIN, HIGH);
delayMicroseconds(5);
digitalWrite(SCL_PIN, LOW);
delayMicroseconds(5);
}
}
// Function to receive a byte of data
uint8_t receiveByte() {
uint8_t receivedData = 0;
// Set SDA pin as input to read data
pinMode(SDA_PIN, INPUT);
for (int i = 7; i >= 0; i--) {
// Generate the clock pulse (SCL)
digitalWrite(SCL_PIN, HIGH);
delayMicroseconds(5);
// Read the SDA line and set the received bit
if (digitalRead(SDA_PIN)) {
receivedData |= (1 << i); // Set the bit if SDA is high
}
digitalWrite(SCL_PIN, LOW);
delayMicroseconds(5);
}
// Set SDA pin back to output
pinMode(SDA_PIN, OUTPUT);
return receivedData;
}
// Function to send an ACK (Acknowledge) signal
void sendAck() {
digitalWrite(SDA_PIN, LOW); // Acknowledge by pulling SDA low
digitalWrite(SCL_PIN, HIGH); // Pulse the clock
delayMicroseconds(5);
digitalWrite(SCL_PIN, LOW);
delayMicroseconds(5);
}
// Function to send a NACK (Not Acknowledge) signal
void sendNack() {
digitalWrite(SDA_PIN, HIGH); // NACK by pulling SDA high
digitalWrite(SCL_PIN, HIGH); // Pulse the clock
delayMicroseconds(5);
digitalWrite(SCL_PIN, LOW);
delayMicroseconds(5);
}
void setup() {
// Initialize serial communication for debugging
Serial.begin(9600);
// Setup the SDA and SCL pins
setupPins();
// Send a start condition
startCondition();
// Send a 7-bit address with write operation (e.g., address 0x50)
sendByte(0xA0); // 0xA0 is the 7-bit address for write (address 0x50 shifted left by 1)
// Send a byte of data (e.g., 0x55)
sendByte(0x55);
// Send an ACK after the byte
sendAck();
// Send a stop condition
stopCondition();
}
void loop() {
// The loop is empty because we are just testing the I2C functions in setup
}
Clock Stretching
Clock Stretching is a feature in I2C where a slave device holds the clock line (SCL) low, effectively pausing the communication, to signal that it is not ready to proceed with the current operation. This is especially useful when the slave needs more time to process data or perform some other action before it can continue with the transaction.
In I2C, the master generates the clock signal, but the slaves can influence it by stretching the clock when necessary. While the master is supposed to control the timing, clock stretching allows a slave to slow down communication as needed.
Multi-Master Operation in I2C
In the I2C (Inter-Integrated Circuit) protocol, the standard setup involves a single master that controls the communication, while multiple slaves are addressed by the master. However, the I2C protocol also supports multi-master configurations, where multiple masters can share control of the bus. This feature enables two or more master devices to communicate with one or more slave devices on the same I2C bus.
In a multi-master setup, any master device can take control of the bus, initiate communication with slaves, and issue commands. The system must ensure that multiple masters can share the bus without conflict, which requires a set of protocols to avoid data collisions and bus contention.
Let’s break down how multi-master operation works in I2C, along with its challenges and solutions.
How Multi-Master I2C Works
In a multi-master I2C configuration, the key principle is that more than one master device can initiate communication on the bus. However, only one master can be in control at any given time. The I2C bus itself is a shared resource, and the protocol defines mechanisms for managing multiple masters to prevent collisions or data corruption.
Key Characteristics of Multi-Master I2C
Arbitration:
The arbitration mechanism in I2C ensures that only one master can control the bus at a time when multiple masters attempt to send data simultaneously. The process relies on the fact that I2C uses an open-drain configuration for the data line (SDA), meaning that any device on the bus can pull the line low, but no device can drive it high. The line is pulled high by a pull-up resistor when no device is driving it low.
Here’s how the AND operation works in I2C arbitration:
Transmission and Monitoring:
- When two or more masters begin transmitting data simultaneously, each master is driving the SDA line to send data bits.
- Each master monitors the state of the SDA line while it is sending its data.
The AND Logic:
- If a master wants to send a ‘1’ (high) on the SDA line, it does not actively pull the line low. Instead, it lets the pull-up resistor keep the line high.
- If a master wants to send a ‘0’ (low), it actively pulls the SDA line low.
Conflict Detection (AND Operation):
- When both masters transmit at the same time, each master is monitoring the SDA line.
- If one master tries to send a ‘1’ (high) and another master tries to send a ‘0’ (low), the SDA line will be pulled low because of the master trying to send a ‘0’.
- The master that tries to send a ‘1’ will detect that the SDA line is actually low instead of high (because the other master pulled it low), meaning it has lost arbitration.
- This is the key point: the master that is transmitting a ‘1’ but detects a ‘0’ on the bus will back off, since it realizes it has lost the arbitration.
Winner of Arbitration:
- The master that successfully transmits its bits without conflict (i.e., the one that doesn’t detect a bus conflict) wins the arbitration.
- The losing master will stop transmitting and wait for the bus to become idle before trying again.
Conclusion
The I2C protocol is a powerful and versatile tool for communication between microcontrollers and peripheral devices in embedded systems. Its simplicity, flexibility, and low-cost wiring make it a go-to option for applications with multiple devices. Despite its limitations in speed and distance, I2C remains one of the most widely adopted serial communication protocols in modern electronic design.
