I2C mulitplexer support

[6by9]

EDIT 26/5/2016
Everything is now merged into the normal Pi kernel. None of the interim files referenced in the discussion are now needed.

EDIT 11/5/2016
As other i2c muxes have been added to the 4.4 kernel, one generic overlay has been created rather than specific ones for individual chips.

The overlay command is now:

Code: Select all

dtoverlay=i2c-mux,pca9548,addr=0x70

(addr defaults to 0x70 so can be omitted if using that address).

Support is now present for pca9542 (2 channel), pca9545 (4 channel), and pca9548 (8 channel) muxes.

Original post left below for reference.
---------------

Following on from discussions on viewtopic.php?f=44&t=140054 I've had a play with the kernel support for I2C multiplexers, mainly the NXP PCA9548A. People such as Adafruit sell it neatly mounted up. It turns out it works surprisingly well.

I've just created a pull request for support to be merged into the main kernel, and it includes a device tree overlay to load it easily.

Add

Code: Select all

dtoverlay=i2c-mux-pca9548a

to /boot/config.txt. Connect up your PCA9548A to i2c-1 (pins 3&5, GPIOs 2&3 for SDA and SCL respectively) and power. Load i2c-dev eiher via your preferred method, and you should find that you will be able to do:

Code: Select all

[email protected]:/ $ ls /dev/i2c*
/dev/i2c-1  /dev/i2c-10  /dev/i2c-3  /dev/i2c-4  /dev/i2c-5  /dev/i2c-6  /dev/i2c-7  /dev/i2c-8  /dev/i2c-9

The overlay uses address 0x70 by default, but you can add ",addr=0x71" or similar to the end of the dtoverlay line if you want to use another address.

Another useful feature is that the muxed ports are all 5V tolerant, so it will also act as an I2C level shifter into the bargain.

If you're wanting to try it out before it hits the main tree then I've pushed the modules to https://github.com/6by9/RPiTest/tree/master/i2c-mux. The commit text tells you where to copy files to. Please note that those files are for 4.4.6, so you'll need to have done a "sudo BRANCH=next rpi-update" for them to be appropriate. I rpi-update'd early this evening, so it should work against 7e9f1ca7629d765111bd7b0c31ebdc056ef17656.

I hope it's of use to some people who are trying to use multiple identical devices, and it's much easier than making userspace take control of the mux.

[mikronauts]

Very nice!

[adun]

Is there any advantage in using this I2C multiplexer over a simpler I2C HUB PCA9518A that I was planning to use ?

[6by9]

Is there any advantage in using this I2C multiplexer over a simpler I2C HUB PCA9518A that I was planning to use ?

That depends on what you're trying to achieve.

If you're only after level shifting and overcoming the capacitance limit of the bus and not controlling the enable lines on the PCA9518, then there's little point in using PCA9548 instead.

If you need to control the ports due to multiple devices on the same I2C address or similar, then 9518 uses GPIOs instead of I2C commands but would achieve the same result (4 outputs instead of 8).
There is a kernel driver (i2c-mux-gpio) that would drive the enable lines on PCA9518A to do the same thing of automatically presenting the different outputs as different /dev/i2c nodes, but I haven't asked for that to be built in the kernel or written an overlay for it (it should be trivial to do though, but might need some rejigging to get the correct GPIO setup).

Have a read of the kernel docs around I2C muxes at https://www.kernel.org/doc/Documentatio ... x-gpio.txt, and wiki at https://i2c.wiki.kernel.org/index.php/I ... ltiplexing to understand what the kernel is up to with the i2c-mux support.
My investigations started because of a thread asking how to add 2 identical non-addressable I2C devices to a Pi, at which point you need some form of switching. I hadn't found an easy supplier of devices other than PCA9548, hence going for that as the solution.

[adun]

Thanks for the explanation .
Basically I was only after level shifting and intended to have the EN lines unconnected.
However if needed, the port control by I2C commands is a much better approach as the GPIO solution needs additional config/wiring and is not easy portable.

