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.

The LTC4316 sits in-between our address-clashing device and the rest of the I²C bus, acting as a temporary check valve. When an address is sent along the line, it’s translated in-flight to the “private” SDA line that the address-clashing device sees.

Once all seven address bits have flown by, the private SDA line is immediately reconnected to the system I²C bus (no more check valve) such that the address-clashing device can reply with an ACKnowledge if it was selected by the bus master. If it was selected, conversation proceeds as normal until the end of the transmission, at which point the private SDA line is disconnected again to setup for the next I²C transmission. As for when this disconnect happens exactly, the datasheet doesn’t specify, although I suspect it’s immediately after the I²C transmission finishes.

Setting the appropriate address is a matter of spec-ing the right voltages at the pins XORL and XORH. each voltage dictates the upper three and lower four translation bits for the devices internal XOR logic. To determine the exact translation byte we want, we follow two steps. First figure out what address we’d like our system bus to use to talk to the address-clashing device. Then we need to know the address-clashing device’s default address. With those two addresses, we then follow the equation:

new_address ^ translation_byte = default_address

…which means we need to perform the inverse XOR to get our translation byte. Luckily, the inverse operation of XOR is XOR, so we just need to solve:

new_address ^ default_address = translation_byte

Phew–that’s not too tricky.

To set the right voltages, the datasheet recommends a voltage divider. At first glance, this option seems somewhat power-inefficient. Luckily, the datasheet suggests resistors in the 100 kilohm range, which should be good enough for all but the tightest of power constraints.

Known Bugs

Following an address translation, there’s a slight chance for the SDA line to “glitch” and spit out one extra logic HIGH voltage level for a brief moment (shown above).

This issue is documented in the datasheet’s “glitch” section. Luckily, it’s no dealbreaker. Because SDA data is only read following the rising edge of the SCL clock line, this extra passes through undetected. As for where this glitch comes from, the datasheet doesn’t say explicitly. Nevertheless, I have a hunch that this glitch coincides with the the LTC4316 disconnecting it’s XOR circuit and reconnecting the private SDA line back to the system SDA line.

Why Translate Now?

I²C has been around for over 30 years, but the LTC4316 has only recently dropped onto our breadboards in 2015. Why such a huge delay for a chip that seems so useful? There’s no clear answer here, but here’s my best guess….

I²C was originally developed by Philips (now NXP) as a low-speed protocol for pin-constrained devices primarily living in consumer electronics (PDF). The mindset here was that oodles of consumer devices had similar interfaces (lcd displays, button panels, etc.) that could be handled by a dedicated device which could then communicate their results elsewhere upon request. This concept is modularity at it’s finest. Here, complicated functionality is handled by a dedicated device, freeing up the load of the primary controller.

The I²C device portfolio has since grown to accomodate hundreds of new devices. In most cases though, if we can think of wanting to use one or more copies of any given device in one system, the manufacturer has almost certainly enabled some way of configuring one or more of the devices address bits. Here lies the first reason why we wouldn’t see an address translator chip emerge for so long: the manufacturer has likely already predicted our needs and made address changing a feature that’s built into the device. Want to use one or two extra PCA9685 sixteen-way LED drivers? No problem. Just toggle one of the six available address pins. Does your BMA180 accelerometer address clash with another I²C device address? No sweat. Just tie pin 1 to logic LOW or logic HIGH to swap the address to the alternate.

Next off, for cases where we would want to handle multiple copies of a device, there’s already a drop-in solution: putting that device on an isolated bus as we discussed earlier. Yes, there’s a bump in software complexity, but unless we’re addressing nested levels of bus demultiplexers, the software remains fairly simple. In that sense, why change the I²C address when you can just bump the clashing device to another bus?

In my mind, the biggest application of I²C address translation may be for repurposing smartphone MEMs sensors. Sensors like the BNO055 IMU or the VL530X absolute distance sensor may have a second life in the robotics world in large arrays. Given that these are addresses are fixed, a translator may have it’s first use-case right here.

As for the practical use of this chip in general, who knows? Nevertheless, when the day comes that an address translation falls under into our sights, we’ll be armed to handle it.