Is there a maximum number of I2C slaves that an I2C master can drive? What are the physical limiting factors (like current drive, capacitance or something like that)?
9 Answers
The software limiting factor is the size of the address used for the slaves: 7-bit or 10-bit, which support 127 and 1023 devices, respectively. Physically, there are two restrictions. First, the physical size of the bus because the bus is only meant for short runs (the inter IC part). If the bus is too large there are capacitive loading and propagation delay effects that need to be dealt with. Second, some devices can't support the full range of I2C addresses. As examples, the MPU6050 gyroscope only supports two addresses, and some devices reserve specific addresses for special purposes.
-
3\$\begingroup\$ You have an off-by-one error. 7 bit addressing supports 128 addresses (0 to 127). 10 bit addressing support 1024 addresses (0 to 1023). \$\endgroup\$– CurtisHxCommented Jul 27, 2015 at 13:36
-
4\$\begingroup\$ This ist not an off by one error. It is an "off by 6 error" because there are 7 reserved addresses not just one. \$\endgroup\$– kruemiCommented Aug 19, 2015 at 4:20
-
\$\begingroup\$ The addressing scheme is dictated by the devices on the bus, master or slave. Some devices have preset address ranges and reserved addresses. Other devices, many micro controllers for example, have no reserved addresses and can use any address in a given bit scheme. \$\endgroup\$– vini_iCommented Aug 19, 2015 at 12:42
-
1\$\begingroup\$ These numbers are somewhat correct, however a caveat is needed. There are a few reserved addresses such as 1111 XXX and 0000 XXX. This means 7-bit = 2^7 - 16 =112 usable addresses, 10-bit is the full 2^10 1024. 8-bit isn't (shouldn't be a thing) it typically is including the R/W bit on 7-bit. nxp.com/docs/en/user-guide/UM10204.pdf \$\endgroup\$– busfaultCommented Dec 7, 2018 at 14:09
-
\$\begingroup\$ @busfault I acknowledge that 8bit addresses are not effectively a thing. I have removed them from my answer. Most microcontrollers can choose to ignore some or all of the reserved addresses and use the full address range. I note in my answer that this is device specific. \$\endgroup\$– vini_iCommented Dec 7, 2018 at 14:55
The maximum number of nodes is limited by the address space, and also by the total bus capacitance of 400 pF, which restricts practical communication distances to a few meters.
Read more at I²C
Addressing limits the number of devices- some can use 10-bit addressing (fairly rarely used), which limits the number of addresses to 1024. There are a handful of 'reserved' addresses.
I2C (as opposed to "two wire bus" or whatever others want to call similar buses), should follow the NXP (née Philips) standard, UM10204 I2C-bus specification and user manual. That should be your primary reference document, not the various interpretations and subsets that exist elsewhere.
The maximum number of devices will be influenced by the drive capability of the weakest output (which in turn determines the minimum pullup resistor), the wiring and input capacitance, and the operating mode/frequency. See section 7.2 Operating above the maximum allowable bus capacitance if the maximum capacitance must be exceeded:
An i2c bus is limited mainly by the capacitance of the bus (and thus speed), and accessible device addresses. And physical board space.
But there is no real upper limit, when you factor in bus buffers, extenders, repeaters, hubs, multiplexers, switches (or any other name for a device that can switch between multiple busses). These add some i2c overhead, as may can be accessible via the same i2c bus. The PCA9548A for example, is an 8 bit bus switch.
This single chip can theoretically quadruple the number of i2c slaves (127 * 8) otherwise available. And the PCA9548A can be configured for up to 8 addresses on a single bus, so 8 * 8 * 127 devices. (math may be off). And that's just with this device and not more.
Frankly, there is no theoretical limit if you adjust for capacitance.
I2C specifies 2 address lengths, 7 and 10 bits, which gives a theoretical maximum of 128 and 1024 distinct address, respectively.
However, there are a few reserved addresses, such as 0x00 (general call). This further limits the address space.
If you are building a system where you have direct control over the I2C devices, you can use the reserved addresses for your own use, but the system will no longer comply with the I2C standard.
In addition to the addressing, there is the physical bus limitations. Each device on the bus needs to be able to pull the bus low in a certain time span (depending on the bus speed). If the bus has lots of capacitance, devices may not be able to pull SDA low fast enough, and the pulls ups may not bring SDA back up fast enough.
Now, the hardware problems can be overcome with a little bit of driver hardware. I'm working on a project right now that uses I2C to communicate with devices over several 10s of meters. The main bus uses 24v, and each board has a driver that steps it down to 3.3v.
In a nut shell, the physical limitation of I2C can be overcome. The addressing can be overcome, but only if you have direct control over the device.
-
\$\begingroup\$ It has been almost three years since you were working on very long i2c buses. Did they work okay? \$\endgroup\$– wallykCommented Apr 13, 2018 at 21:14
-
1\$\begingroup\$ @wallyk I left that company shortly after posting that answer. I will say that given the right hardware, you can make I2C communicate over longer distances. However, there are other communication protocols that are designed for long distance and would probably be a better choice than I2C. \$\endgroup\$– CurtisHxCommented Apr 14, 2018 at 21:40
The primary limitation on the number of slaves a master can drive is generally going to come from electrical factors like bus capacitance, leakage, drive strength, etc. If one could construct slaves with zero parasitic capacitance and zero leakage, and if one could connect them with zero-capacitance board traces, then bus capacitance wouldn't be a factor, but in practice neither assumption is going to hold.
Addressing of devices which "know" about each other, on the other hand, isn't really a problem. It would be trivial to design a peripheral which would allow billions of chips to be connected using one read and one write address. Simply specify that every device must have a unique four-byte ID, and is required to listen to the write address all the time, but must drop out of every transaction whose first four transmitted data bytes don't match their ID. Further specify that devices may only respond to the read address if the last write transaction they heard matched their address.
If one wanted to add the ability to have the master determine the IDs of all connected slaves, one could reserve some special ID ranges for such purposes. For example, one could say that if the first ID byte is FF, then the next four bytes will be a mask and the four after that an ID; a device should stay connected (and ack the last ID byte) if the portion of its ID specified by the mask matches that given in the command. This would allow a master to identify at least one device using 64 transactions, and additional devices using 62 or fewer transactions each. Perhaps not the fastest possible means of device identification, but not bad given a search space of billions of device IDs.
Short answer: It depends
If you have (common) devices with 7 bit addresses up to 104 Devices (128 addresses - reserved addresses (0x00-0x07 and 0xF0-0xFF are reserved))(certain limitations apply) If you have (less common) devices that support 10 bit addressing up to 1024 devices (you can mix 7bit and 10bit devices and reach up to 1136 devices that way)
Now to the limitations: Most simple devices can only be configured to two to 8 different addresses. You can overcome this by custom ordering devices with different base addresses (but this normally means that you order a minimum ammount of devices) There are also hardware limitations (mainly bus capacitance) but this can be solved with special i2c drivers.
If you want to connect many devices over bigger distances I'd suggest to use a fieldbus anyway! I2C is intended for communication inside a device (like a TV set). I'm using I2C myself with a RaspberyPi with external cables of up to 50cm (even with T-Sections you should never have in a bus system). It works surprisingly well.
The number of devices connected to the bus is only limited by the total allowed bus capacitance of 400 pF. Because most ICs with an I²C interface use low-power, high-impedance CMOS technology, many ICs can be connected to the I²C bus before that maximum capacitance is reached
-
2\$\begingroup\$ This does not answer the OP's question in a complete manor. Try to answer all aspects of the question, even if using approximate values. Specify and/or leave a link to your source of information. \$\endgroup\$– user105652Commented Jul 5, 2016 at 18:24
With added multiplexer chips (like TCA9544A) or buffers (like PCA9515B) you can overcome all limits - both bus capacitance and addressing.
You can place 3 devices with identical addresses behind a multiplexer and select only one of them, communicate with it and later select another. Of course software gets more complex.
If you have long wiring you can place a buffer in the middle and overcome the capacitance limit.
-
\$\begingroup\$ No, you will still be limited: 4 Channels/ Multiplexer, per channel you have 4 Subchannels, then you have subsubchannels, subsubsubchannels and more. You have 3 Address-lines per channelswitcher: Is 4^(2^3)=65536 channels. Per channel you have 2^8 - 7 - 8 + 2^10 = 1265 Devices / Channels (When you also use Buffers) (the -7 are for reserved addresses and -8 for the multiplex addresses). 1265 *65536 = 82903040 Maximum Devices. \$\endgroup\$ Commented Dec 5, 2017 at 13:57
-
\$\begingroup\$ Edit: Sorry had a error: it is 2^7 - 7 - 8 + 2^10 = 1137 Devices / Channel => 1137 * 65536 = 74514432 Devices. But there may be more possible when you use IO-Expander to turn on and off some Buffers (What is far form practical use but a theoretical possibility). \$\endgroup\$ Commented Dec 5, 2017 at 14:09