Multiple I2C devices on same bus in Raspberry Pi - Deep Dive

Overview - Multiple I2C devices on same bus

What is it?

Multiple I2C devices on the same bus means connecting several sensors or modules to one pair of wires (SDA and SCL) that carry data and clock signals. Each device has a unique address so the main controller, like a Raspberry Pi, can talk to them one at a time. This setup saves wiring and pins while allowing many devices to share communication lines. It is common in electronics projects to read data from or control multiple components efficiently.

Why it matters

Without the ability to connect multiple devices on one I2C bus, each sensor or module would need its own separate wires and pins, making projects bulky and complicated. This would limit how many devices you can use and increase costs and wiring errors. Using one bus with multiple devices simplifies hardware, reduces clutter, and makes it easier to expand projects with more sensors or controls.

Where it fits

Before learning this, you should understand basic I2C communication and how a single device connects to the Raspberry Pi. After this, you can explore advanced topics like I2C multiplexers, bus speed tuning, and troubleshooting communication conflicts.

Mental Model

Core Idea

Multiple I2C devices share the same two wires but use unique addresses so the controller can select and talk to each device individually.

Think of it like...

Imagine a group of friends sharing one phone line. Each friend has a unique phone number (address), so when you call a number, only that friend answers while others stay quiet.

┌───────────────┐
│ Raspberry Pi  │
│  (Master)     │
└──────┬────────┘
       │ SDA, SCL (shared wires)
       │
┌──────┴───────┬───────┬───────┐
│ Device 1     │Device 2│Device 3│
│ Address 0x20 │0x30    │0x40    │
└──────────────┴────────┴────────┘

Build-Up - 7 Steps

1

Foundation

Basics of I2C Bus Wiring

Concept: Learn the physical wiring and signals of the I2C bus.

I2C uses two wires: SDA for data and SCL for clock. Both lines need pull-up resistors to keep the line high when no device is pulling it low. The Raspberry Pi acts as the master, controlling the clock and initiating communication. Devices connect to these two wires in parallel.

Result

You understand how to physically connect one device to the Raspberry Pi using SDA and SCL lines with pull-up resistors.

Knowing the wiring basics prevents hardware damage and ensures reliable communication from the start.

2

Foundation

Understanding I2C Device Addressing

Concept: Each I2C device has a unique address to identify it on the bus.

Every device on the I2C bus has a 7-bit or 10-bit address. The master sends this address before data to select which device to talk to. Devices ignore messages not matching their address. You can find device addresses using tools like 'i2cdetect' on Raspberry Pi.

Result

You can identify and communicate with a single device by its address on the bus.

Addressing is the key to managing multiple devices on the same wires without confusion.

3

Intermediate

Connecting Multiple Devices on One Bus

Concept: Multiple devices share SDA and SCL lines but must have unique addresses.

You connect several devices in parallel to the same SDA and SCL wires. Each device must have a different address; otherwise, communication conflicts occur. Some devices allow changing their address by hardware pins. Use 'i2cdetect' to confirm all devices appear with unique addresses.

Result

Multiple devices respond correctly on the same bus without interfering with each other.

Sharing wires saves pins and wiring but requires careful address management to avoid conflicts.

4

Intermediate

Handling Address Conflicts and Limitations

🤔Before reading on: do you think two devices with the same address can work on the same I2C bus? Commit to your answer.

Concept: Devices with the same address cause conflicts; solutions include changing addresses or using multiplexers.

If two devices share the same address, the master cannot distinguish them, causing data errors. Some devices let you change their address via pins or software. If not, you can use an I2C multiplexer chip that switches between devices on separate channels, allowing identical addresses on different channels.

Result

You know how to resolve address conflicts and expand device count beyond address limits.

Understanding address conflicts helps avoid frustrating bugs and enables scaling complex projects.

5

Advanced

Software Communication with Multiple Devices

🤔Before reading on: do you think you need to change the bus or wires to talk to different devices? Commit to your answer.

Concept: The software selects devices by sending their address; no hardware change is needed to switch devices.

