# Changing I2C address

I need to connect two Si114x light sensors to one I2C bus. I don't have them physically yet. Every sensor has the same I2C address, so connecting them with the default settings would mean a conflict. However, the datasheet (http://www.silabs.com/Support%20Documents/TechnicalDocs/Si114x.pdf) mentions a BUSADDR command which modifies the address, and the default value of the modified register is 0x00 (not 0x5A which is given as a slave address, that's a bit weird).

My question is: does the sensor keep the address in a non-volatile memory? The datasheet doesn't say it explicitly. Can I just connect one sensor first as the only sensor to the bus, reprogram its address and then add the second sensor? Is it some kind of pattern in I2C devices? If not, the address modification command wouldn't make sense to me.

• I'd bet my bottom dollar that it doesn't have a NVM – Dzarda Jan 29 '14 at 15:05
• Second that, if you want to connect multiple sensor you'll have to use multiple I2C busses (not that difficult in SW), or mux a single bus in hardware (muxing just the SCLK, which is unidirectional, will do). – Wouter van Ooijen Jan 29 '14 at 15:11

On page 54, the datasheet states:

I2C Address[7:0] Specifies a new I2C Address for the device to respond to. The new address takes effect when a BUSADDR command is received.

That pretty much means, that you first set this RAM value, then call the BUSADDR command.

Anyway, I think your only shot is to separate one of the sensors somehow. This could mean a transistor for holding the SCL line high while you program the other sensor's address. After the initialization, you can keep this transistor conducting.

simulate this circuit – Schematic created using CircuitLab

... I hope I didn't mess up the MOSFET's orientation ...

Of course, this requires a separate signal. And I don't think you can do without it.

This may not answer your question directly, but another way around the problem, that does not require changing the device addresses, is to use a CD4066 to connect one of the two sensors at a time, like in the Wayne and Layne's Arduino Video Game Shield. Scroll down to the sction entitled Nunchucks. There's also links to schematics and firmware.

Wii nunchucks (the wireless controller of the famous videogame) show the same problem: they connect to the main wireless controller using I2C, but they all have the same address of 0 (zero).

What the authors of that device cleverly did was to use a bidirectional switch IC (the CD4066) to communicate with one controller at a time, disconnecting the other from the data lines while doing so. Below is a diagram showing the general idea behind their design.

I've built such a device using their open source schematics and it works perfectly with both controllers hooked up at once. Maybe that's an option for you to consider if the setting of the addresses (as suggested by Dzarda) fails.

If you are using software bit-banging for the I2C master, and the parts you are using do not use clock stretching, a simple trick for using two I/O pins to connect two identical I2C parts is to have one pin connect to SCL of the first part and via resistor to the SDA of the other, and have the other pin do the opposite. The one thing to watch out for (and the reason software bit-banging is required) is that if one isn't careful, the device whose SDA/SCL connections are reversed from the device one is trying to talk to might misinterpret communications meant for the other device as a request to start talking to it. If the SCL meant for one device has a falling edge while SDA is high (which would be normal when sending a "1" bit), the other device will see that as a "start" condition. Every time SDA goes from low to high while sending data to the first device will clock in a "0" to the second; a "stop" condition for the first device will clock in a "1" to the second. Sending to one device certain sequences of data followed by a stop condition could cause the other to see a start condition followed by a valid address. Bit-bang I2C implementations may prevent that by sending redundant pulses on SDA at certain times while SCL is low, but hardware I2C master implementations can't do that.

• Thanks for the idea, but in my particular case I have to use DMA, so I don't take bit-banging into account. – PiotrK Jan 30 '14 at 17:06