Writing data to I2C device in Embedded C - Deep Dive

Overview - Writing data to I2C device

What is it?

Writing data to an I2C device means sending information from a microcontroller to a small chip or sensor using the I2C communication protocol. I2C uses two wires to connect devices: one for clock signals and one for data. This method allows multiple devices to share the same wires but still communicate separately. Writing data involves telling the device what to do or sending values it needs to work.

Why it matters

Without the ability to write data to I2C devices, microcontrollers could only read information but not control sensors, displays, or other components. This would limit the functionality of many gadgets like temperature sensors, digital clocks, or motor controllers. Writing data lets devices work together smoothly, making smart devices possible. Without it, many modern electronics would be less flexible and less powerful.

Where it fits

Before learning to write data to I2C devices, you should understand basic digital electronics and how microcontrollers communicate using protocols like I2C. After mastering writing data, you can learn about reading data from I2C devices, handling errors, and using more complex I2C features like multi-master setups or clock stretching.

Mental Model

Core Idea

Writing data to an I2C device is like sending a letter through a shared mailbox system where each device has its own address, and you use two wires to coordinate sending the message bit by bit.

Think of it like...

Imagine a group of friends sharing a single mailbox with two slots: one slot signals when to check the mailbox (clock), and the other slot is where letters (data) are passed. Each friend has a unique mailbox number (address), so when you send a letter, only the friend with that number reads it.

┌─────────────┐
│ Microcontroller │
└──────┬──────┘
       │ SDA (Data line)
       │
       │
       │ SCL (Clock line)
       │
┌──────┴──────┐
│ I2C Bus     │
└──────┬──────┘
       │
┌──────┴──────┐   ┌─────────────┐
│ Device 1    │   │ Device 2    │
│ Address 0x10│   │ Address 0x20│
└─────────────┘   └─────────────┘

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 lines: SDA for data and SCL for clock. Devices on the bus have unique addresses. The master device controls the clock and starts communication by sending the address of the device it wants to talk to.

Result

You know how devices share two wires and how the master starts talking to a specific device.

Understanding the two-wire system and addressing is key to grasping how data is sent and received on the I2C bus.

2

Foundation

I2C Write Operation Steps

Concept: Learn the sequence of signals needed to write data to an I2C device.

Writing data involves these steps: 1) Master sends a START signal to begin communication. 2) Master sends the 7-bit device address plus a write bit. 3) The device acknowledges (ACK) if it hears its address. 4) Master sends data bytes one by one. 5) Device acknowledges each byte. 6) Master sends a STOP signal to end communication.

Result

You can list the exact steps to send data to an I2C device.

Knowing the exact order of signals helps prevent communication errors and ensures the device understands the data sent.

3

Intermediate

Writing Data Using Embedded C Code

🤔Before reading on: do you think writing data requires sending the device address every time or just the data bytes? Commit to your answer.

Concept: Learn how to write data to an I2C device using embedded C functions that handle the protocol steps.

In embedded C, you usually use functions to send START, write the device address with the write bit, send data bytes, and then send STOP. For example: // Pseudocode I2C_Start(); I2C_Write(device_address << 1 | 0); // write bit = 0 I2C_Write(data_byte1); I2C_Write(data_byte2); I2C_Stop(); Each function handles the low-level signals on the SDA and SCL lines.

Result

You can write a simple program that sends data to an I2C device.

Understanding that the device address must be sent first with the write bit clarifies how the device knows the data is for it.

4

Intermediate

Handling Acknowledgments (ACK/NACK)

🤔Before reading on: do you think ignoring ACK signals can cause problems? Commit to your answer.

Concept: Learn why checking for device acknowledgments after sending address and data is important.

After sending the device address or each data byte, the master expects an ACK bit from the device. If the device sends NACK (no acknowledgment), it means it did not receive or cannot process the data. Proper code checks for ACK and can retry or stop communication if NACK is received.

Result

You know how to detect if the device is ready and responding during data writing.

