How to set address when connecting two sensors to I2C.

[waiwaifiona]

Hey Guys,
I am a new users to this Raspberry Pi.

Right now I want to connect two same sensors (MPU6050) to the Pi. After searching some posts, I realize this is possible by connecting them in parallel.
The problem is when I try to access the address, it seems like the pi only detect one address which is 0x68 by the way.
What should I do next? Am I connecting it wrong or should I set the address deliberately myself and how exactly?

Much gratitude will be given if you guys could help me.

[joan]

The modules will need unique addresses. The documentation for the module you bought will tell you if the module can be configured for unique addresses or not.

[scotty101]

Doesn't look like the MPU-6050 supports changing it's address.

There are two usual ways that people support changing the address
1. A set of external pins to change a few bits of the address
2. Write a new address to memory

MPU-6050 has neither of these.

You could connect a second one via SPI.

[6by9]

Or use an I2C multiplexer to add additional I2C buses at the expense of dropping max throughput on them.
https://learn.adafruit.com/adafruit-tca ... t/overview

(Has anyone played with the kernel support for I2C muxes? It would seem a useful thing to have as a dt overlay option if anyone can get it running. Adafruit's controlling the mux from userspace is functional but pushes extra responsibility onto the client)

[waiwaifiona]

Doesn't look like the MPU-6050 supports changing it's address.

There are two usual ways that people support changing the address
1. A set of external pins to change a few bits of the address
2. Write a new address to memory

MPU-6050 has neither of these.

You could connect a second one via SPI.

Thanks for your help.
It seems like a dead end to me now though since I was planning on connecting 8 more MPU6050 to this pi.
I came across this website that is a tutorial about how to change I2C address: http://www.mindsensors.com/content/54-h ... spberry-pi

Could you take a look and see if it is possible for me to use this too?

[scotty101]

This only works for the sensors that are on that website. Neither the ability to change an I2C address nor the method to do so is universal.

Why do you need 8 inertial sensors?

[Massi]

Or use an I2C multiplexer to add additional I2C buses at the expense of dropping max throughput on them.
https://learn.adafruit.com/adafruit-tca ... t/overview

(Has anyone played with the kernel support for I2C muxes? It would seem a useful thing to have as a dt overlay option if anyone can get it running. Adafruit's controlling the mux from userspace is functional but pushes extra responsibility onto the client)

wow this thing is dreadfully nice!
another pro: you can have some "i2c buses" pulled up to 5V and some other to 3,3V
only bad: you have to add pullups

sadly i can't find that board out of adafruit

why do you say that you are dropping the throughput?
for sure you have to add the "change channel" timing, but once the channel is selected isn't it transparent to the pi?

[6by9]

wow this thing is dreadfully nice!
another pro: you can have some "i2c buses" pulled up to 5V and some other to 3,3V
only bad: you have to add pullups

sadly i can't find that board out of adafruit

Pimoroni have 19 at the moment - https://shop.pimoroni.com/products/tca9 ... ultiplexer (I better go and buy a couple having just posted that!)
Adafruit product page - https://www.adafruit.com/products/2717

why do you say that you are dropping the throughput?
for sure you have to add the "change channel" timing, but once the channel is selected isn't it transparent to the pi?

You have one physical I2C bus running at X speed (100kHz by default).
If no mux then you can talk to the devices on the bus at that rate.
With the mux, you can talk to the combination of all devices off the mux at that rate, even though if driven by the kernel they show up as independent I2C buses.
If you had two genuinely independent I2C buses, then you can push X speed down each of them (assuming you code is suitably multi-threaded). That's why I said the throughput is reduced.

[Massi]

Pimoroni have 19 at the moment - https://shop.pimoroni.com/products/tca9 ... ultiplexer (I better go and buy a couple having just posted that!)
Adafruit product page - https://www.adafruit.com/products/2717

i don't live in a country lucky enough to receive goods from pimoroni

You have one physical I2C bus running at X speed (100kHz by default).
If no mux then you can talk to the devices on the bus at that rate.
With the mux, you can talk to the combination of all devices off the mux at that rate, even though if driven by the kernel they show up as independent I2C buses.
If you had two genuinely independent I2C buses, then you can push X speed down each of them (assuming you code is suitably multi-threaded). That's why I said the throughput is reduced.

Full agree on this, ok
and yes, it would be very very nice to be able to use channels as "i2c-2, 3, 4" and so on..

[6by9]

Pimoroni have 19 at the moment - https://shop.pimoroni.com/products/tca9 ... ultiplexer (I better go and buy a couple having just posted that!)
Adafruit product page - https://www.adafruit.com/products/2717

i don't live in a country lucky enough to receive goods from pimoroni

They seem to list Italy, but only via UPS and not standard delivery - https://shop.pimoroni.com/pages/shipping-information
Farnell seem to have the bare chip if you're up for a bit of soldering - http://uk.farnell.com/texas-instruments ... dp/2496587

Full agree on this, ok
and yes, it would be very very nice to be able to use channels as "i2c-2, 3, 4" and so on..

2 on order, so I'll have a play when they arrive. The setup is all documented under https://www.kernel.org/doc/Documentatio ... ca954x.txt, so as long as the right kernel modules are being built it should all just fall into place. (That was easy to write, but I know it won't be that easy to get working!)

[Massi]

Farnell seem to have the bare chip if you're up for a bit of soldering - http://uk.farnell.com/texas-instruments ... dp/2496587

this chip seems not to be available in DIP package as well.. not so easy to use it without a pre assembled board

The setup is all documented under https://www.kernel.org/doc/Documentatio ... ca954x.txt, so as long as the right kernel modules are being built it should all just fall into place. (That was easy to write, but I know it won't be that easy to get working!)

wonderful. please let us know if it all work, i'll look for the board in the meantime

[6by9]

Farnell seem to have the bare chip if you're up for a bit of soldering - http://uk.farnell.com/texas-instruments ... dp/2496587

this chip seems not to be available in DIP package as well.. not so easy to use it without a pre assembled board

http://www.ebay.com/itm/5pcs-SOP-SSOP-T ... 1216713832 ?

[rpdom]

http://www.ebay.com/itm/5pcs-SOP-SSOP-T ... 1216713832 ?

What a coincidence. I was just looking at those for something else

[Massi]

definitely i'm not good enough to solder one of these

[6by9]

definitely i'm not good enough to solder one of these

You'd be surprised. Tin the pads first, position the IC, reheat a couple of corners, reflow all the other pins, then solder suck or solder wick up any excess solder. Suckers/wick never remove all the solder, and what is left is good enough normally to make a decent joint. Just make sure you don't overheat the device too badly.
Admittedly it's easier to try and get someone to ship one to you ready made

[Massi]

i want to clarify that i'm not good enough to solder the 1.27mm side of the board
the 0.65mm side must be a joke

(i should buy a tinier head for my soldering machine just to try one of these..)

[rpdom]

i want to clarify that i'm not good enough to solder the 1.27mm side of the board
the 0.65mm side must be a joke

(i should buy a tinier head for my soldering machine just to try one of these..)

I can just about manage the 1.27mm pitch stuff. I'd need a microscope and much steady hands to do the 0.65mm pitch.

I've just soldered a 1.27mm pitch RGB LED onto ordinary 2.54mm stripboard by cutting along the length of one of the strips to double the pitch

That's what I was looking at getting the adaptor boards for.

[Massi]

2 on order, so I'll have a play when they arrive. The setup is all documented under https://www.kernel.org/doc/Documentatio ... ca954x.txt, so as long as the right kernel modules are being built it should all just fall into place. (That was easy to write, but I know it won't be that easy to get working!)

