1
\$\begingroup\$

I was looking in the NXP product selection guide for ARM Microcontrollers. There are multiple I2C modules in most of the ARM MCUs.

Since I2C is a multi-master multi-slave protocol, is there any clear advantage to this approach?

\$\endgroup\$
  • 3
    \$\begingroup\$ Different speeds and limited number of supported nodes comes to my mind \$\endgroup\$ – PlasmaHH Apr 21 '17 at 8:47
  • 1
    \$\begingroup\$ Device could be master on one I2C bus and slave on the other one... \$\endgroup\$ – Flanker Apr 21 '17 at 9:02
  • 1
    \$\begingroup\$ I2C devices often have fixed addresses, or addresses that can be varied by one or two bits. You can't have more than one device with the same fixed address on the same bus. \$\endgroup\$ – pjc50 Apr 21 '17 at 9:07
  • \$\begingroup\$ Monitors have an I2C EEPROM in them that can be read by the computer and contain EDID information. Since this exposes an I2C bus to the outside world, it's possible for something to cause the bus to stop working. Having a second bus for internal components is wise in this situation. \$\endgroup\$ – Steve Apr 21 '17 at 13:36
7
\$\begingroup\$
  • Ability to have multiple independent buses
    • Avoid address conflicts:
      • You can have two identical I²C devices with hard-coded addresses that way (e.g. temperature sensors), or;
      • if the address is only variable by a few bits, have more devices than addresses that fit into these bits.
    • Higher cumulative throughput
    • Not having to wait for one I²C transfer to be finished for the one on the other bus to start
    • Independent speeds
    • Having one bus for devices that are fully I²C compliant, and one for those not supporting advanced features like clock stretching (and would become confused)
  • Your MCU might be "logically" a peripheral on one bus, and a controller on the other
  • Layout simplification
  • Higher permissible rates
  • Different pull-ups for different device characteristics
  • Error isolation
  • Higher computational efficiency
    • Configure DMA to put I²C data from one interface to a different memory region than the other
    • Have different interrupts for different I²C buses
    • Have two threads accessing different I²C devices without needing to mutex access to the I²C hardware.
  • Energy saving
    • Only pulling down a small I²C bus with weak pull-up resistors wastes less energy than pulling down a large bus with strong resistors
\$\endgroup\$
  • \$\begingroup\$ Sam, sorry, rolled back your edit. the point really was "logical" roles (device/controller) as opposed to bus roles (master/slave). You can have a slave that actually logically controls the bus master! \$\endgroup\$ – Marcus Müller Apr 21 '17 at 12:40
2
\$\begingroup\$

Two clear benefits of independent I2C busses are isolation and throughput.

A short on an I2C bus stops communication with all devices on that bus. The risk of a short is generally higher with I2C busses going to connectors and off-board. So multiple I2C controllers lets you have one for on-board devices and another for off-board devices. If you have several off-board destinations then a separate I2C bus for each destination reduces the consequences of a short circuit on any of those busses.

Equally, long busses running off-board will be harder to keep within the capacitance limit in a nice multi-drop arrangement, as a star arrangement tends to come about. This leads to worse achievable bus timings because of reflections from the networks stubs. Separate busses can be run at different speeds and arranged in a more linear multi-drop layout.

If your I2C devices need high throughput or just low latency then fewer devices per bus may be needed to achieve this.

You could solve some of these problems with I2C bus isolation ICs. But multiple masters are cheap to put in a single microcontroller and they keep the chip count down.

\$\endgroup\$

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.