Checking ACK signals prevents silent failures and helps your program handle communication errors gracefully.

5

Intermediate

Writing Multiple Bytes and Registers

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

Concept: Learn how to write several bytes in one communication session, often to specific registers inside the device.

Many I2C devices have registers to hold data. To write multiple bytes, you send the device address with write bit, then the register address, then the data bytes sequentially, all before sending the STOP signal. This keeps the communication efficient and atomic. Example: I2C_Start(); I2C_Write(device_address << 1 | 0); I2C_Write(register_address); I2C_Write(data_byte1); I2C_Write(data_byte2); I2C_Stop();

Result

You can write multiple bytes to specific places inside the device in one go.

Knowing how to write multiple bytes in one session reduces bus traffic and speeds up communication.

6

Advanced

Dealing with Bus Errors and Timeouts

🤔Before reading on: do you think the I2C bus can get stuck forever if a device misbehaves? Commit to your answer.

Concept: Learn how to detect and recover from common I2C bus errors like stuck lines or missing acknowledgments.

Sometimes devices hold the clock line low or fail to respond, causing the bus to hang. Good embedded code implements timeouts and error checks. If a timeout occurs, the code can reset the bus by sending extra clock pulses or a STOP condition to free the lines before retrying communication.

Result

Your program can recover from bus errors and continue working without freezing.

Handling bus errors is crucial for reliable real-world applications where devices may misbehave or disconnect.

7

Expert

Optimizing I2C Writes with DMA and Interrupts

🤔Before reading on: do you think writing data byte-by-byte in a loop is the fastest way? Commit to your answer.

Concept: Learn advanced techniques to speed up I2C data writing using hardware features like DMA and interrupts.

Instead of waiting for each byte to send, microcontrollers can use Direct Memory Access (DMA) to transfer data to the I2C hardware automatically. Interrupts notify the CPU when transfers complete. This frees the CPU to do other tasks and improves performance in complex systems. Example: Configure DMA to send a buffer of data to the I2C peripheral, then start the transfer and wait for an interrupt signaling completion.

Result

Your system writes data faster and uses CPU time more efficiently.

Leveraging hardware features like DMA and interrupts is key for high-performance embedded systems communicating over I2C.

Under the Hood

At the hardware level, the I2C controller in the microcontroller controls the SDA and SCL lines by setting them high or low according to the protocol timing. Writing data involves shifting out bits on SDA synchronized with clock pulses on SCL. The device address and data bytes are sent bit by bit, and the receiving device pulls SDA low during the ACK bit to signal it received the byte. The microcontroller's I2C peripheral or software bit-banging manages these signals precisely.

Why designed this way?

I2C was designed to use only two wires to reduce complexity and cost while allowing multiple devices on the same bus. The clock line ensures all devices stay synchronized, and the acknowledgment mechanism confirms data integrity. Alternatives like SPI use more wires but can be faster. I2C balances simplicity, flexibility, and moderate speed, making it ideal for many embedded applications.

┌───────────────┐
│ Microcontroller│
│ I2C Peripheral│
└──────┬────────┘
       │ Controls SDA and SCL lines
       │
┌──────┴───────┐
│ SDA (Data)   │<───── Bit by bit data transfer
│ SCL (Clock)  │<───── Clock pulses synchronize bits
└──────────────┘
       │
┌──────┴────────┐
│ I2C Device    │
│ Receives bits │
│ Sends ACK bit │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think the write bit in the address byte is always zero? Commit yes or no.

Common Belief: The device address byte is fixed and does not include a read or write bit.

Reality: The last bit of the address byte is the read/write bit: 0 for write, 1 for read. This bit tells the device if the master wants to send or receive data.

Why it matters: Ignoring the read/write bit causes devices to misinterpret commands, leading to failed communication or data corruption.

Quick: Do you think you can write data without sending a START condition first? Commit yes or no.

Common Belief: You can send data bytes directly without signaling the start of communication.

Reality: The START condition signals the beginning of communication and alerts devices to listen. Without it, devices ignore data on the bus.

