I have a situation where I need to daisy chain three different sensors on the same I2C channel. With the pattern in this codebase, the driver takes ownership of the I2C device not allowing it to be shared with other device drivers.
I would recommend adding in some way that the driver accepts does not always own the I2C and can be managed by a higher level interface. An example would be to move the i2c device in the struct to be an Option<I2C> and then put in a take_i2c(&mut self) and a set_i2c(&mut self, i2c: I2C) style methods.
An alternative I have seen with other drivers, is to just pass the I2C device to each call. Sounds cumbersome, but might be proffered based on the time it takes to do the extra function calls and cross-checks postulated above.
I have a situation where I need to daisy chain three different sensors on the same I2C channel. With the pattern in this codebase, the driver takes ownership of the I2C device not allowing it to be shared with other device drivers.
I would recommend adding in some way that the driver accepts does not always own the I2C and can be managed by a higher level interface. An example would be to move the
i2c
device in the struct to be anOption<I2C>
and then put in atake_i2c(&mut self)
and aset_i2c(&mut self, i2c: I2C)
style methods.An alternative I have seen with other drivers, is to just pass the I2C device to each call. Sounds cumbersome, but might be proffered based on the time it takes to do the extra function calls and cross-checks postulated above.
Thoughts?