Suppose that the processor runs at 3.3V and all the I2C devices are running at 3.3V and the TCA9548A does no level shifting, and the processor and I2C devices have no internal pullup, then every pullup resistor is connected to 3.3V, so even such a "bussed resistor array" can be used.
The TCA9548A is an I2C device, you do not need any additional pins from the arduino.
3 Likes
Yea.... got my wires crossed so to speak... I do realise that.
If you have the processor pins available, I think the 4051 is the better choice. The SCL line does not need to be multiplexed, so it could fan out to all the sensors, with a single pullup resistor somewhere. Then you would run the SDA line through the 4051. But you would need a pullup resistor on that line on each sensor. Possibly a resistor array would work.
If you needed to level shift, the multiplexer might be the better choice. But I assume everything here is 3.3V.
Everything is 3.3v. I have ordered some TCA9548A's anyway for a tinker and for stock.
But yes... probably going with 4051'S for footprint size and ease.
You just repeated what I said back in post #20
Sorry. I must have missed it.
Of course if the VEML6040 does clock stretching then it won't work.
Eh?... Well... only one way to find out
Combining the SCL signal and clock pulse stretching are not related.
[UPDATE]
DrDiettrich made me see that they can be related. Suppose one of the Slaves is an Arduino board or a smart sensor (with a processor inside) such as the BNO085 that can keep SCL low, and that Arduino board has very bad code or the sensor is faulty and the Arduino Wire library is not used and the MUX is switched during a I2C session, then the single SCL can be related to Clock Pulse Stretching.
But even with a normal single I2C bus, someone can cause the bus to be stuck, I wrote something about that on Github: How to unlock a stuck I2C bus · Koepel/How-to-use-the-Arduino-Wire-library Wiki · GitHub
What do you mean?
Let's call the I2C at the Master the "main" I2C bus and all the I2C buses after the multiplexer "sub" I2C buses.
Only SDA needs to be multiplexed. The SCL from the Master can go directly to all the Slaves. I call that combining all the SCL signals (of the "main" and all the "sub" I2C buses) into a single SCL signal.
That is not related to clock pulse stretching. One thing has no influence on the other thing.
Then every slave can block the SCL by clock stretching in unknown state entered from missing or floating SDA.
The SDA is never floating. The "main" and all the "sub" I2C buses should have pullup resistors for SDA or else it is not a I2C bus. A normal "dumb" sensor (without processor inside) has no hardware to pull the SCL low.
I assume that the MUX is not changed during a I2C session 
I doubt that a sensor without kind of embedded controller can implement the I2C protocol, in addition to the conversion from analog to digital values. Just such "dumb" sensors are known for spurious errors and locking up the I2C bus until reset.
Post #19 has the datasheet....
I think it's getting too involved now.
Buy some
Breadboard it
Try to break it
That's the plan
And that datasheet classifies SDA as input/output, but SCL as input only. Does that mean it can't stretch?
That is very nice of them to mention that.
I call that a "dumb" sensor. It can not pull SCL low, it can not do Clock Pulse Stretching.
But what has Clock Pulse Stretching to do with anything ?
I stepped out at this point... I think it's drifted away from my question
Thank you for all your advice chaps
OK all...
For various reasons of design, I am going to control the I2c switching with an ATtiny84.
Not actually used one before (only attiny85's), but my question is regarding timing.
I assume it has an 8Mhz internal crystal (I will check that). To drive a couple of NeoPixels, would I be better off with an external 16Mhz crystal? Or will it work just fine on the internal 8Mhz?
It can support 20Mhz. Any advantage to using that?
Newbies eh...