Reading data from I2C device in Embedded C - Deep Dive

Overview - Reading data from I2C device

What is it?

Reading data from an I2C device means getting information from a small chip or sensor connected to a microcontroller using the I2C communication protocol. I2C uses two wires to send and receive data between devices. This process involves sending a request to the device and then reading the response it sends back.

Why it matters

Without reading data from I2C devices, microcontrollers could not get information from sensors like temperature, light, or motion detectors. This would limit the ability to build smart gadgets or control systems that react to the environment. I2C makes it easy to connect many devices with just two wires, saving space and complexity.

Where it fits

Before learning this, you should understand basic microcontroller programming and digital communication concepts. After mastering reading data from I2C devices, you can learn how to write data to I2C devices, handle multiple devices on the bus, and use other communication protocols like SPI or UART.

Mental Model

Core Idea

Reading data from an I2C device is like sending a letter asking for information and then receiving a reply through a shared mailbox using a simple two-wire system.

Think of it like...

Imagine you and your friend share a mailbox with two slots: one for sending letters and one for receiving replies. You write a question on a letter and drop it in the sending slot. Your friend reads it, writes an answer, and puts it in the receiving slot. You then pick up the answer. This back-and-forth is like how I2C devices communicate.

┌───────────────┐       ┌───────────────┐
│ Microcontroller│──────▶│ I2C Device    │
│ (Master)      │       │ (Slave)       │
└───────┬───────┘       └───────┬───────┘
        │ SDA (Data)─────────────▶│
        │ SCL (Clock)────────────▶│
        │◀────────SDA (Data)     │
        │◀────────SCL (Clock)    │

Process:
1. Master sends start signal.
2. Master sends device address + read command.
3. Slave sends data bytes.
4. Master sends stop signal.

Build-Up - 7 Steps

1

Foundation

Understanding I2C Basics

Concept: Learn what I2C is and how it uses two wires to communicate between devices.

I2C stands for Inter-Integrated Circuit. It uses two wires: SDA for data and SCL for clock. One device controls the clock (master), and others respond (slaves). Each device has a unique address. Communication starts with the master sending a start signal, followed by the address, then data is sent or received.

Result

You know the roles of SDA and SCL lines and the basic flow of I2C communication.

Understanding the physical and logical setup of I2C is essential before trying to read data from devices.

2

Foundation

Setting Up I2C Hardware Connections

Concept: Learn how to physically connect an I2C device to a microcontroller.

Connect the SDA and SCL pins of the microcontroller to the corresponding pins on the I2C device. Both lines need pull-up resistors to the power supply to keep the lines high when idle. Also, connect the ground and power pins properly to ensure the device works.

Result

The microcontroller and I2C device are physically ready to communicate.

Proper wiring and pull-up resistors are critical; without them, communication will fail or be unreliable.

3

Intermediate

Writing Code to Initiate I2C Communication

Concept: Learn how to start communication with an I2C device in embedded C.

Use the microcontroller's I2C library or registers to send a start condition, followed by the device's 7-bit address with the read bit set. This tells the device you want to read data. Then wait for an acknowledgment from the device before proceeding.

Result

The microcontroller successfully requests data from the I2C device.

Knowing how to send start signals and addresses in code is the first step to reading data.

4

Intermediate

Reading Data Bytes from the I2C Device

🤔Before reading on: do you think the master or the slave controls when data is sent during reading? Commit to your answer.

Concept: Learn how the master reads data bytes sent by the slave device and how to acknowledge each byte.

After the device acknowledges the read request, the slave sends data bytes one by one. The master reads each byte and sends an acknowledgment (ACK) after each byte except the last one, where it sends a no-acknowledge (NACK) to signal the end of reading. Finally, the master sends a stop condition to end communication.

Result

Data bytes are successfully received from the I2C device.

Understanding the ACK/NACK mechanism prevents common bugs where data reading stops prematurely or continues too long.

5

Intermediate

Handling Multi-Byte Data Reads

🤔Before reading on: do you think reading multiple bytes requires separate start signals for each byte? Commit to your answer.

Concept: Learn how to read multiple bytes in one continuous I2C transaction.

To read multiple bytes, the master keeps the clock running and acknowledges each byte except the last. This continuous reading avoids sending multiple start signals, which can confuse the device. The stop signal is sent only after all bytes are read.

Result

Multiple bytes are read smoothly in one session.

Knowing how to read multiple bytes efficiently is key for sensors that send data in chunks.

6

Advanced

Using Embedded C I2C APIs for Reading

🤔Before reading on: do you think low-level register manipulation or high-level APIs are better for all projects? Commit to your answer.

Concept: Learn how to use embedded C libraries or APIs to simplify I2C reading.

Many microcontroller platforms provide I2C APIs that handle start, address, read, ACK/NACK, and stop signals internally. Using these APIs reduces code complexity and errors. For example, functions like HAL_I2C_Master_Receive() in STM32 HAL library read data with simple calls.

Result

You can read data from I2C devices with less code and fewer errors.

Using APIs improves productivity and code reliability but knowing the underlying process helps debug when things go wrong.

7

Expert

Debugging I2C Read Failures and Timing Issues

🤔Before reading on: do you think all I2C read errors are caused by wrong addresses? Commit to your answer.

Concept: Learn common causes of I2C read failures and how to diagnose timing or hardware issues.

I2C read failures can happen due to wrong device addresses, missing pull-up resistors, clock stretching by the slave, or bus noise. Using an oscilloscope or logic analyzer helps visualize signals. Adjusting clock speed or adding delays can fix timing problems. Also, checking acknowledgment bits reveals if the device responds.

Result

You can identify and fix common I2C read problems in real devices.

Knowing how to debug beyond code saves time and prevents frustration in embedded projects.

