I2C 4 Channel Mux TCA9545A Breakout Board ($11.95)

[include-page id=”buy-include-file”]

The I2C 4 Channel Mux Breakout Board is a TCA9545A based quad bidirectional translating

4 Channel I2C Mux Breakout Board
4 Channel I2C Mux Breakout Board

switch controlled via the I2C bus.  The SCL/SDA controlling fans out to four downstream channels.  It works for both the Arduino and Raspberry Pi.

At SwitchDoc Labs, we love data. And we love I2C devices. We like to gather the data using lots of I2C devices on our computers and projects. Project Curacao has a total of 12, WeatherPi has 11 devices and SunRover will have over 20 and will require one I2C bus just for controlling the motors. We are always running into conflicts with addressing on the I2C device. Since there are no standards, sometimes multiple devices will have the same address, such as 0x70 and you are just out of luck in running both of them on the same I2C bus without a lot of jimmy rigging.

What is the solution for this? It’s an I2C controlled 4 I2C bus multiplexer!

And we have the software drivers written for it for the Arduino and the Raspberry Pi on

I2C 4 Channel Mux in WeatherPi
I2C 4 Channel Mux in WeatherPi

github.com/switchdoclabs. With the software and board, you are ready to go!

Specification

The full specification for the I2C 4 Channel Mux Breakout Board is available here.

 

The TCA9545A is a quad bidirectional translating switch controlled via the I2C bus. The SCL/SDA controlling fans out to four downstream channels. Any individual channel or combination of channels can be selected via I2C. Four interrupt inputs (INT3–INT0), one for each of the downstream pairs, are provided. One interrupt (INT) output acts as an AND of the four interrupt inputs.  When you receive an interrupt, you read the interrupt register on the device to find out what channel interrupted you.

INA3221 Breakout Board Pinout
I2C 4 Channel Mux Breakout Board Pinout

An active-low reset (RESET) input allows the TCA9545A to recover from a situation in which one of the downstream I2C buses is stuck in a low state. Pulling RESETlow resets the I2C state machine and causes all the channels to be deselected, as does the internal power-on reset function.

The TCA9545A allows the use of different bus voltages on each pair, so that 1.8-V, 2.5-V, or 3.3-V parts can communicate with 5-V parts, without any additional protection. External pull-up resistors pull the bus up to the desired voltage level for each channel. All I/O terminals are 5.5 V tolerant!

How to Use

The I2C Mux Breakout Board is a quad bidirectional translating switch controlled via the I2C bus. The SCL/SDA controlling fans out to four downstream channels.

To use the I2C Mux Breakout Board, you connect the I2C bus up to an Arduino or Raspberry Pi and then connect the additional I2C busses as shown below.   The main I2C bus can be 3.3V or 5.0V as well as each of the multiplexed bus can be individually selected as 3.3V or 5.0V I2C busses.   There are three things to note when you wire up your I2C Mux Breakout Board.

  • If you are not driving your  RESET line with a GPIO pin, you must connect it to VCC.  Otherwise, the board will not respond.
  • Each of the four multiplexed I2C busses must be connected to either 3.3V or 5.0V.  Each multiplexed bus is individually powered.
  • Unlike other SwitchDoc Labs Breakout Boards, there is a  10K Ohm Pullup on the main I2C lines to VCC and 10K Pullups on each of the Multiplexed I2C busses to their respective power supplies.
Application Block Diagram
Application Block Diagram

Software

SwitchDoc Labs developed this pure Python TCA9545A I2CMux Raspberry Pi library and the Arduino Library and have posted them on the SwitchDoc Labs Respository on github.com

The Raspberry Pi Pure Python software is here:  https://github.com/switchdoclabs/SDL_Pi_TCA9545

The Arduino Software is here:  https://github.com/switchdoclabs/SDL_Arduino_TCA9545A

Using the Arduino libraries and the test software show the following result.  The test setup is to connect an additional I2C device to Bus 0 – in this case a SwitchDoc Labs INA3221 Breakout Board at address 0x40 on Bus0.

-----------------------------
------------------------------
SDA_Arduino_TCA9545_Test
Reading all four I2C Buses
------------------------------
------------------------------

------------------------------
------------------------------
Bus 0 Control Register:1
Scanning...
I2C device found at address 0x40  !
I2C device found at address 0x73  !
done

------------------------------
Bus 1 Control Register:2
Scanning...
I2C device found at address 0x73  !
done

------------------------------
Bus 2 Control Register:4
Scanning...
I2C device found at address 0x73  !
done

------------------------------
Bus 3 Control Register:8
Scanning...
I2C device found at address 0x73  !
done

 

Repeat the above test connecting the I2C Device to Bus1, Bus2 and Bus3

The I2C device (the INA3221 in this case) will move from bus to bus.

