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)


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)


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.


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)
  • \$\begingroup\$ Why not use SPI for your application? The data transfer is faster, and you can generate as many chip-select signals as you like by many different means. \$\endgroup\$
    – The Photon
    Oct 16, 2013 at 21:24
  • \$\begingroup\$ @ThePhoton but weren't we choosing and using i2c for simplicity (like fewer routes on board, flexibility etc) in the first place? \$\endgroup\$
    – Passerby
    Oct 16, 2013 at 22:15
  • \$\begingroup\$ @Passerby, simplicity and flexibility are usually competing goals. \$\endgroup\$
    – The Photon
    Oct 16, 2013 at 22:42
  • 1
    \$\begingroup\$ OP, keep in mind that i2c as is, is a 31 year old (now expired) patented standard with official "i2c" parts all going through NXP/Phillips for address assignment. Auto-assigning addresses would be a huge change to i2c and not worth it, as even smbus ARP hasn't been too popular (or so wiki says) \$\endgroup\$
    – Passerby
    Oct 16, 2013 at 23:07
  • \$\begingroup\$ @ThePhoton Why not use SPI for my application? Because I want to reuse my board drawings later if I need to add another ADC or GPIO. If I use SPI, I need to draw a line for the new component's CS pin. Also, however it's not mandatory right now, SPI does not support interrupts. In fact, since SPI is 10 times faster than most I2C's implementation, cyclic check for changes is a sensible option. Maybe as you suggest, I must use SPI for data exchange and a low end microcontroller with own serial protocol stack for chip select lines... \$\endgroup\$
    – ceremcem
    Oct 17, 2013 at 17:38

5 Answers 5


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.


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.

  • \$\begingroup\$ Okay, I understand that non-volatile memory is a huge cost. Here is another proposal (backwards compatible again): \$\endgroup\$
    – ceremcem
    Oct 16, 2013 at 21:51
  • \$\begingroup\$ @ceremcem, Stackexchange isn't really designed for back-and-forth discussion. Better venues for that kind of interaction would be our chat (chat.stackexchange.com) or the allaboutcircuits.com discussion forums or the "ECE" and "AskElectronics" forums on Reddit. \$\endgroup\$
    – The Photon
    Oct 16, 2013 at 21:57
  • \$\begingroup\$ Hmm... Ok, I may move the question right away. \$\endgroup\$
    – ceremcem
    Oct 16, 2013 at 22:50

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.


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.

  • 1
    \$\begingroup\$ It is part of the smbus standard though. See the section on Address Resolution Protocol. \$\endgroup\$
    – florisla
    Mar 27, 2017 at 8:41

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.