The tricky thing about I2C devices is there’s only a finite pool of addresses. What happens when there’s a collision or you want to use multiple identical devices? Enter the Multiplexer or MUX.
This week we assemble a MUX prototype and discuss some neat design-for-maufacture tricks we can use with resistor networks/arrays.
We also show off the upgraded PiicoDev Buzzer - available now!
Hi Michael
As usual a very good presentation.
I have a question regarding the I2C bus itself. Just what would be the maximum number of devices allowed on a bus if there was no provision to remove the pull up resistors. I note that most (and I assume all) of your PicoDev units do provide this facility but if one were mixing different sensors for example this provision may not be easily available. There must be a point where the number of parallel resistors becomes a problem, particularly the IO ports with lower current capability.
I bring this up as I don’t recall ever seeing too much mention of this potential problem and if an end user just goes ahead and strings a number of units together without any consideration for IO loading they could quickly run into trouble. I have seen the odd mention of “only one pull up required per bus run” or similar on the odd occasion but it is usually buried down into the “skim over” part of the text. The inexperienced experimenter could easily get to the hair pulling stage if the set up becomes border line.
One example of a published spec is for RS485 drivers where the data sheet says the maximum design load is 54Ω (or 56Ω, I just forget which) which equates to 2 x 120Ω terminations plus 32 devices all in parallel on the same line. I feel it would not hurt to do something similar with I2C or is there too much difference with driver circuitry to make this feasible. Or maybe there is this information buried down in the deep dark mysterious world of individual device specs.
Would there be any possibility of some sort of tutorial or discussion to highlight any potential problems this could cause or to point out best practise and make this a stand alone subject to emphasise the importance of such practices. Similar to the tutorials currently published. I suggest stand alone so it does not get swamped by other subjects as I regard this sort of thing as very important when considering reliability and longevity.
Cheers Bob
And keep up the good work.
Hi Bob,
I stumbled across this forum post and did some digging to verify.
It will end up being around 10 minimum spec I2C devices (Minimum spec being 3mA, though this isn’t on many datasheets)
The Vishay VEML6030, has been listed as 3mA which is featured in PiicoDev, I’ve experimented with this to work at much higher clock speeds than normal though (Up to 400kHz, from default I2C 100kHz with a full PiicoDev bus (photo below))
With I2C at long wire runs, capacitance (and with strong sinking, inductance) will also become a problem. I recall Core doing some experimentation with all of the modules sometime before the Mux was released and each of the modules working (500mm cables between each).
For sure, personally I see it tying in with the Mux a lot as it will drastically increase the effect of many more modules being on the bus.
Great Video (as always) - Thank You…
Any idea how long before the PiicoDev MUX becomes available for sale?
A couple of answers:
The short answer (as usual) is “it depends.” It depends on the drive characteristics of the I2C Controller and Target, and the value of pullups chosen. PiicoDev uses 10k pullups on its devices so we expect to get around 8-12 devices on a bus before comms start to break down. For this reason we’re working on a bus isolator/booster which will be able to segment long busses into groups: once the chain becomes too long you can add a booster and reset the bus impedance.
Documentation about eg. max devices will be rolled up into the connection guide for this device.
“Soon” - we’re working on a few projects in parallel which are sliding the PiicoDev MUX a little. The Factory is often a very early glimpse at products in work which is great because we can be candid about what we’re working on, and tricky for excited makers that want to get their hands on fresh, cool gear 
Hi Michael.
Thanks for that.
Most seem to be 10k but on one occasion I measured 4k7. Don’t remember exactly when that was now. Easy enough to check, just measure the resistance between the data pins and vcc (or whatever). I think the 4k7 would be in the minority but it would not hurt to know to ward off any future problems with multi connections.
That would be fair enough. One thing to keep in mind though I think I saw on some data sheet where these controllers (Arduino I think it was) have a maximum current of XmA per I/O BUT a total load of YmA for the whole device which is far lower than XmA multiplied by the number of I/O. This means in effect you can draw XmA from some of the I/O but NOT all of them at the same time. I wonder how many people overlook that little gem.
Great idea. Pretty easy for the clock line but a bit tricky for the data line but I think there are probably devices to do this, After all RS485 will operate half duplex which TX and RX on same line just not both at once which I think is similar to I2C. You don’t want too many anyway in case the time it takes to recover data from each one could get embarrassing if time is critical.
Good work anyway
Cheers Bob
@Robert93820 I should have been more explicit - the device modules use 10k pullups. The adapters for the dev boards eg. PiicoDev Expansion Board for Pico all have 4k7 on board. The intent here is that the bus starts off with an overall pretty low impedance to accommodate long bus lengths. Each additional device is only 10k so that the impedance doesn’t drop as rapidly with every new device added.
some very early PiicoDev module designs used 4k7 pullups but we phased those designs out in favour of 10k.
Hi Michael
Thanks, that clears that up. That might have been where I came across the 4k7.
Cheers Bob
OK so the elephant in the room is we still haven’t released this project as an official product…
Rest assured it’s still on my to-do list, 2023 has just been filled with many projects that have had greater urgency than this one. I still think the PiicoDev MUX is an awesome project that I think will help that 1-in-100 advanced PiicoDev (or other I2C) project, and so;
If you’re absolutely jonesing to use a MUX in a PiicoDev project I have some good news - I’m making the unfinished PiicoDev MUX MicroPython Module available for preview. The feature set is complete-enough for most makers, and there are some salient examples that ought to get you started. In short - any user that is familiar enough with PiicoDev and isn’t scared off by the idea of test-driving an unreleased, undocumented (but super-good-enough) driver will likely know what to do with this information.
The PiicoDev MUX design uses a PCA9546 IC which is the same IC found in a similar offerings. In fact, I’ve tested it with ADA5664 and am pleased to say it works!
Other muxes with more channels in the PCA95xx family might work with the existing driver, since they use a similar register structure - you will just be able to select eg. from a larger pool of buses eg. 8 instead of 4
If anybody tries the driver and would like to document their findings please do! No guarantee of fitness or function is expressed or implied.
And you can get our latest projects and tips straight away by following us on:
