Switch angle sensors to use integer instead of floating point

[Moddingear]

Instead of using floating point for the angle, use integer, as most angle sensors already quantify the angle.

This makes it more straightforward, and doesn't lose any precision due to floating point. Revolutions and angle are accumulated within a single variable.

Performance-wise, on a STM32G431, it doesn't change anything (loop speed 18311Hz float vs 18230Hz integer), but this is to be expected, as I haven't touched any of the FOC code.

I also have the corresponding changes done in Arduino-FOC-Drivers, but it's a fork of Phoque2_CurrentSense because i'm using that to test. It makes the CalibratedSensor more staightforward, but in the case of true analog sensors, such as the MXLemming, it requires quantization.

[dekutree64]

Interesting proposal, but I think I'll give it a thumbs-down for unnecessary complexity and maintenance difficulty since it doesn't provide much real benefit. The sensor classes mostly handle large angles well already, and it doesn't solve the real problem of floating point range in the PID.

A fixed-point PID wouldn't have any fundamental advantage over float when using 32-bit numbers. I'd expect it to be worse since float can make use of higher precision at low magnitude, and gradually becomes unstable at high magnitude rather than wrapping around and failing completely.

So regardless of int or float, the options are 1. use more bits, or 2. don't let the angle get large in the first place. Since most applications that run into the range problem don't actually need to keep track of the large value, I favor the latter (see my comment here #302). And then float is better for the PID, so leave the motor angle and velocity as floating point radians, which are more human-friendly too.

And CalibratedSensor benefits from having higher resolution than the sensor itself, since if the sensor steps were happening exactly where they should be, there would be nothing to calibrate. So calibrated positions will typically be partway between sensor steps. Quantizing back to the encoder resolution means that sometimes two raw steps will map to the same calibrated step, and some calibrated steps will be skipped over. It doesn't matter to the angle PID since it can't stop between sensor steps, but the FOC current vector can be pointed between sensor steps, so it will run a bit more smoothly.