4
\$\begingroup\$

I'm having a problem with a system I'm designing that should support multiple modules, these modules communicate over the I²C bus and all have their own micro-controller which takes care of their own address.

As I don't want the users to have to specify the address using dip-switches, the micro-controller should detect the assigned address (in EEPROM) and if it's the default address it should query the master for a unique address. This works when you connect only one module at a time, but when all the modules are connected at once they will all listen to the same address.

Therefore, I thought of using a I²C repeater (PCA9514adp, or similar), which I can enable or disable (which will basically disable the SDA/SCL out of the IC). The micro-controller will disable the bus when it detects the default I²C address and after querying the master for a unique address it will reset and open the bus so that the next module can request a unique address.

The problem I'm having now is that the data-sheet specifies that I shouldn't use more than 3 repeater on the bus and that's simply not enough so I guess that idea can be put in the bin...

So I guess my question is: how can I disable the I²C bus, so that only one module listens to the default I²C address at the same time, but without the limitations of the I²C repeater?

\$\endgroup\$
4
  • \$\begingroup\$ Unfortunately you've hit one of the problems that I2C was not designed to solve. \$\endgroup\$ Jun 29 '16 at 12:54
  • \$\begingroup\$ How are the modules connected? Are they daisy chained together? In other words, can one module (say 'a') connect to the main board, then the next module (say 'b') connects to the first module 'a'. \$\endgroup\$ Jun 29 '16 at 13:21
  • \$\begingroup\$ @IgnacioVazquez-Abrams: Actually, the multiple-master protocol handles this just fine. \$\endgroup\$
    – Dave Tweed
    Jun 29 '16 at 13:26
  • \$\begingroup\$ @TomCarpenter The modules are indeed daisy chained together. My initial plan was to have each microcontroller act as a master, so that we have a master-slave/master configuration. The microcontroller in turn toggles the i2c repeater so that the chain can be broken in order to allow the address assignment by the 'master-master' \$\endgroup\$
    – Roland
    Jun 29 '16 at 13:28
3
\$\begingroup\$

Since you were thinking of using an I²C repeater (PCA9514adp), it would be easier to use a handshake signal that depends upon connection order. This would be daisy chained, so two pins, an input (from previous) and an output (to next).

\$\endgroup\$
4
  • \$\begingroup\$ I'm not sure i'm following you... The two pins you're describing, I suppose you mean other pins than the SCL and SDA? That does make some sense, since i'm using microcontrollers as the brains for the modules... \$\endgroup\$
    – Roland
    Jun 29 '16 at 15:46
  • \$\begingroup\$ Yes, an additional two pins, you would have had to use one additional pin to control the repeater. \$\endgroup\$ Jun 29 '16 at 15:49
  • \$\begingroup\$ +1. Given the slaves are MCUs, you could also use the reset pin so as not to use any additional I/O pins. Each module has an output (what would have been the control signal of the PCA) which connects to the reset pin of the next module (with pull-down resistor). When each module is released from reset by the previous module, it would keep the rest of the chain held in reset until it has an address, then releases the next module and so on. No repeaters required. \$\endgroup\$ Jul 1 '16 at 1:01
  • \$\begingroup\$ @TomCarpenter Wow, I can't believe it could be that simple! \$\endgroup\$
    – Roland
    Jul 1 '16 at 6:45
3
\$\begingroup\$

This can be done, but it requires that you support multi-master arbitration on your I2C bus.

In order to explain, I need to make a distictiion between your application's "system master" device and any device that may be functioning as an I2C master at a given time.

All devices, including your system master, need to be capable of operating as both I2C masters and I2C slaves.

The system master would respond (as an I2C slave) to a single reserved address. Each of the other devices, when it comes online, would execute a transaction (as an I2C master) to that reserved address to get its own slave address assignment. Thereafter, the system master would use that assigned address (as I2C master) to access that device (as I2C slave).

\$\endgroup\$
11
  • \$\begingroup\$ so, if I understand you correctly: the system master is both a master and a slave on a reserved address. All the modules in turn first act as a master to request an address and after address assignment reset to be slave only? \$\endgroup\$
    – Roland
    Jun 29 '16 at 13:29
  • \$\begingroup\$ Yes. The point is, you need to correctly support arbitration on the bus, because multiple devices might attempt to get their slave addresses simultaneously. In particular, you need to handle the case where they all start up in lockstep at system power-up, and prevent them from all believing that they have the same slave address. Each device needs to have a unique ID that is used in the arbitration process. \$\endgroup\$
    – Dave Tweed
    Jun 29 '16 at 13:49
  • \$\begingroup\$ If each device has a unique ID already, you don't even need multi-mastering. Just have the master read the unique ID from the default address device - the slave with the first 0 bit in its unique ID will win out because the other slaves can detect that the level of the data line is not what they are trying to send. But that requires a unique ID. \$\endgroup\$ Jun 29 '16 at 13:57
  • \$\begingroup\$ @DaveTweed but that basically means I'm back at square one, as it's not really possible to assign a unique ID to the modules... \$\endgroup\$
    – Roland
    Jun 29 '16 at 13:59
  • 1
    \$\begingroup\$ @Roland: There must be something that makes the modules functionally distinct. If not, what's the point? You can use whatever that is to also make them distinguishable on your bus. \$\endgroup\$
    – Dave Tweed
    Jun 29 '16 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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