In code, you open the I2C bus once and specify the device address when reading or writing. The bus stays the same; the address tells the device to respond. For example, using Python's smbus2 library, you set the device address before each operation. This lets you communicate with many devices seamlessly.

Result

You can write code that talks to multiple devices on the same bus by changing addresses in commands.

Knowing that device selection is done by address in software simplifies multi-device programming.

6

Advanced

Electrical Limits and Bus Speed Considerations

Concept: More devices and longer wires affect signal quality and speed on the I2C bus.

Each device adds capacitance to the bus, which can slow signals and cause errors. Longer wires increase this effect. To maintain reliability, you may need to lower the bus speed (e.g., from 400kHz to 100kHz) or add stronger pull-up resistors. Sometimes, using bus buffers or repeaters helps for many devices or long distances.

Result

You understand how to keep communication stable when many devices share the bus.

Recognizing electrical limits prevents mysterious communication failures in complex setups.

7

Expert

Using I2C Multiplexers for Address Overlaps

🤔Before reading on: do you think hardware can help when devices share the same address? Commit to your answer.

Concept: I2C multiplexers let you switch between groups of devices with overlapping addresses by selecting different channels.

An I2C multiplexer is a chip that connects one master bus to multiple downstream buses. You select which downstream bus is active by writing to the multiplexer’s address. This allows devices with the same address to exist on different channels without conflict. The Raspberry Pi talks to the multiplexer first, then to the device on the chosen channel.

Result

You can use identical-address devices in one project by switching channels via software.

Knowing about multiplexers unlocks advanced project designs with many sensors and modules.

Under the Hood

The I2C bus uses open-drain/open-collector lines with pull-up resistors, allowing multiple devices to pull the line low without damage. Each device listens to the clock and data lines and responds only when its unique address is called by the master. The master controls timing and initiates communication sequences. When multiple devices share the bus, the electrical signals combine safely because devices only pull lines low, never drive them high.

Why designed this way?

I2C was designed to minimize wiring and pins by sharing two lines among many devices. Open-drain lines prevent electrical conflicts when multiple devices try to communicate. The addressing scheme allows flexible device selection without extra wires. Alternatives like SPI use more wires but can be faster; I2C trades speed for simplicity and scalability.

┌───────────────┐
│   Master      │
│ (Raspberry Pi)│
└──────┬────────┘
       │
       │ SDA, SCL (open-drain lines with pull-ups)
       │
┌──────┴─────────────┐
│ Multiple Devices    │
│ (each with address) │
│  ┌─────┐ ┌─────┐    │
│  │Dev1 │ │Dev2 │ ...│
│  └─────┘ └─────┘    │
└────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can two I2C devices with the same address work on the same bus simultaneously? Commit to yes or no.

Common Belief: Two devices with the same address can share the bus without problems.

Reality: Devices with identical addresses cause communication conflicts and data corruption because the master cannot distinguish them.

Why it matters: Ignoring this leads to unpredictable sensor readings and system failures, wasting debugging time.

Quick: Does adding more devices always slow down the I2C bus speed automatically? Commit to yes or no.

Common Belief: The bus speed automatically adjusts when more devices are added.

Reality: The bus speed stays the same unless manually changed; adding devices increases electrical load, which can cause errors if speed is not reduced.

Why it matters: Assuming automatic speed adjustment causes communication errors and device malfunctions.

Quick: Is it necessary to use separate SDA and SCL wires for each I2C device? Commit to yes or no.

Common Belief: Each I2C device needs its own SDA and SCL wires.

Reality: All devices share the same SDA and SCL lines; separate wires are not needed and would defeat the purpose of I2C.

Why it matters: Misunderstanding this leads to complicated and unnecessary wiring, increasing project complexity.

Quick: Can software alone fix hardware address conflicts on the I2C bus? Commit to yes or no.

Common Belief: You can solve address conflicts just by changing software code.

Reality: Hardware address conflicts require physical changes like setting address pins or using multiplexers; software cannot fix identical addresses on the same bus.

Why it matters: Relying on software fixes wastes time and causes persistent communication failures.

