I2C Multiplexer Driver

Morten Nissov

Hi,

In connection with another post (link) we're trying to put together some custom drivers for sensors we'd like to use with the voxl2 mini. Previously we got a driver working for a hall-effect sensor we were interested in using, but in reality we want to use 4 of them.

All 4 have the same I2C address (which could be changed given more IO) so we're interfacing these using an I2C multiplexer. I wanted to try and reuse the previously mentioned single sensor driver, but it seems not so straightforward. For example, calling the module_start for the multiplexer driver will be a bit complicated if it in reality needs to also start the underlying hall-effect drivers. Also probing (function used by I2C class) the sensor drivers at the start is not so possible, given they will be "hidden" behind mux.

I was curious if you knew of any examples of something similar? Or any advice how to structure this. Hope it makes sense

Eric Katzfey

@Morten-Nissov I think you are charting some new ground here. You might have better luck posting on the PX4 forum. And also, you don't have to follow the same structure as other i2c drivers. You can just do something completely custom.

Vinny

HI @Morten-Nissov
We've done some internal projects using the TCA9548A 8-port I2C mux.

It's a very simple device that has only one config register, and the ability to configure it's device address to eight different values.
The mux also provides inherent voltage translation too, which is why I love it!
Check it out... https://www.ti.com/product/TCA9548A?

As far as supported SW for it, since it is just a 1-register device, it should not be hard to include a command to configure it how you need to support a polling structure, but we have no official support as Eric mentioned.

Hope this helps!

Morten Nissov

Thanks to both.

We actually have a mutliplexer (PCA9546) and 4 magnetometers working on a teensy. So all should be good, it's just about converting this to px4.

@Vinny This sounds interesting because it is essentially what we would like to do, the challenge for us is that we haven't found a way to send I2C messages to the multiplex address (0x70) as well as the sensor address (0x35) from a single px4 driver class. Did you manage to do something similar?

I've been trying to create a class for the multiplexer and have the magnetometer as a member variable but it doesn't seem like this will work particularly well given the standard boilerplate for px4 drivers. At least to me it looks that way. I assume it's the same for you, that the multiplex just needs a single byte sent to select which sensor is enabled, if you've found an easy way to send this byte from an I2C driver with a different address then I would be interested in hearing how to do that.

Edit: I mean this in particular for bus 1 on header J19. I believe this bus is on the DSP. I think this is relevant for how I do I2C at a low level right? E.g., on linux using ioctl and such to write a byte. I mention this because I tried to implement this with ioctl and the docker container returns

fatal error: 'linux/i2c.h' file not found
#include <linux/i2c.h>

so I figured this was maybe not 100% correct.

Morten Nissov

Edit 2: Tried creating a class for handling only the multiplexer:

#define NUMBER_OF_TMAG5273 1

class PCA9546 : public device::I2C
{
public:
  PCA9546(const I2CSPIDriverConfig& config)
    : I2C(DRV_MAG_DEVTYPE_PCA9546, "pca9546", config.bus, ADA_PCA9546::I2C_ADDRESS_DEFAULT, I2C_SPEED)
  {
  }

  bool select(uint8_t i)
  {
    if (i >= NUMBER_OF_TMAG5273)
    {
      PX4_ERR("select for index > NUMBER_OF_TMAG5273: %i", NUMBER_OF_TMAG5273);
      return false;
    }

    this->transfer(&i, 1, nullptr, 0);
    return true;
  }
private:
  int probe() override
  {
    return PX4_OK; // mux doesn't return anything
  }
};

I include this as a member variable in my main driver class which is meant to read from the hall-effect sensors through the mux. This is proving to be a bit difficult as the probe doesn't seem to succeed ever (same probe which worked with single sensor but now with a call to select(0) first to test.

Edit3: The mux driver can read a single sensor (sending the byte to mux address first followed by the standard read exchange) so it would seem that the difficult comes with the part interfacing the mux.

Eric Katzfey

@Morten-Nissov I would advise trying to get some support from the PX4 community. I'm not aware of any use of i2c multiplexers in any current PX4 drivers but I think it's a useful feature. But that is the best place to get advice on PX4 development.