[brekee12]

I like your idea of I2C bus switch and driver program. I have been designing a B+, 2B standard panel with 8 connector and 4 bus driver. Questions:
- I buy 1.48USD PCA9548AD switches in SO package, is there anyone interested on part of the shippment?
- 6by9 would you check the design fullfills the driver requirements

If the PCB ready it is available on self-producement cost.https://goo.gl/photos/3t8Yrxp2WREdDuiv9

[brekee12]

Does it make sense to configure the port to the system I2C(0) port? This port could be used as normal system port at startup, but with the switch it could be add more functionality. The only question in my mind is which address to configure the switch not to disturb the system?

[adun]

Interesting idea. If I understand you correctly you want to connect the mux to the i2c0 port to add multiple i2c hosts along with the native i2c1. Currently on RPi3 i2c0 is not accessible by the ARM and reserved by the GPU for cam/disp, port expander and smps control. For the mux the firmware would need to support it. Another possiblity would be through a virtual i2c0 port (on GPIO 0,1) which I hope will soon be available for HAT programming.

[6by9]

I'm only enabling support written by others in the upstream kernel, mainly due to Pi3 using i2c0 for other purposes (as arun says).

Sorry, I'm not going to check your schematic. There's nothing complex to the driver, just make sure you don't swap SDA and SCL.
Personally I don't see much gain in having it as a plugin card over buying the Adafruit board - you're going to be wiring up extra boards to the i2c outputs, so one extra isn't a big deal. You've also lost the gain of being able to set your own pullup resistors for other I2C bus voltages.

As to enabling it on i2c0, that's not going to work. i2c0 is used by the GPU firmware for the camera, display and touchscreen, HATs, and GPIO expander, so that's not solely at startup.
The bigger issue is that there is no arbitration between the GPU and ARM on accessing the peripheral within the SoC. Without that there isn't a safe way to use the peripheral from both, and now you're wanting both firmware and ARM to know how to control a 3rd party mux too - not going to happen. The firmware already partially does that anyway by altering the pin muxing on the SoC to move the bus between pins, but there's no integration into the ARM. Sorry, it's not one I'll be investigating further - i2c1 or nothing.

[adun]

Correct me if I'm wrong
The firmware does pin muxing beetween
GPIO 0,1 HAT
GPIO 44,45 Cam, Display
GPIO 46,47 Port Expander, SMPS

I think the idea of OP was to connect the mux to one of those pins (GPIO 0,1 on RPi3 as they are the only ones direct accessible).
Then the firmware could treat the mux like the port expander (as i2c device).
And offer several virtual i2c ports to the arm like it does with the port expander and virtual GPIO

[6by9]

Correct me if I'm wrong
The firmware does pin muxing beetween
GPIO 0,1 HAT
GPIO 44,45 Cam, Display
GPIO 46,47 Port Expander, SMPS

For a Pi3 those are the correct numbers. For other models the camera and display are typically on 28&29, but that's details.

I think the idea of OP was to connect the mux to one of those pins (GPIO 0,1 on RPi3 as they are the only ones direct accessible).
Then the firmware could treat the mux like the port expander (as i2c device).
And offer several virtual i2c ports to the arm like it does with the port expander and virtual GPIO

So currently on a Pi3 you can't safely use I2C0 at all - show stopper.

If a virtual I2C driver is written, then that would pinmux to GPIOs 0&1 when the ARM/Linux wants to write to them, and elsewhere when the GPU wants to communicate to other places. That's the level of muxing that the GPU cares about (and can actually be replicated with the kernel pinctrl mux driver).
There's nothing stopping you then adding the same i2c-mux driver onto that virtual bus within Linux to provide additional busses without the GPU getting involved in driving the mux at all. It would remove the dependency on the GPU having to worry about a mux that may or may not be present but provides the same functionality. The only downside is that the main i2c0 interface will see the HAT EEPROM, but there's not much you can do to avoid that when that is the primary use for those GPIOs.

