ryanrightmer / lis3mdl Goto Github PK

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.

Thoughts?

The I2c trait from embedded-hal-async would allow this crate's usage with embassy.

Unfortunately, I can only think of hacky solutions to support both blocking and async:

• Make a second copy of all the functions, doing the rote fn -> async fn transformation and sprinkling in some .await calls
• Macro magic to define two copies using the same source

and then another question is:

• Keep the same type names and swap in async using a feature, or
• Expose the methods on a different type or in a different module (still feature-gated).

I asked in rust-embedded/embedded-hal#356 if there's any best practice here. I think most of the other crates I've seen have gone for some form of duplicate code.