Why it matters: Skipping the START condition means the device never knows data is coming, so your write commands fail silently.

Quick: Do you think the I2C bus can handle unlimited devices without issues? Commit yes or no.

Common Belief: You can connect as many devices as you want on the I2C bus without problems.

Reality: The bus capacitance and address space limit the number of devices. Too many devices slow the bus and can cause signal integrity problems.

Why it matters: Overloading the bus leads to communication errors and unreliable device behavior.

Quick: Do you think ignoring ACK signals is safe during data writing? Commit yes or no.

Common Belief: You don't need to check if the device acknowledges each byte; just send data continuously.

Reality: ACK signals confirm the device received data. Ignoring them can hide communication failures.

Why it matters: Not checking ACKs can cause your program to think data was written when it wasn't, leading to bugs that are hard to trace.

Expert Zone

1

Some devices require repeated START conditions to switch from writing to reading without releasing the bus, a subtlety often missed.

2

Clock stretching allows slower devices to hold the clock line low to delay the master, which must be handled properly to avoid bus hangs.

3

The electrical characteristics of the bus, like pull-up resistor values, affect signal timing and reliability, requiring careful hardware design.

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 due to higher speeds and simpler wiring.

Production Patterns

In production, I2C writes are often wrapped in driver libraries that handle retries, error checking, and device-specific quirks. DMA and interrupt-driven transfers are used in complex systems to optimize performance and reduce CPU load.

Connections

Serial Peripheral Interface (SPI)

Alternative communication protocol with different wiring and speed tradeoffs.

Understanding I2C helps appreciate SPI's simpler but more wire-intensive design, highlighting tradeoffs in embedded communication.

Computer Networking Protocols

Both use addressing and acknowledgments to manage communication between multiple devices.

Knowing how I2C uses addresses and ACK bits parallels how network protocols ensure data reaches the correct computer and confirm receipt.

Human Conversation Turn-Taking

I2C's clock and data lines coordinate when devices speak and listen, similar to how people take turns talking.

Recognizing this coordination helps understand why timing and signaling are critical in digital communication.

Common Pitfalls

#1 Not sending the START condition before writing data.

Wrong approach:

I2C_Write(device_address << 1 | 0);
I2C_Write(data_byte);
I2C_Stop();

Correct approach:

I2C_Start();
I2C_Write(device_address << 1 | 0);
I2C_Write(data_byte);
I2C_Stop();

Root cause:

Misunderstanding that the START condition signals the beginning of communication and is required for devices to listen.

#2 Ignoring the acknowledgment bit after sending the device address.

Wrong approach:

I2C_Start();
I2C_Write(device_address << 1 | 0); // no check for ACK
I2C_Write(data_byte);
I2C_Stop();

Correct approach:

I2C_Start();
if (!I2C_Write(device_address << 1 | 0)) {
// handle NACK error
}
I2C_Write(data_byte);
I2C_Stop();

Root cause:

Assuming the device always responds and not verifying communication success.

#3 Sending multiple data bytes with separate START and STOP signals each time.

Wrong approach:

for (int i = 0; i < len; i++) {
I2C_Start();
I2C_Write(device_address << 1 | 0);
I2C_Write(data[i]);
I2C_Stop();
}

Correct approach:

I2C_Start();
I2C_Write(device_address << 1 | 0);
for (int i = 0; i < len; i++) {
I2C_Write(data[i]);
}
I2C_Stop();

Root cause:

Not understanding that multiple bytes can be sent in one continuous communication session.

Key Takeaways

Writing data to an I2C device requires sending a START signal, the device address with a write bit, the data bytes, and a STOP signal in that order.

Checking acknowledgment bits after sending the address and each data byte ensures the device received the information correctly.

Multiple bytes can be written in one session by sending the register address followed by data bytes before stopping communication.

Handling bus errors and timeouts is essential for reliable communication in real-world embedded systems.

Advanced techniques like DMA and interrupts can optimize I2C data writing for better performance and CPU efficiency.