7 Comments

  1. This should be an easy question to answer. Purchased this so I can hook up the am2315 sensor. I see SDA, SCL and ground. Is it safe to assume that the positive lead goes to what appears to be pin vou3? What’s the best way to attach a sensor lead that is a bare wire to a male pin? thx, sam

    • Hi Sam,

      Sound like you are making great progress. The positive lead does go to VOU3. You are correct. Remember that you do need to provide power to the vou3 line. Check out the specification for details.

      SDL

  2. Thx, in general I think I know generally the purpose of the VCC bus: There’s only one 3.3 + pin on the Pi and that must “fan out” to be available to all the things that need that power.

    I’m going by the table in the Instructable for generally how that should wire out.

    If we do this for 3.3v+, why do we not do this for GND? The wiring for GND from the PI goes to the JP1 of the MUX. And it seems the 3.3v+ goes to its pin on JP1 of the MUX as well. This calls into question my assumption above for one source for all the 3.3v+ power. I’m having trouble getting my head wrapped around how to reconcile
    FROM PiA+ GPIO/Pin 1: 3.3V TO I2CM JP1/Pin 4:VCC
    and how the VCC will go to each sensor when the VCC from the Pi is going to only JP1 of the MUX?

    2) From the instructible this is throwing me: FROM WPA JP4/Pin 1: SCL TO WPA JP4/Pin 1: SCL. And its counterpart. Going to itself? The context is SCL from I2C Mux Board. Is this a goof in the instructible or something I’m overlooking?

    3) Pls confirm that FROM I2CM JP1/Pin 5: RESET TO VCC Screw Connector is correct. Am I correct that if this reset pin goes to GND it will reset. And since I believe I don’t want it to reset it should instead get VCC?

    thx for your attention to this, sam

    • Hi Sam,

      Some answers:

      1) You need to have a common GND. All the Grounds need to be connected together.

      FROM PiA+ GPIO/Pin 1: 3.3V TO I2CM JP1/Pin 4:VCC
      This takes power (3.3V) to the I2CM board. Then you jumper the VCC to the individual power VCX for each of the I2C busses which then power the sensors.

      2) Woohoo now that is a typo. The comment is correct, but the second board type is not correct. We will correct that in the instructable. It should read:
      WPA JP4/Pin 1: SCL I2CM JP4/Pin 1: SCL SCL from I2C Mux Board

      WPA JP4/Pin 2: SDA I2CM JP4/Pin 2: SDA SDA from I2C Mux Board

      3) The I2C Mux device resets on power up. You tie the Reset to VCC to make sure it doesn’t reset itself (which can happen if it is floating with enough noise).

      SDL

  3. You’ve lost me on this in context of 3.3v jumper/bus and Ground jumper/bus on the i2c MUX board:

    “Remember that you do need to provide power to the vou3 line. Check out the specification for details.”

    Using the instructable wiring, the 3.3v and ground, SCL, SDA wires for JP1 of the i2c MUX to the Pi. And I’ve made a provisional 3.3 bus/screw from the Pi’s GPIO 17 (actual 11) and a Ground bus/screw from the Pi’s actual pin 17. Right now they’re dangling because each of the temperature sensor are not wired to JP5 of the i2c MUX. The MUX is getting power from the Pi.

    Are extra devices getting their power/Ground from the Pi feeding the i2c MUX’s JP1? If so, where does the VCC bus/screws come into play here? I’ve read the specs for the sensor and I’ve got it wired up. Just don’t know how the VCC/screws are being used yet. thx, sam

    • Sam,

      I’m confused. What is dangling?

      By and large, sensors get their power from the I2C bus. But for the JP1 to feed other 3.3V I2C buses on the I2C Mux you need to connect the VouX lines. On JP6, you have the power line for each of the I2C buses broken out. You can connect the VDUx on JP6 to power any of the I2C Buses.

      SDL

  4. What’s dangling is the screw/bus for 3.3v/Ground only attached to the Pi’s spare 3.3v/Ground. There are four leads from the AM2315 including VCC and Ground. They are now attached to JP5 of the MUX. At this point nothing is getting power/Ground from this new bus. I’m glad that powering the JP1’s VCC and Ground may be sufficient to power this sensor is what I’m hearing from you. If it is already attached to the power pins for each jumper set then what would this new screw/bus for power be used for since the MUX has its own set of VouX and GND pins? It seemed that I had to use both VouX and the screw/bus 3.3 and that’s confusing.

    Thanks for helping me get my mind right on how the VCC screws/bus and the MUX board relate to each other, sam

7 Trackbacks / Pingbacks

  1. I2C 4 Channel Mux TCA9545A Python Drivers Released for Raspberry Pi - SwitchDoc Labs
  2. WeatherPi Solar Powered Weather Station Deployed Outside - SwitchDoc Labs
  3. WeatherPi Outside- 7 Days in the Sun - SwitchDoc Labs
  4. Create Your Own Solar Powered Raspberry Pi Weather Station | Fluharty Industries R&D
  5. SwitchDoc Labs Makes the Cover of Raspberry Pi Geek Magazine - SwitchDoc Labs
  6. Flame On! SunRover Solar Powered Robot Raspberry Pi / Arduino Power Up - SwitchDoc Labs
  7. Three Covers for SwitchDoc Labs on Raspberry Pi Geek Magazine - SwitchDoc Labs

Leave a Reply

Your email address will not be published.


*