Under the Hood

I2C communication works by the master generating clock pulses on the SCL line and sending data bits on the SDA line synchronized to these pulses. Each byte sent is followed by an acknowledgment bit from the receiver. Reading data involves the master releasing the SDA line so the slave can drive it to send data bits. The master controls the clock and signals start and stop conditions to frame the communication.

Why designed this way?

I2C was designed to minimize wiring complexity by using only two lines for multiple devices, allowing easy expansion and simple hardware. The clock line controlled by the master ensures synchronized data transfer. Acknowledgments provide error checking. Alternatives like SPI use more wires but can be faster; I2C balances simplicity and flexibility.

┌───────────────┐
│   Master MCU  │
│  ┌─────────┐  │
│  │ Clock   │──┼─────▶ SCL (Clock line)
│  │ Control │  │
│  └─────────┘  │
│      │        │
│      │ SDA    │
│      ▼        │
│  ┌─────────┐  │
│  │ Data    │──┼─────▶ SDA (Data line)
│  │ Control │  │
│  └─────────┘  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│  I2C Device   │
│  (Slave)     │
└───────────────┘

Process:
Start → Address + R/W bit → ACK → Data bytes → ACK/NACK → Stop

Myth Busters - 4 Common Misconceptions

Quick: Do you think the master device sends data during a read operation? Commit to yes or no.

Common Belief: During a read operation, the master sends the data bytes to the slave.

Reality: During a read operation, the slave device sends data bytes to the master, while the master controls the clock and acknowledges each byte.

Why it matters: Confusing who sends data leads to incorrect code that never receives data, causing device communication failure.

Quick: Is it true that pull-up resistors on SDA and SCL lines are optional? Commit to yes or no.

Common Belief: Pull-up resistors on the I2C lines are optional and can be omitted if the microcontroller has internal pull-ups.

Reality: Pull-up resistors are essential on SDA and SCL lines to ensure the lines return to a high state when not driven low; internal pull-ups are usually too weak.

Why it matters: Without proper pull-ups, the bus lines may float, causing unreliable communication and data corruption.

Quick: Do you think each byte read requires a new start condition? Commit to yes or no.

Common Belief: Each byte read from an I2C device requires sending a new start condition.

Reality: Multiple bytes are read in one continuous transaction without repeated start conditions; only one start at the beginning and one stop at the end.

Why it matters: Sending multiple start conditions unnecessarily can confuse the device and cause communication errors.

Quick: Do you think the I2C clock speed can be set arbitrarily high without issues? Commit to yes or no.

Common Belief: You can set the I2C clock speed as high as you want to speed up communication.

Reality: I2C clock speed is limited by device specifications and bus capacitance; too high speed causes signal integrity problems and failed reads.

Why it matters: Ignoring speed limits leads to intermittent failures that are hard to diagnose.

Expert Zone

1

Some I2C devices use clock stretching where the slave holds the clock line low to delay the master; ignoring this can cause missed data.

2

Repeated start conditions allow the master to change direction (write to read) without releasing the bus, which is essential for some sensors.

3

The 7-bit addressing scheme can be extended to 10-bit addresses, but many libraries only support 7-bit, requiring special handling.

When NOT to use

I2C is not suitable for very high-speed communication or long-distance wiring; in such cases, SPI or UART protocols are better alternatives. Also, if bus complexity or noise is high, differential signaling protocols like CAN are preferred.

Production Patterns

In production, I2C reading is often wrapped in driver libraries that handle retries, error checking, and device-specific protocols. Multi-threaded systems use mutexes to avoid bus conflicts. Power management techniques disable I2C devices when not needed to save energy.

Connections

SPI Communication Protocol

Alternative communication protocol with different wiring and speed trade-offs.

Understanding I2C helps appreciate SPI's simpler but more wire-heavy design, showing how engineers balance complexity and performance.

Serial Communication (UART)

Another serial communication method but asynchronous and point-to-point.

Knowing I2C's synchronous clock line clarifies why UART can be simpler but less suited for multi-device buses.

Human Conversation Protocols

I2C communication mimics turn-taking and acknowledgments in conversations.

Recognizing communication patterns in human dialogue helps understand how devices coordinate sending and receiving data reliably.

Common Pitfalls

#1 Not using pull-up resistors on SDA and SCL lines.

Wrong approach:

Connecting SDA and SCL directly to microcontroller pins without pull-up resistors.

Correct approach:

Adding 4.7kΩ pull-up resistors from SDA and SCL lines to the positive voltage supply.

Root cause:

Misunderstanding that I2C lines are open-drain and require pull-ups to define the high state.

#2 Ignoring acknowledgment bits after sending address or data.

Wrong approach:

Sending address and data bytes without checking if the slave acknowledged.

Correct approach:

After sending each byte, checking the acknowledgment bit before proceeding.

Root cause:

Not realizing that missing ACK means the device did not respond, leading to communication errors.

#3 Sending stop condition too early during multi-byte reads.

Wrong approach:

Sending stop signal after each byte instead of after all bytes are read.

Correct approach:

Sending stop signal only after the last byte is read and NACK is sent.

Root cause:

Misunderstanding the continuous nature of multi-byte I2C transactions.

Key Takeaways

I2C uses two wires, SDA and SCL, to allow multiple devices to communicate with a master controller using unique addresses.

Reading data from an I2C device involves sending a start signal, the device address with a read bit, then receiving data bytes with acknowledgments.

Proper hardware setup with pull-up resistors and correct wiring is essential for reliable I2C communication.

Using embedded C APIs simplifies reading data but understanding the underlying protocol helps debug and optimize communication.

Common pitfalls include ignoring acknowledgments, missing pull-ups, and mishandling multi-byte reads, which can cause communication failures.