Expert Zone

1

Some devices support 10-bit addressing, but most use 7-bit; mixing both requires careful handling in software.

2

Pull-up resistor values affect bus speed and signal integrity; choosing the right resistor depends on bus length and device count.

3

Repeated start conditions in I2C allow switching devices without releasing the bus, improving efficiency but requiring precise timing.

When NOT to use

Using multiple devices on one I2C bus is not ideal when devices require very high-speed communication or when bus length is very long. In such cases, SPI or UART protocols or using I2C bus extenders and buffers are better alternatives.

Production Patterns

In real-world projects, engineers use I2C multiplexers to handle many sensors with overlapping addresses, implement bus error detection and recovery in software, and carefully design PCB layouts with proper pull-ups and shielding to ensure reliable multi-device communication.

Connections

SPI Communication Protocol

Alternative communication method with separate lines per device

Understanding I2C multi-device sharing highlights why SPI uses more wires but can achieve higher speeds and simpler device selection.

Networking Addressing (IP Addresses)

Both use unique addresses to identify devices on a shared medium

Knowing how I2C addresses devices helps understand how IP addresses allow computers to communicate on shared networks.

Telephone Switchboards

Switchboards route calls to unique phone numbers on shared lines

Recognizing that I2C addressing is like routing calls clarifies how one bus can serve many devices without confusion.

Common Pitfalls

#1 Connecting two devices with the same I2C address on one bus without any hardware solution.

Wrong approach:

Connect Device A and Device B both set to address 0x40 on the same SDA and SCL lines and try to communicate.

Correct approach:

Change the address of one device using hardware pins or use an I2C multiplexer to separate devices with the same address.

Root cause:

Misunderstanding that each device must have a unique address or be isolated to avoid conflicts.

#2 Omitting pull-up resistors on the SDA and SCL lines when connecting multiple devices.

Wrong approach:

Wire SDA and SCL lines directly to devices without pull-up resistors.

Correct approach:

Add appropriate pull-up resistors (e.g., 4.7kΩ) on SDA and SCL lines to the 3.3V rail.

Root cause:

Not knowing that I2C lines require pull-ups to function correctly due to open-drain design.

#3 Using very long wires for I2C bus without adjusting speed or adding buffers.

Wrong approach:

Connect devices with several meters of wire at 400kHz bus speed without any signal conditioning.

Correct approach:

Reduce bus speed to 100kHz or add bus buffers/repeaters for long-distance communication.

Root cause:

Ignoring electrical limitations and signal integrity issues on the I2C bus.

Key Takeaways

Multiple I2C devices share two wires but must have unique addresses to communicate without conflict.

Address conflicts cause communication errors and must be resolved by changing addresses or using multiplexers.

Pull-up resistors are essential for proper I2C bus operation and signal integrity.

Software selects devices by address; the physical bus wiring remains shared and constant.

Electrical limits like bus length and device count affect speed and reliability, requiring adjustments.

Practice

1.

What is the main requirement to connect multiple I2C devices on the same bus?

Choose the best answer.

easy

A. Each device must have a unique I2C address.

B. Each device must use a different bus.

C. Devices must be connected with separate wires.

D. Devices must have the same address to communicate.

Solution

1. Step 1: Understand I2C bus addressing

   I2C devices share the same two wires but must have unique addresses to avoid conflicts.

2. Step 2: Identify the correct requirement

   Since devices share the bus, unique addresses allow the master to select each device individually.

3. Final Answer:

   Each device must have a unique I2C address. -> Option A

4. Quick Check:

   Unique addresses = multiple devices on one bus [OK]

Hint: Remember: unique addresses prevent device conflicts on I2C [OK]

Common Mistakes:

• Thinking devices need separate wires
• Assuming devices can share the same address
• Believing each device needs its own bus

2.

Which Python code snippet correctly initializes communication with two I2C devices at addresses 0x20 and 0x21 on the same bus?

import smbus2
bus = smbus2.SMBus(1)

# What comes next?

easy

A. device1 = smbus2.SMBus(0x20)
device2 = smbus2.SMBus(0x21)

