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.
At $3.50 to $1.80 depending on quantity, it’s one of those useful chips for a quick design where you have no time to spec a different chip or use another pair of pins for a separate I2C bus on your microcontroller…but won’t find its way into a cost-conscious BOM (as is true for many other parts from Linear).
Unless cost concerns have led to using a micro with too few I/O pins and a second I2C bus isn’t possible.
That would be a hurried fix indeed…the difference between package styles or upgrading to a uC variant in the same series with more I/O pins usually far, far less than $1.80.
Or if another uC can be used to perform the same function. An Attiny10-TSHR in case SOT23/6 is €0.29 in quantity of 5 at tme.eu. I have no idea if they can match the full speed of i2c though.
There was a project a while back using attiny to inject some data in the middle of i2c exchange by pulling SDA low, cant remember what it was, processing ….bzzzz bzzz
here we go, http://hackaday.com/2016/07/12/i2c-bit-injection-adds-memory-banks-to-everything/
On many occasions a single extra SDA line is enough, if the SCL can be shared. There nothing wrong at clocking SCL with a idle SDA.
You can even reuse the SCL and SDA as SPI clock and either MOSI or MISO data. I have used this trick on a Motorola 16 pins HC08 about 20 years ago, back to the days when low pins count programmable uC was hot new stuff…
I have used this trick many times. Often you can also clock SDA with an idle SCL. This creates start and stop commands, but the device will not do anything because it never gets its address.
This chip is quite useful. If you’re using Chinese displays with only I2C and no address pins exposed, you can’t have more than one display of the same model – which is very sad. I wanted to make an ATTiny-based solution for this, but it seems I can save lots of time by just buying this.
My thinking would be to just use an ATTiny as well. What Joshua neglected to mention, however, is that this chip also performs voltage level translation. That and the fact that it’s capable of 1Mb/s fast mode is what makes the ATTiny solution unable to perform the same task.
I’ve used this on a project. Some more complex I2C devices may only come in one address, or they may have pre-programmed/user programmable addresses (but requires a special fixture or timed pin toggle to write the address). Often devices with FLASH programmable addresses are available pre-programmed from the manufacturer (with a part number suffix), but it’s unlikely you’ll find very many of these variants in stock or available in small quantities off the shelf. So this is a quick fix to multiply your numbers of these devices.
Caveat though, translators and isolators sometimes have special low/high logic level limitations as part of their design. This can sometimes cause conflicts. The LTC4316 only pulls down to about 0.4V in some situations. Most devices should be ok with this, but then some isolators like the Si8600 series on side-A will sometimes not recognize this as a “low” condition. You can try flipping the isolator to operate in reverse, using side B as master side, as side B has a higher “low” input level.
I’m in the market for a heat shrink labeler… I’d like to know how you like what you have and where can I buy one :-)
Thanks
Wow. I didn’t realize this was a real thing. I’ve been printing labels on paper then sliding them inside clear heatshrink tubing for years. This would be a huge time saver. :)
I used to have one at work, but it was a keypad type.So I was more often then not just pulling out a sharpie and hand writing the labels…
Aye, it’s the Brady BMP21-PLUS Handheld Label Printer. I have one at my current gig, so I used to just buy the permasleeve cartridges and print labels there. A few months later, I could totally justify getting one. A few labels go a long way in ruling out uncertainty. ..
I can recommend the Brother PTouch P700. It’s USB connected, has a nice windows-only utility (works within virtualbox).
Drawbacks:
1. it wastes about a centimetre of tape per print job, so if you want to print multiple labels it can be advantageous to prepare a spreadsheet and use that as datasource
2. It is not possible to print an inverted color label, so if you print a barcode on al black label with white text you cannot read it (at least using a smartphone barcode scanner app I tried, didn’t try a real scanner).
Otherwise the software is good, the printer is nice and there are multiple third party label cartridge makers.
it would be interesting if this could be done on a digital logic FPGA or CPLD for a larger number chips. I still think a 4:1 or 8:1 mux is a more cost effective solution but even there you are limited to what the MUX address lines are. Ultimately though, a 7-bit address space is just woefully inadequate for todays designs — but it’s a 40 year old spec so no surprise there.
nice article, did not know this came out in 2015.
i2c addressing reminds me of IRQ/IO conflicts back in the day of ISA, now those were fun times
FSVO ‘fun’ of course. YMMV etc…
If you can’t figure out what they’re referring to for the VL530X Absolute Distance Sensor, it is here:
http://www.st.com/en/imaging-and-photonics-solutions/vl53l0x.html
There’s also the VL6180X, which is very similar
http://www.st.com/en/imaging-and-photonics-solutions/vl6180x.html
wow, i’ve been thinking lately about how awful my breadboards always turn out, little nests of chaos. but this article helped me realize, my boards look that way because i don’t photograph them.
“… I²C address translation may be for repurposing smartphone MEMs sensors. Sensors like the BNO055 IMU or the VL530X absolute distance sensor…”
The VL530X does allow one to change the address. It isn’t persistent however and must be changed each time it is powered up (and you will need to hook up a pin off your uC to the VL530X shutdown pin). See their application note https://www.pololu.com/file/download/VL53L0X-AN4846.pdf?file_id=0J1239
I’ve ran 4 of them on the same bus with no problem though in the end I found I preferred to use a PCA9544A mux. It made wiring and coding much easier to do.
It appears this little chip can also mediate between different-voltage components, which is useful too.
Just the thing for switching between sensors and Flash memory!
Recently I got a new task where I needed to make wrist worn 360 color sensor array. The wiring should be as little as possible but there must be at least 16 color sensors (30 degrees for each), I looked for translator chips, oddly enough this is the only available single address translator chip in the market (There is Dual translator for cousin LTC4317). It does the job, even serves as bus voltage level shifter. There is a handy Pass through mode as well.
Much more important. You can label heat shrink tubes?
Sorry, I need to go shopping!
I know google is easy (already have some samples on order from LT), but can I ask why there isn’t a link directly to the product landing page included in this article?
It is something to do with changing the context of the write-up into an advertisement, or some such? I only ask because I’m sure it’s not the first time I’ve noticed this!