How are unique I2C addresses handled in mass production

[u/juaspo]

Hi!

I am developing a product that will be utilising I2C protocol for communication with various things like LCD, BMS and more. I just realized that these component have unique address ids and im wondering how that is handled in mass production units when you obviously dont want to update the source code for each device to match the unique ID of the component.

[u/AutoModerator]

Do you have a question involving batteries or cells?

If it's about designing, repairing or modifying an electronic circuit to which batteries are connected, you're in the right place. Everything else should go in /r/batteries:

/r/batteries is for questions about: batteries, cells, UPSs, chargers and management systems; use, type, buying, capacity, setup, parallel/serial configurations etc.

Questions about connecting pre-built modules and batteries to solar panels goes in /r/batteries or /r/solar. Please also check our wiki page on cells and batteries: https://www.reddit.com/r/AskElectronics/wiki/batteries

If you decide to move your post elsewhere, or the wiki answers your question, please delete the one here. Thanks!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/triffid_hunter]

They're not unique - there's only 126 available addresses, and the address for each device is listed in its datasheet.

[u/markus_b]

I think you misunderstand this. The Bus address for the same device is always the same. The LCD has always address 0x16, the BMS 0x45, etc. Some devices may have a unique serial number, but it is not used for addressing.

[u/juaspo → u/markus_b]

Ok thanks for the clarification! I get it now.

[u/agent_kater]

I think you're mixing something up here. I2C usually doesn't have unique addresses.

So when you use more than one device that has the same address, you put them behind something like a TCA9548A.

Dallas 1-wire protocol has unique addresses. The way this works is that during startup the master runs a binary search through the address space, asking "is there anyone on the bus with an address above X", if more than one device answers, it splits the range in two and asks again, until it has identified all the devices on the bus.

[u/JimHeaney → u/agent_kater]

Yep, the terms you're conflating OP are "bus unique" (only one device with address 0x10 allowed on the bus) for i2c and similar, and "globally unique" (only one device with address 0x10 in the entire world) for OneWire, MAC, etc.

Every device with bus unique components has the same addresses and therefore the same code. In a globally unique device you need to ID them some other way, or treat the ID as a variable (e.g. you determine "the MAC" and use "the MAC" here, rather than finding the MAC is 10:32:24:09, then updating your code to use 10:32:24:09).

[u/juaspo → u/agent_kater]

Ok thanks for the clarification. I have worked with both a while back so I might have confused things together

[u/jacky4566 → u/agent_kater]

*or use an IC with configurable address. Or use SPI because it's better :P

[u/JimHeaney → u/jacky4566]

SPI isn't better in most applications. The higher bandwidth isn't used by most devices, and you quickly increase routing complexity with all the GPIO 

[u/jacky4566 → u/JimHeaney]

IMO. If you are working on any small low power products SPI should 100% be preferred.

SPI Push-Pull design means lower consumption by nature because you only have to worry about line capacitance. With I2C you have line capacitance and active current drain while LOW.

The higher bandwidth also means the CPU is not spinning IDLE waiting for data. Get your data, get the math done, go back into STOP0 states much faster. But also I2C FM+ is a thing with 2 bits more overhead.

We just did a pedometer application with accelerometer data bursts of 192B every ~500ms. Since this product also has SPI flash it was less routing overall.

Places I have worked prefer SPI and fallback to I2C for GPIO constraints, routing, or other reasons.

There is a much bigger list of factors that go into I2C v SPI of course, and its an old hammered out debate. I just wish people not to write off SPI too soon in their projects.

[u/2N5457JFET → u/jacky4566]

pedometer

Are it's readings admissible in courts, or is it the same case as with variograph, that results can be easily skewed or misinterpreted and courts dismiss them as evidence of a crime?

[u/jacky4566 → u/2N5457JFET]

You should always cross reference with your E-meter and be sure to spool up the turbo encabulator for the best results.

[u/TechE2020 → u/JimHeaney]

You also run the risk of being out of a job because SPI just works.

[u/juaspo → u/jacky4566]

Yea since bandwidth isn't a problem and we are a bit short on pin, using I2C would be the way to go here for us.

[u/Real-Entrepreneur-31]

Some modules have open solder pads that you can short to change the adress. If you use multiples of the same LCD for example.

[u/zydeco100]

You standardize the components used and wire them up to have known addresses. You're confusing a "unique address ID" like an Ethernet MAC with the I2C address scheme, which is a single byte. You can vary the I2C address of a part - sometimes - by changing how certain pins are ground in the design. But then those parts and addresses should never change once you hit production.

[u/commonuserthefirst]

If you only have two conflicting devices for the same address there is a trick, that has worked for me before, I'm sure I'll get lots of reasons why this is bad but in practice it has been ok.

Put one device on the i2c bus as normal, put the second one on with clock and data swapped, swap the SDA and SDC in software when you want to read the second device.

Otherwise, some devices, like the laser TOF VL53L0X devices don't have solder the address solder pads, but can have address changed by software, until next power up. In that case you just need extra VCC lines used like chip select to wake them up one at a time and change the address, then next one etc.