I2C Multiple Slave addressing

Hi Abu,

each I2C slave need his unique address! Have a look at the code examples http://focus.ti.com/mcu/docs/mcuflashtools.tsp?sectionId=95&tabId=1538&familyId=342; there you will find master and slave source code examples for I2C.

Pls also look at the 'known issues' for the eZ430-RF2500 in the wiki http://processors.wiki.ti.com/index.php/EZ430-RF2500#Known_issues. No. 2 says:

Issues getting I2C to work: On the eZ430-RF2500 development board the I2C clock line (P3.2) is also connected to the CC2500 chip. It turns out you have to add P3DIR |= 0x0F before P3SEL |= 0x06 in order to disable the CC2500. Once this is done the I2C clock line works correctly.

Rgds
aBUGSworstnightmare

The I2C bus protocol does not support dynamic addresses. All I2C devices have a fixed address. On mos tof them, this address is assembled by a device-dependent part and a hardware-configurable part such as sone or more Input pins defining the LSBs of the address.

There is no protocol that will allow dynamic address assignment. Also, since it is likely that two devices with the same firmware and the same power-up time will generate an identical chain of pseudo-random values, there is no point in using such an approach. Also, the master needs to KNOW the addresses of its slaves, else it had to poll any possible address and then it still couldn't decide which is which.

Abu is looking to do some dynamic address assignment using I2C. It is possible to do so using some fancy techniques. One of them is actually a derivation of I2C called SMBus. This protocol is exactly the same as I2C but with ARP (Address Resolution Protocol). Can you guys think of any other techniques (not necessarily standards) to solve this problem of ARP? Any other ideas are much appreciated.

-Nihad

Sure, there are several.

You can go for a random address and broadcast it as a broadcast magic package. If you don't get a 'I have the same addres' reply from any other of the attached devices, you can keep it, else you should try another address.

The master then can use a technique similar to the PCI bus enumeration to determine which devices are on the bus. Broadcast a 'start scan' message, then a 'respond' message. In the respond message, every device will respond simultaneously, but when it detects that another device is sending a low bit where itself would like to send a high bit, it stops responding to this scan. At the end, only one device made it through the full 7 bit address range and the master now knows its address - and the next byte can be used as a device identification info (what type of device). Then another 'respond'  request is started and since there was no 'start scan' message, the previously identified device won't respond anymore. This repeats until no more devices respond and the master gets a 0xff as response. Then all devices on the bus have been enumerated and identified.

The enumeration, however, cannot be easily implemented using the I2C hardware. It likely has to be done by bit-banging.

The tricky thing is to combine the automatic address finding with the master scanning process, since usually master and slaves start simultaneously. So both have to be implemented so they don't conflict. E.g. the master starting the enumeration as soon as it detects another address evaluation traffic or such.

And of course all this requires the slaves acting as masters too on some point, so implementation of the multi-master protocol is necessary, including bus arbitration.

It's far easier (and the code is much smaller) if every device has its own fixed address, maybe set using some port pins. As it is done for every normal I2C slave device.