i have to admit that more than the PCA9548A board, i'd like to put my hands on a couple of PCA9544A boards (since i have 2 separate places where i'd need to split i2c channels
this seems to be even harder to find..
btw, do you think the "dt approach" will allow to manage at kernel's level multiple multiplexer? (i'm not thinking to nest them )

Edit to add:
lol i found out that there's a full family of chips..
http://www.nxp.com/documents/application_note/AN262.pdf
and i also discovered "switches" more than "multiplexers"

if i got it right, with a SWITCH i can do all what i do with a multiplexer, but i can do even more because i can have multiple "downstreams" selected together (this would allow to have a piece of bus at 5V and a piece of the same bus at 3,3v i.e.

nice! and the PCA9546A is also in SO format
ok i want a couple of these

[6by9]

i have to admit that more than the PCA9548A board, i'd like to put my hands on a couple of PCA9544A boards (since i have 2 separate places where i'd need to split i2c channels
this seems to be even harder to find..

If you look at the driver source, it claims support for:

* This module supports the PCA954x series of I2C multiplexer/switch chips
* made by Philips Semiconductors.
* This includes the:
* PCA9540, PCA9542, PCA9543, PCA9544, PCA9545, PCA9546, PCA9547
* and PCA9548.

so PCA9544 should work. If there isn't significant impact on board space or price, then take the hit with PCA9548A as at least it is then easy to prototype.

btw, do you think the "dt approach" will allow to manage at kernel's level multiple multiplexer? (i'm not thinking to nest them )

In theory, yes. You should be able to create almost any form of tree architecture you fancy with muxes PROVIDED you can access each of the control nodes uniquely. PCA954x devices all have an I2C address of their own, so that has to be uniquely accessible and not collide with your actual I2C device addresses.
Don't ask me to code it into DT, but the following should be possible

