i2c address translation

3 Articles

The I2C extender board on a white background, fully assembled, with two connectors and two indicator LEDs

Extenders And Translators For Your I2C Toolkit

April 5, 2024 by 5 Comments

If you’ve ever been laying out a network I2C devices inside a project box or throughout your robot’s body, you’ll probably know that I2C is not without its pitfalls. But for many of those pitfalls, there’s a handy chip you can use. [Roman Dvořák] from ThunderFly has experienced it on their drone building journeys, and that’s why they bring us two wonderful open source hardware boards: an I2C bus extender, and an I2C address translator.

The first board, an I2C bus extender, is based around the TCA4307 chip, and not only it lets you extend the bus further than it would normally go, it would also protect you. When the bus capacity is no longer handleable by your devices, or a particular misbehaving device gets the bus stuck, this chip will take care of it and dissipate your troubles. It will even let you know when your bus is wired up correctly, with a handy shine-through LED!

The second board is an I2C address translator. We’ve covered them before, but in short, address translators let you avoid I2C address conflicts while using multiple devices that share the same address. This particular module uses the LTC4317 chip, a common choice for such translation, and the board leaves no feature unimplemented. In the README, there’s quite a few pictures with examples of where this sensor proves mighty useful, too!

It appears that ThunderFly open sources a lot of their designs on GitHub, an effort that we salute. The designs are great to learn from, but if you’re just looking for turn-key hardware, you can get both of these boards from their Tindie store. The cables they use have locking connectors, but as long as the pinout matches, you should be able to solder a JST-SH socket and add these modules to your QWIIC toolkit.

A breadboard showing a tiny ESP32 board and two HMC5883L sensors connected to it on different pins

Avoid I2C Address Conflicts On ESP32 By Pin Muxing

February 28, 2024 by 20 Comments

Using hardware I2C on an ESP32? Do you need to connect multiple I2C devices with the same address? Normally, you wouldn’t be able to do that without extra parts, but on the ESP32, [BastelBaus] has found a nice hack — just connect your devices to different pins and slightly abuse the ESP32 GPIO muxing, no extra hardware required!

Initially, they tried separating SDA and SCL completely, and after a bit of tinkering, that’s worked out wonders! For this method, [BastelBaus] provides example Arduino code you could easily integrate into your project, and shows logic analyzer captures that demonstrate there’s barely any overhead. Later, they’ve also found out that you could multiplex only one of the pins, specifically, SDA, having the SCL line be common! As far as we see, this could also work out with split SCL, but do let us know if that doesn’t sound right.

Typically, such a problem is solved with an I2C multiplexer, and we’ve highlighted projects with them before. However, this simple method could also work on chips like the RP2040 or even the Raspberry Pi 4 — just a bit more limited, since the GPIO muxing for I2C has less available ports! Also, if you’re not using a chip with such a comfortable GPIO mux and you must use devices with overlapping addresses, check out the comment section under our I2C ecosystem article – there’s a fair few other methods you can use. And, if this method ever malfunctions for you, there’s a bunch of very straightforward ways you could debug your bus!

LTC4316 Is The I2C Babelfish

February 17, 2017 by 25 Comments

The LTC4316 is something special. It’s an I²C address translator that changes the address of a device that would otherwise conflict with another on the same I²C bus. Not a hack? Not so fast. Exactly how this chip does this trick is clever enough that I couldn’t resist giving it the post it rightfully deserves.

On-the-Fly Translation

What’s so special? This chip translates the address on-the-fly, making it transparent to the I²C protocol. Up until this point, our best bet for resolving address collisions was to put the clashing chip on a separate I²C bus that could be selectively enabled or disabled. In that department, there’s the PCA9543 and PCA9547 demultiplexers which we’ve seen before. Both of these devices essentially act like one-way check valves. To address any devices downstream, we must first address the multiplexer and select the corresponding bus. While these chips resolve our address collision problems, and while there’s technically a way to address a very large number of devices if we’re not time-constrained, the control logic needed to address various bus depths can get clunky for nested demultiplexers.

What’s so classy about the LTC4316 is that is preservers simplicity by keeping all devices on the same bus. It prevents us from having to write a complicated software routine to address various sections of a demultiplexed I²C bus. In a nutshell, by being protocol-transparent, the LTC4316 keeps our I²C master’s control logic simple.

How it Works

I mocked up a quick test setup to have a go at this chip in real life. Continue reading “LTC4316 Is The I2C Babelfish” →