raspberry pi - Managing I2C address conflicts with multiple MCP23017 on the same bus

I'm using a Raspberry Pi with the I2C master and I successfully wired 8 different MCP23017 chips, each with their respective addresses by setting the last 3 bits of their 7 bit addresses. They are all working flawlessly.

My problem is that the basic addressing of the chips are permanently set to 0x20 to 0x27, which seems odd. After using i2cdetect I see so many other potential addresses.

My first question is: If the chips are locked on the 0x20s will there be any conflict IF any another I2C device uses the same device address?

Secondly: Is there a way to modify the basic addressing scheme (0x3*, 0x4*, 0x5*) to maximize all these potential addresses or are they permanently set for each device?

Answer

My first question is: If the chips are locked on the 0x20s won't there be any conflict IF any another i2c device uses the same schemes?

Correct. Another slave device which uses address 0x20 - 0x27 would conflict with an existing MCP23017 device using the same address within that address range, if they were connected on the same I²C bus. Each I²C slave needs a unique address on an I²C bus.

Two ways to mitigate a slave address conflict would be either spreading the devices across multiple I²C buses on the I²C master (e.g. the Raspberry Pi), or using an I²C multiplexer device on a single I²C bus (which effectively creates multiple I²C buses itself). [See below for another approach.]

Secondly: Is there a way to modify the basic addressing scheme (0x3*, 0x4*, 0x5*) to maximize all these potential addresses. Or are they permanently set for each device?

This depends on the device (i.e. read their datasheet) but typically the I²C address, or the range of selectable I²C addresses, is fixed for each model of slave device.

One exception is where a slave device is totally programmable (e.g. some I²C slaves are actually PIC devices running firmware to make them into permanent I²C slaves) and in those cases, I have seen more flexibility about which addresses they can be programmed to use.

---

Edited to add: Another approach to avoid I²C bus address conflict, as kindly commented by @DoxyLover, is to use the Linear Technologies I²C address translators - LTC4316, LTC4317, LTC4318. These devices re-write the I²C addresses "on-the-fly" between their input and output "channels". Effectively, they create new I²C bus segments, with a configurable pattern of (in theory, transparent) I²C address translation between the original and new I²C bus segments.

From their datasheets, they also add other features e.g. built-in "stuck bus" detection and voltage level translation. However, while they support common I²C features, there are a few which they don't support e.g. 10-bit addressing and Device ID. As always, read the datasheets.

In the context of the original question, an LTC4316 looks like it would be able to create a new I²C bus segment, where another set of (up to) eight MCP23017 devices could be connected. Let's assume that I²C addresses 0x30 - 0x37 are free on the I²C bus directly connected to the master, but the new set of MCP23017 devices need to use their fixed addresses 0x20 - 0x27. The LTC4316 would be configured with a "translation byte" value of 0x10.

On the LTC4316 "output" I²C bus segment, the new set of eight MCP23017 devices "see" their usual 0x20 - 0x27 I²C addresses, as they require. However on the "input" I²C bus segment where the I²C master is connected, the I²C master would address them using I²C addresses 0x30 - 0x37, with the LTC4316 translating an address of 0x3n on the "input" (master side) bus segment, to 0x2n on the "output" (slave side) bus segment [where n = 0 - 7].