First thing to get sorted is safe access to i2c0 from the ARM - Pi Towers are on the case based on viewtopic.php?f=29&t=108134#p933119

[adun]

That's exactly what I was thinking of, thanks for explanation !

The only downside is that the main i2c0 interface will see the HAT EEPROM, but there's not much you can do to avoid that when that is the primary use for those GPIOs.

This should not be a big problem as other devices will then be attached to the mux.

Will try to test this when safe access to i2c0 is sorted out.

[6by9]

Will try to test this when safe access to i2c0 is sorted out.

It should work fine on a Pi1 or 2 if you add dtparam=i2c_vc=on to config.txt, just avoid having the display or camera attached/used at the same time.
It's only the PI3 that really has an issue due to the GPIO expander.
Take the existing i2c-mux-pca9548a-overlay.dts, and amend

Code: Select all

		target = <&i2c_arm>;

to

Code: Select all

		target = <&i2c_vc>;

Recompile, and it should be job done.
I might give it a quick whirl myself, but I'm not going to push it anywhere as use of i2c0 currently has too many pitfalls.

[6by9]

That works too:

Code: Select all

[    5.566150] i2c i2c-0: Added multiplexed i2c bus 3
[    5.566395] i2c i2c-0: Added multiplexed i2c bus 4
[    5.568410] i2c i2c-0: Added multiplexed i2c bus 5
[    5.568683] i2c i2c-0: Added multiplexed i2c bus 6
[    5.568891] i2c i2c-0: Added multiplexed i2c bus 7
[    5.569118] i2c i2c-0: Added multiplexed i2c bus 8
[    5.569322] i2c i2c-0: Added multiplexed i2c bus 9
[    5.569520] i2c i2c-0: Added multiplexed i2c bus 10
[    5.569540] pca954x 0-0070: registered 8 multiplexed busses for I2C switch pca9548
[    5.574295] i2c i2c-1: Added multiplexed i2c bus 11
[    5.577252] i2c i2c-1: Added multiplexed i2c bus 12
[    5.579775] i2c i2c-1: Added multiplexed i2c bus 13
[    5.580794] i2c i2c-1: Added multiplexed i2c bus 14
[    5.581077] i2c i2c-1: Added multiplexed i2c bus 15
[    5.581300] i2c i2c-1: Added multiplexed i2c bus 16
[    5.581504] i2c i2c-1: Added multiplexed i2c bus 17
[    5.581709] i2c i2c-1: Added multiplexed i2c bus 18
[    5.581730] pca954x 1-0071: registered 8 multiplexed busses for I2C switch pca9548

Code: Select all

[email protected]:~ $ ls /dev/i2c*
/dev/i2c-0  /dev/i2c-10  /dev/i2c-12  /dev/i2c-14  /dev/i2c-16  /dev/i2c-18  /dev/i2c-4  /dev/i2c-6  /dev/i2c-8
/dev/i2c-1  /dev/i2c-11  /dev/i2c-13  /dev/i2c-15  /dev/i2c-17  /dev/i2c-3   /dev/i2c-5  /dev/i2c-7  /dev/i2c-9

Now to think of enough devices to make that worth while!
It's quite convenient that the Adafruit board includes the pull ups for the main I2C bus as they aren't present on i2c0 (pins 27&28).

[brekee12]

I2C-0 can accomplish its own function, PCA does not disturb the communication with the camera or HAT only I must be sure the addresses does not hit eachother. If nothing on 0x70 to communicate basicly I2C-0 works as a standard bus, if 0x70 addressed there are 8 new busses opens. The panel got pullup resistor anyway independently I2C-0 or 1.

The panels everyone can solder ones own resistor values. But it got place of four bus amplifiers two for 5V and two for 3 V, this makes the possible connection length to 25m. additionally four connector has Amphenol type connector which is usual, but four connector is a pin type for testing purposes. I make it not for business, primary for myself, but of course if someone has interested it I can send the panel on its production cost and the mux can be bougth in bulk only in resonable price, so I would like to share it.

