search

eldruin / lsm303agr-rs

Platform agnostic Rust driver for the LSM303AGR ultra-compact high-performance eCompass module: ultra-low-power 3D accelerometer and 3D magnetometer
Apache License 2.0
18 stars 14 forks source link

Support for other LSM303x devices #7

Open rubberduck203 opened 3 years ago

rubberduck203 commented 3 years ago

I am the maintainer for the stm32f3-discovery board support crate, which is a replacement for the old f3 bsc.

It has recently come to my attention that the STMF3Discovery board has newer revisions with this IMU on board instead of the LSM303DLHC. The accelerometers on the AGR and DLHC are compatible, only the magnometers and temperature sensors differ. In fact, the old, unmaintained, lsm303dlhc driver works just fine for the accelerometer.

This driver's API is also already almost compatible with the old [lsm303dlhc driver]().

I understand that the LSM303DLHC is obsolete and out of production, but there are still a number of them floating around in the wild and I would like to support both variants of the board if I can.

I can, obviously, plaster over the differences in APIs and use a feature gate to switch between the two drivers, but I was curious if you'd be open to adding support for the older device here, considering they share so much common implementation code. I'm happy to put in some work here, but didn't want to do so if there wasn't a chance of it being merged.

eldruin commented 3 years ago

Thank you for your work on the stm32f3-discovery BSC. I have been wanting to switch to it myself here too.

This is an interesting point. I would be open to making this driver compatible with the lsm303dlhc behind an lsm303dlhc flag or similar, provided that the code can be kept reasonably confined. I would like to keep the method names used in this crate, though, at least for now. It would be good if you could put as much as possible related to the lsm303dlhc inside a module similarly named, including all the applicable methods from the LSM303AGR as well as tests for the functionality as available here. Once that is available, I can restructure the rest of the crate, provide a set of traits for both models and so on.

What I am skeptical about is implementing the Accelerometer traits as I have now seen in your BSC. That crate adds the whole micromath dependency just for a vector definition, contains a whole error mechanism with specific kinds, etc. But that is a separate discussion.

rubberduck203 commented 3 years ago

Ok. I’ll work on it as I have time.

FWIW I’m fine continuing to implement Accelerometer on the bsc side of things. It has other problems, like using g instead of mg, which forces you into a float. Fine for my purposes, because the stm32f3 has an FPU. Not ok for a general use HAL IMO. It’s also not well maintained. I’m probably going to take a stab at a different abstraction which includes magnometer and temperature as well as a compass, but I digress.

Thanks for the quick response and your work on this driver. I’ll see what I can come up with.