i2c automatic address assignment

Question

History:

I decided to design a circuit with some peripheral ic's. Although SPI may achieve great data rates, because of its master-slave architecture and separate chip select pin requirement, I decided to use I2C because of its multi-master and real serial design. (SPI is not a fully serial protocol, it's more like a hybrid protocol: serial port for data exchange, parallel port for chip select lines)

Problem:

I've been planning to add some adc, dac, gpio ic's to a microcontroller but these modules are produced with a few slave addresses available. Manufacturers are embedding slave's addresses into the ic hardware. What a bad idea! So, I have faced with the addressing problem of i2c protocol.

Some of the ic's present address assignment pins (3 pins, which means I would not use more than 7 of them). That's not enough in my case.

Some people offer scanning addresses from 0x00 to 0xff, but this is not a good approach because it's time wasting (I think). Someone says "There are i2c buffer's or i2c MUX's you may use" or even another microcontroller for address translation (NAT like approach) but weren't we choosing and using i2c for simplicity (like fewer routes on board, flexibility etc) in the first place?

There are people having this address assignment problem (eg. http://www.linkedin.com/groups/Methods-enumerating-I2C-slaves-autoassigning-4023060.S.113408032)

Suggestion:

Automatic address assignment could be done with an algorithm something like that:

1. Slave components would have 2 bytes of non-volatile memory in order to keep their addresses permanently.
2. Slaves will have a default address (eg. 0x01).
3. On power up, if slave has not been assigned with an address different from default, slaves will become master and ask for an address from the host (eg at address 0x00).
4. Our actual master node (microcontroller, the host) (in this example which has "0x00" address) will act as a slave naturally, because there is another master on the bus and will respond (assign) next available address to the slave.
5. 0x01 address will be reserved for broadcasting. Master may use this address in order to make slaves reset their assigned addresses.

That would be enough for automatic address assignment.

Yes, I know about SMbus. It has automatic address resolution protocol, but it has other limitations (speed, timeout etc) which makes me not want to prefer SMbus over I2C.

This address assignment protocol may be optional and could be activated by a single pin on the ic package. So, it will be backwards compatible.

Question:

Probably I'm not the smartest person in the universe but,

1. is there an address assignment protocol that vendors already implement in i2c
2. if not, what would be wrong with this protocol
3. if nothing is wrong, why don't they possibly start implementing a protocol like this (again, I know I'm not the smartest person, so they should have taught about this problem and they should have already discovered an algorithm like this)

Answer 1

Your problem can be solved with SMBus which is logically an extension on I2C. SMBus supports an ARP, wherein it can detect multiple IC's of same address, and assign them a different address. The ARP process basically reads a UUID ( a unique id per device; all the different devices in the same lot will have a different UUID) from the slave address (there may be multiple devices on this slave address). Due to the I2C bus arbiration process, only one slave will succeed at a time, and the master successfully reads its UUID. Then the master assigns a unique address using that UUID as reference. The process is repeated until all the slaves get a resolved address.

Answer 2

is there an address assignment protocol that vendors already implement in i2c [?]

The current protocol is, each device maker writes to NXP and requests an address be assigned for each device they make.

what would be wrong with this [proposed] protocol [?]

I2C is often implemented on very low-cost parts.

Your proposal requires adding non-volatile memory to parts that mostly don't already have it.

Non-volatile memory typically requires specialized process steps in IC manufacturing.

Adding process steps increases the cost of an IC.

So your proposal isn't compatible with maintaining the low cost of many I2C parts.

Also, your proposal requires every master device to implement some protocol to assign the new addresses when requestd. This adds complexity that many users might not want.

if nothing is wrong, why don't they possibly start implementing a protocol like this?

This is marketing question, not an electronics design question.

Answer 3

The problem of the automatic address assignment seems like it is a usable concept in the cases where you are making the devices out of low cost microconrollers.

Trying to lay this protocol onto low end chips like port expanders, muxes, temp sensors, eeproms and similar chips really puts more design burden and silicon area onto the chip. This makes the simple chips cost more and more difficult to implement into a platform level deployment.

Answer 4

Having the master assign an address,and some of the other features you describe, are simply not part of the i2c standard. The result might work but it would not be i2c. You lose many of the benefits of using a standard.

Answer 5

If you really need this assign address by host capability on absolutely every peripheral you need to use, you should add a gate microcontroller to every peripheral and implement SMBus ARP on those. Those microcontrollers also translates the address issued on the bus to the address discovered from the device it attached to.

Note that this will result in you having to bit bang I2C somehow. But since you are already using microcontrollers translating protocols, you might as well just design your own protocol stack.