Non-floating-point normalized readings

[tcbennun]

I'm using the ESP32-C3, which doesn't have floating-point hardware, meaning any floating-point code is very inefficient. It would be good to have the option to implement without floating-point, e.g. a variant of accel_norm returning e.g. I32x3 in units of ±mg, or maybe a fixed-point impl. Maybe Accelerometer should take a generic V: Vector like RawAccelerometer does?

[tarcieri]

The point of a normalized Accelerometer is to have a common representation that works across different types of accelerometers.

If you don’t want that, use RawAccelerometer.

[tcbennun]

Hi @tarcieri - apologies if I've not been clear. I understand the purpose of the trait.

I take issue with the trait returning normalized values as f32. Many microcontrollers don't have floating-point hardware. The same normalized acceleration could be returned in fixed-point or signed integral types (with some precision loss, and in a scaled unit).

It would be possible to design this crate so that implementors could choose to work with a number of underlying representations, not just floating-point. I just wanted to get opinions on that point.

[tarcieri]

All of the functionality in the crate which operates on the normalized representation such as orientation detection is implemented in terms of floating point.

In general algorithms for computing spatial rotations/transformations are more naturally expressed as floating point, including quaternions, rotors, and Madgwick.

I don't think it makes sense to change the normalized representation to an integer representation.

Also note this crate is practically unmaintained as I no longer work directly on accelerometers and haven't found anyone to hand it off to.

[tcbennun]

Natural though floating-point may be, I believe that extensive hardware compatibility is key to the embedded Rust ecosystem. I'd be extremely surprised if FP were ever used in an embedded-hal trait (it certainly isn't so far).

In Rust, it is feasible to generalise mathematical operations such that an arbitrary underlying representation can be used, and this allows the introduction of maths-heavy traits like Accelerometer while giving implementors and users the choice to use FP, emulate FP, or avoid FP completely.

Not that it matters; I didn't realise the crate was unmaintained! Thanks for taking the time to comment.