B. device1 = bus.read_byte(0x20)
device2 = bus.read_byte(0x21)

C. device1 = 0x20
device2 = 0x21

D. device1 = bus
device2 = bus

Solution

1. Step 1: Understand bus and device addressing

   The bus object is created once; devices are identified by their addresses.

2. Step 2: Assign device addresses as variables

   Assigning device addresses to variables allows easy communication calls later.

3. Final Answer:

   device1 = 0x20\ndevice2 = 0x21 -> Option C

4. Quick Check:

   Bus once, devices by address [OK]

Hint: Create one bus object; use addresses to identify devices [OK]

Common Mistakes:

• Trying to create multiple bus objects for each device
• Calling read_byte immediately without setup
• Assigning bus object directly to devices

3.

Given this Python code snippet on a Raspberry Pi with two I2C devices at addresses 0x20 and 0x21:

import smbus2
bus = smbus2.SMBus(1)

value1 = bus.read_byte(0x20)
value2 = bus.read_byte(0x21)
print(value1, value2)

What will be the output if device 0x20 returns 10 and device 0x21 returns 20?

medium

A. 10 20

B. 20 10

C. 0 0

D. Error: Address not found

Solution

1. Step 1: Read bytes from each device address

   The code reads one byte from address 0x20 and one from 0x21.

2. Step 2: Print the values in order

   Since value1 reads from 0x20 (returns 10) and value2 from 0x21 (returns 20), print outputs "10 20".

3. Final Answer:

   10 20 -> Option A

4. Quick Check:

   Read from 0x20 then 0x21 = 10 20 [OK]

Hint: Read bytes by address order matches output order [OK]

Common Mistakes:

• Mixing up device addresses and values
• Assuming output is reversed
• Expecting error without checking device presence

4.

Consider this Python code snippet intended to read from two I2C devices on the same bus:

import smbus2
bus = smbus2.SMBus(1)

value1 = bus.read_byte(0x20)
value2 = bus.read_byte(0x20)
print(value1, value2)

Why might this code cause a problem when trying to read two different devices?

medium

A. The code is missing pull-up resistors on the bus.

B. Both reads use the same address, so the second device is never accessed.

C. The addresses 0x20 and 0x20 are invalid on the bus.

D. The bus object is created twice, causing conflict.

Solution

1. Step 1: Check device addresses used in reads

   Both read_byte calls use address 0x20, so only one device is accessed twice.

2. Step 2: Understand impact on multiple devices

   To read two different devices, their unique addresses must be used; otherwise, the second device is ignored.

3. Final Answer:

   Both reads use the same address, so the second device is never accessed. -> Option B

4. Quick Check:

   Same address twice = one device only [OK]

Hint: Use different addresses to access multiple devices [OK]

Common Mistakes:

• Assuming bus object creation causes error
• Thinking addresses 0x20 are invalid
• Confusing hardware wiring issues with code errors

5.

You have three I2C sensors connected to the same Raspberry Pi bus with addresses 0x20, 0x21, and 0x20. You want to read data from all three devices. What is the best way to fix this setup?

hard

A. Use separate I2C buses for devices with the same address.

B. Use software to ignore address conflicts and read anyway.

C. Connect devices with the same address to different GPIO pins.

D. Change the address of one device so all three have unique addresses.

Solution

1. Step 1: Identify address conflict

   Two devices share address 0x20, causing bus conflicts and communication errors.

2. Step 2: Resolve conflict by changing address

   Most I2C devices allow changing their address via hardware pins or software configuration to ensure uniqueness.

3. Step 3: Alternative solutions

   Using separate buses or GPIO pins is complex; ignoring conflicts causes errors.

4. Final Answer:

   Change the address of one device so all three have unique addresses. -> Option D

5. Quick Check:

   Unique addresses fix conflicts [OK]

Hint: Ensure all devices have unique addresses to avoid conflicts [OK]

Common Mistakes:

• Trying to read devices with duplicate addresses
• Assuming software can fix hardware address conflicts
• Using separate GPIO pins without separate buses