Code: Select all

                                            C0 -> 
                                            C1 -> 
                                            C2 -> 
                                            C3 -> 
                        A0 -> PCA9548 (0x77)C4 ->    (0x71, 0x72, and 0x77 not available on these ports)
                                            C5 ->
                                            C6 -> 
                                            C7 -> 
			
                        A1 -> 	(0x71 and 0x72 not available on these ports)
                        A2 -> 
                        A3 -> 
i2c-1 +> PCA9548 (0x71) A4 ->
      |                 A5 -> 
      |                 A6 -> 
      |                 A7 -> 
      |
      |                 B0 -> 	(0x71 and 0x72 not available on these ports)
      |                 B1 ->
      |                 B2 ->
      |> PCA9548 (0x72) B3 ->
      |                 B4 ->
      |                 B5 ->
      |                 B6 ->
      |                 B7 ->
      +-> Random other devices, but not 0x71 or 0x72.

So you've now got 25 I2C ports available, but addresses 0x71, and 0x72 are not available on any port for your devices, and 0x77 is also used for 9 of the ports (A0 and C0-C7). You could also cascade another PCA9548A onto (eg) A7, also using address 0x77, as A0 and A7 won't both be active at once. How far do you want to push it?!

Don't expect to do that lot via a simple overlay though - it's beyond the complexity level that overlays are aimed at (all node details are effectively hard coded).
NB There is kernel support for GPIO controlled I2C muxes too, so you can change your choice of chip and regain the use of those addresses at the expense of some dedicated GPIO.

If you really want to explore this lot, then do read the kernel docs on it. I've just seen there's even a pinmux based control driver (docs at http://lxr.free-electrons.com/source/Do ... inctrl.txt), so on a Compute Module you can have the kernel automatically switch i2c1 between pins 2&3 and 44&45 as two apparently independent i2c buses. The GPU already does a similar thing with i2c0 to switch between multiple cameras on the Compute Module.

[Massi]

Don't expect to do that lot via a simple overlay though - it's beyond the complexity level that overlays are aimed at (all node details are effectively hard coded).
NB There is kernel support for GPIO controlled I2C muxes too, so you can change your choice of chip and regain the use of those addresses at the expense of some dedicated GPIO.

Your schema was exactly the worst case i was thinking to evry deeper step adds a further i2c call to open the channel. It is for sure usable _coding_ it, probably - as you say - not through a DT overlay.
Very interesting
thanks a lot

[6by9]

Your schema was exactly the worst case i was thinking to evry deeper step adds a further i2c call to open the channel. It is for sure usable _coding_ it, probably - as you say - not through a DT overlay.

Potentially adds an extra call for setup. It does remember the last setting for each mux, so the one byte write (2 byte transaction including address) is only required when things change. Poll in the "right" order and it should be a small overhead.

(Apologies to the OP for this thread going a little off into details, but it would solve your problem).

[Massi]

Your schema was exactly the worst case i was thinking to evry deeper step adds a further i2c call to open the channel. It is for sure usable _coding_ it, probably - as you say - not through a DT overlay.

Potentially adds an extra call for setup. It does remember the last setting for each mux, so the one byte write (2 byte transaction including address) is only required when things change. Poll in the "right" order and it should be a small overhead.

do you think the kernel is going to manage this?
and i was thinking to another matter: with standard channel every i2c call is "preserved", so that it is not possible to break a i2c call doing another call in the meantime
with mux/switch every "device" call is indeed a couple of calls (select channel on the mux + call to the device)
probably managing "in software" the mux would expose to the unlucky case of overlapping i2c calls between different scritps.
it would be nice to know if the "dt approach" would manage this

(Apologies to the OP for this thread going a little off into details, but it would solve your problem).

probably "i2c multiplexer / switch" deserve a topic itself

[6by9]

do you think the kernel is going to manage this?
and i was thinking to another matter: with standard channel every i2c call is "preserved", so that it is not possible to break a i2c call doing another call in the meantime
with mux/switch every "device" call is indeed a couple of calls (select channel on the mux + call to the device)
probably managing "in software" the mux would expose to the unlucky case of overlapping i2c calls between different scritps.
it would be nice to know if the "dt approach" would manage this

This is where using the kernel wins over Adafruit's solution. The kernel will deal with making operations atomic, as long as you call it appropriately. In particular that means using the I2C_RDWR ioctl if you want to doing a combined "write register address, read register value" transaction. Independent write and read calls will not have any guarantees.

(Apologies to the OP for this thread going a little off into details, but it would solve your problem).

probably "i2c multiplexer / switch" deserve a topic itself

Probably. Oh well. Can do that if/when I get it working

[Massi]

it seems that no breakout exists with a PCA9546 chip
and for the rest the adafruit's one seems far better than all of the other existing boards
i fear i'll have to take a couple of those

[6by9]

I'll create a new thread, but I2C mux support for the PCA9548 just works with the relevant options. I've created a dt overlay to set it up so it's simple for those wanting to use a single one.

Code: Select all

pi@raspberrypi:~ $ 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