WIP: initial support for fixed-point data for sensors

[raiden00pl]

Summary

WIP code for fixed-math data type for sensors.

All sensor math operations will require modification to use sensor_data_xxx macros.

At the moment, no sensor is modified to handle this properly. I'll probably choose the easiest sensor to port with a small amount of math operations to provide PoC.

EDIT: ported bmp280_uorb to fixed-math, probably the easiest one :)

Ultimately, all sensor units must be checked to see if the data unit make sense for the b16_t type.

Doing this work all at once is a lot of work which I don't want to do, so I suggest introducing this change gradually:

1. introducing a configurable sensor data type and raise compilation error in all sensors that don't support fixed-point data type
2. gradually port sensors to use fixed-point data and remove compilation errors
3. on the app side we need to modify uorb tools to work with fixed-point data. At this moment we can just raise compilation error for fixed-point data type, and add depends on SENSORS_USE_FLOAT

Impact

Testing

[linguini1]

One more thing about this; we should investigate if b16 is ever too small for a sensor's resolution. I would imagine float might have this same problem when compared to double for high-resolution sensors, but if there are any values that would fit in float and not b16, we should consider:

a) having those sensors depend on the float representation, so users can only use them with floats
b) allowing the user to choose b16 vs b32 (and maybe also float vs double)?

What do you think?

[raiden00pl]

It would be best to choose sensor units that make sense for both float and fixed-point.

With this architecture it should be possible to add other data types for sensors, but using 64-bit data seems like a overkill to me. So far, the highest resolution of data in commercial available sensors that I have seen is 24 bits.

[lupyuen]

Hi @raiden00pl: I'm testing a new way to Build PRs in Our Own NuttX Repos, wonder if you would like to try out, and give your feedback to @simbit18 and me? Thank you so much :-)

1. Demo Video in YouTube
   Demo Video in Google Drive
2. Browse to github.com/NuttX/manual-nuttx-ci
3. Click "Fork" to clone the repo
4. Click "Actions > Enable GitHub Actions"
5. Click "Manually Build NuttX > Run Workflow"
6. Enter the following:
   • Repo for NuttX: raiden00pl/nuttx
   • NuttX Branch: sensors_fixedmath
   • Repo for NuttX Apps: apache/nuttx-apps
   • NuttX Apps Branch: master
   • Host Platform: all
7. And the PR Build should start. Lemme know if it doesn't work thanks!
8. Why are we doing this? Earlier this year, we saw very high usage of GitHub Runners. By building PRs in Our Own NuttX Repos, we will greatly reduce our usage of GitHub Runners, so that ASF Infrastructure Team won't revoke our access to GitHub CI. So we hope everyone can help out thanks :-)

[raiden00pl]

I've done some tests with thingy53 and it works well. The only problem is that b16_t saturates faster than float and for some sensors full sensor range can't be achieved. But this is something we have to accept when choosing this type of data.

Here sensors with float:

Here sensors with b16_t (you can observe that rgb0 saturate at ~32k) :

[linguini1]

I'm hoping to try using this with an upcoming project; do you think we could add an option so that the user can choose between b16 and b32? I'm using a barometer in a rocket which should experience a pretty wide range of pressures, I'd like to avoid saturation but like the integer format.