[FEATURE] Create a way to integrate uORB sensors as wrapper around character device sensor to avoid duplication

[acassis]

Is your feature request related to a problem? Please describe.

As discussed here: https://github.com/apache/nuttx/pull/17363 adding support to character device sensor and uORB sensor is non ideal. Although there are "natural" pressure in favor on uORB sensor, they are not the best option for small microcontrollers with few KBs of RAM.

Describe the solution you'd like

I truly believe it is possible to solve this issue creating uORB drivers as a wrapper around character device sensors. It could avoid duplication of driver development and simplify the development.

Describe alternatives you've considered

No response

Verification

• [x] I have verified before submitting the report.

[raiden00pl]

the new sensor framework is a character driver and can be used without urob. You can even use fetch interface without polling thread. So I think this issue is already solved :) the only problem I see for small systems is the use of float to represent sensor data, which I mention in https://github.com/apache/nuttx/issues/10644

[acassis]

@raiden00pl @xiaoxiang781216 @linguini1 what is we define the type of sensor data to be float when !DEFAULT_SMALL and int when DEFAULT_SMALL (assuming that uORB will not be used on DEFAULT_SMALL) ?

[linguini1]

@raiden00pl @xiaoxiang781216 @linguini1 what is we define the type of sensor data to be float when !DEFAULT_SMALL and int when DEFAULT_SMALL (assuming that uORB will not be used on DEFAULT_SMALL) ?

I think unfortunately it will require more work than that. There a few gotchas:

1. We immediately lose floating point values, so it's no longer possible for, say, an accelerometer to measure in m/s^2 unless you only want 1 m/s^2 resolution. So, all the fields will have to change from SI units to maybe something like 0.001 of an SI unit? And we'll need a large enough field, like an i32, to represent enough values.

2. Application level code must now handle two cases: when uORB uses floating point and when uORB uses integers.

You could maybe duplicate structure definitions for the uORB types and have one with float and one with int, but the user still needs to handle two distinct cases.

[acassis]

@raiden00pl @xiaoxiang781216 @linguini1 what is we define the type of sensor data to be float when !DEFAULT_SMALL and int when DEFAULT_SMALL (assuming that uORB will not be used on DEFAULT_SMALL) ?

I think unfortunately it will require more work than that. There a few gotchas:

1. We immediately lose floating point values, so it's no longer possible for, say, an accelerometer to measure in m/s^2 unless you only want 1 m/s^2 resolution. So, all the fields will have to change from SI units to maybe something like 0.001 of an SI unit? And we'll need a large enough field, like an i32, to represent enough values.

2. Application level code must now handle two cases: when uORB uses floating point and when uORB uses integers.

You could maybe duplicate structure definitions for the uORB types and have one with float and one with int, but the user still needs to handle two distinct cases.

1. True, it is an issue to be fixed.
2. No, the idea is not to use it with uORB when CONFIG_DEFAULT_SMALL is selected, so the driver will be used as a char device sensor

[linguini1]

But that is still a problem? Now we have two different sensor driver frameworks to maintain on NuttX. Like @raiden00pl mentioned, "uORB" devices can still be interacted with as character drivers. I guess the confusion here is that I am referring to the new sensor framework as uORB, even though it is technically not dependent on that (mentioned in #10644). I think if users want a character driver, they should interact with the sensor framework devices as character devices instead of through uORB. That way there is still only one framework. The only problem is float dependency. I am firmly against maintaining two different types of frameworks, I would rather solve the float problem.

I guess we should stop referring to the framework as uORB, since uORB is an optional extension. In fact, there at least a few drivers I've contributed where I added depends on UORB where really it doesn't they can be used as char drivers.

[acassis]

But that is still a problem? Now we have two different sensor driver frameworks to maintain on NuttX. Like @raiden00pl mentioned, "uORB" devices can still be interacted with as character drivers. I guess the confusion here is that I am referring to the new sensor framework as uORB, even though it is technically not dependent on that (mentioned in #10644). I think if users want a character driver, they should interact with the sensor framework devices as character devices instead of through uORB. That way there is still only one framework. The only problem is float dependency. I am firmly against maintaining two different types of frameworks, I would rather solve the float problem.

I guess we should stop referring to the framework as uORB, since uORB is an optional extension. In fact, there at least a few drivers I've contributed where I added depends on UORB where really it doesn't they can be used as char drivers.

True, I think the idea of using the sensor driver that works for uORB as a char device will meet the goal of this Feature Request, we just need to fix the float issue and organize the driver to not include uORB features/functions, could depends on CONFIG_SENSORS_UORB or similar

[raiden00pl]

We immediately lose floating point values, so it's no longer possible for, say, an accelerometer to measure in m/s^2 unless you only want 1 m/s^2 resolution. So, all the fields will have to change from SI units to maybe something like 0.001 of an SI unit? And we'll need a large enough field, like an i32, to represent enough values.

@linguini1 that's why I proposed that we should use fixedpoint math already present in NuttX (include/fixedmath.h). In this way, by using a macro to define mathematical operations we should be able to create portable code: https://github.com/apache/nuttx/issues/10644#issuecomment-2592061754

If any unit already used with float implementation doesn't fit for fixedmath, we should change the unit used in float so that both versions of the framework use the same one.

[linguini1]

@linguini1 that's why I proposed that we should use fixedpoint math already present in NuttX (include/fixedmath.h). In this way, by using a macro to define mathematical operations we should be able to create portable code: https://github.com/apache/nuttx/issues/10644#issuecomment-2592061754

If any unit already used with float implementation doesn't fit for fixedmath, we should change the unit used in float so that both versions of the framework use the same one.

This would be a breaking change that in my opinion is very worth it! Good idea!