I think this multiplexer idea is great staff and I am very glad if someone writes a great code for that. Congratulations for the idea and good luck for writing the code.

[adun]

Nice to see it is working!
The adafruit board has 10k pull up resistors on the i2c lines. On GPIO 0,1 with the 3k9 from a attached HAT this will result in approximate 2k8 ohm what is lower than the recommended for the HAT EEPROM. On compute module the i2c0 line for CSI/DSI has 1k8 pull ups.
What would be a ideal value?

[brekee12]

10kOhm is proper value on local bus. The suggested value is 4k7 kOhm, parallels the two 10k on both side of the bus is OK.
P82B715 driver datasheet advice 4k7 it is a short distance to the driver/mux and it is not splitted to the two end. 470 Ohm on the driven side adviced using on the two ends. You can check the calculations according to this datasheet, where everything is explained.

Sorry I have just checked the resistance values and I can see the driven distance is not 25 only 20 meter, I could remember wrong.

[6by9]

If you really want to use i2c0 (and I'm advising against it for most things, at least until a sensible virtual driver is sorted), then you're creating a bus like:

Code: Select all

i2c0 ----------+----------+
(GPIO0&1)     HAT        Mux
             EEPROM   (0x70-77)
             (0x50)   | | | | | | | |

So address 0x50 and the mux address are not available on any of the virtual busses - there's no way around that one.
(The camera and display are on different GPIOs, so you already effectively have a mux there controlled by the GPU).

If you're getting a board made up, I'd suggest you copy Adafruit and allow the user to select the I2C address of the mux using the A0-A2 lines (see their schematic for more details). It just allows people to readdress it should they have another device at 0x70.
Perhaps think along similar lines with pads for selecting i2c0 vs i2c1. Default to i2c1, but cut two tracks and bridge two pads to switch i2c0 if you know what you're doing.

Pull up resistors - to be honest the exact value is not that critical. 10k will typically work as long as the line capacitance isn't too great. Go much below 1k and the open drain ends up having to carry a modest current when pulling the line low. Aim for something in between.

Bus drivers - P82B715 seem to have to be used as a pair, one at each end of the line. I've never really encountered using I2C for long lengths - it's designed for use within devices. Is the long drive length useful? Not to me, but maybe to others.

Summary - design the board for your purposes and feel free to ignore any of my waffling. I have no ideas if it will be useful to others.

[brekee12]

Thank you for the idea of jumperable address space and SCL SDA. I will take it into consideration.
Some people complaining they want long lines (10m) to their sensor. It would solved their needs. (Most cases temperature sensor outside.) As the board is not assembled or if someone ask me I partially assemble to decrease costs, it is not required to use driver, even the two connection point can be shorted and it is like nothing but not a driver there.

What I would like to ask you to see everything from the driver point of view. I am not a professional, especially not from software point of view. My original idea was not to check my schematic, but I would like to design something which works with your driver.

[adun]

I
So address 0x50 and the mux address are not available on any of the virtual busses - there's no way around that one.
(The camera and display are on different GPIOs, so you already effectively have a mux there controlled by the GPU).

I understand, that's because they are on the bus before the mux split it.
The I2C HUB PCA9518A has no i2c address so this would at least free up 0x70. But as mentioned this would need GPIO to control the EN lines.
I'm wondering if there exists something like a hub chip that offers (one/multiple) i2c ports that are completely free for any address.

Another idea I had in mind:

Code: Select all

i2c0 ----------+----------+
(GPIO0&1)     HAT        AVR ----------+    
             EEPROM   (0xXX)        i2c HUB
             (0x50)              | | | | | | | |

Use a microcontroller (AVR) with 2 i2c buses. One goes to the RPi and the other has the I2C HUB PCA9518A connected to it.
The EN lines are controlled via the AVR-GPIO. With a suitable code the Pi could talk over the AVR to the different i2c subsystems.
I know this is a bit of an overkill but it would allow to have the whole range of i2c addresses.
Or with a special chip that offers directly multiple i2c ports. But I was only able to find I2C hubs or multiplexers.

[6by9]

The I2C HUB PCA9518A has no i2c address so this would at least free up 0x70. But as mentioned this would need GPIO to control the EN lines.
I'm wondering if there exists something like a hub chip that offers (one/multiple) i2c ports that are completely free for any address.

You've just referenced it - PCA9518A. Connect that onto i2c1 and job done.
TBH The PCA9548 has got address select lines, so the chances of needing an architecture where none of those are available is vanishingly small.

Another idea I had in mind:

Code: Select all

i2c0 ----------+----------+
(GPIO0&1)     HAT        AVR ----------+    
             EEPROM   (0xXX)        i2c HUB
             (0x50)              | | | | | | | |

Use a microcontroller (AVR) with 2 i2c buses. One goes to the RPi and the other has the I2C HUB PCA9518A connected to it.
The EN lines are controlled via the AVR-GPIO. With a suitable code the Pi could talk over the AVR to the different i2c subsystems.
I know this is a bit of an overkill but it would allow to have the whole range of i2c addresses.
Or with a special chip that offers directly multiple i2c ports. But I was only able to find I2C hubs or multiplexers.

Major overkill. And you still can't isolate off the HAT EEPROM, nor have you specified a way to control the AVR other than via I2C. You'd also need to write a kernel driver to control the AVR.

This seems to be getting needlessly bogged down into trying to squeeze something out of i2c0 that isn't necessary. Just use i2c1, and either a PCA9548, or a PCA9518 with some GPIOs.

[6by9]

What I would like to ask you to see everything from the driver point of view. I am not a professional, especially not from software point of view. My original idea was not to check my schematic, but I would like to design something which works with your driver.

As long as you've connected SDA, SCL, 3.3V and ground correctly, the driver (not written by me, just configured by me) should find it and be able to work. If you're using i2c1 then pull up resistors are already taken care of. Anything on the other side of the PCA9548 is up to you.

[brekee12]

I redesigned the PCB. Now it is selectable with 0R to which I2C port it uses and the A0, A1, A2 also selectableb between VCC and GND.
On the PCB there are place for four driver, two for 3.3V and two for 5V; this ports has been connected by Amphenol usual connectors. There are four undriven port, two for 3.3V and two for 5V; this are connected with pin header.

[Massi]

Some people complaining they want long lines (10m) to their sensor. It would solved their needs. (Most cases temperature sensor outside.)

well, if this is the problem you can go with a "simple" i2c bus expander (no addresses used)
btw, my 2 multiplexers are coming

[Massi]

hello,
finally got my 2 expanders..
I was on the "actual" 4.1.19-v7+ #858 firmware.
added 2 lines to /boot/config.txt

Code: Select all

dtoverlay=i2c-mux-pca9548a
dtoverlay=i2c-mux-pca9548a,addr=0x74

and got nothing in /dev
checked for i2c-dev to be loaded, and it was.

So i went for a rpi-update and got a 4.1.21-v7+ #872
and still got nothing.

i just got this in logs

Code: Select all

001376.302: Failed to load overlay 'i2c-mux-pca9548a'
001394.692: Failed to load overlay 'i2c-mux-pca9548a'

so i tried looking for the overlay files and it seems to be present in both firmwares

Code: Select all

[email protected]:/dev $ sudo find / -name "*i2c-mux*"
/lib/modules/4.1.19-v7+/kernel/drivers/i2c/i2c-mux.ko
/lib/modules/4.1.21-v7+/kernel/drivers/i2c/i2c-mux.ko

that said, why isn't it working? is it available in my firmware or still not?

and, finally, i haven't understood if using the multiplexer on i2c-0 on a pi3 is safe or not (safe: does not kill any other function)

thanks