#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.

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.

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!