drivers/sensors: Legacy sensor warning

[linguini1]

Summary

This commit implements a compile-time warning and in-code comment warning for legacy sensor drivers. This is intended to:

• Warn users that legacy drivers may eventually be removed
• Warn developers that they should not use a legacy driver as a reference for their new driver contributions

Closes #18434

Impact

All legacy drivers have a compile-time warning.

Ideally, this makes it easier for contributors to be aware of what to use as a reference.

Testing

N/A: only a comment and #warning directive was added, so if the CI passes all is well.

[raiden00pl]

current/power monitors are not supported in new sensor framework. The question is whether these types of sensors are suitable for this new approach. Probably more suitable than Qenco or Zerocross, but we'll have to think about it carefully.

[linguini1]

I believe the goal was to have them implemented as uORB sensors, as per #18430

That one at least seems suitable, as it returns voltage/current/power information on read which could be done via uORB

[acassis]

@raiden00pl maybe qe, zerocross and other "sensors" that are not really a sensor and doesn't make sense to be in drivers/sensors/ should be moved to other place. See, qe in some way it similar to pulse capture that is in drivers/timers/ so maybe we could move it to there. The zerocross could be there too or in drivers/misc/

Or other alternative is creating a drivers/sensors/misc/ or other better name and move it to there. BTW we can do it during the 13.x release

[acassis]

@linguini1 @raiden00pl I think the support to fixed math to sensors should come with 13.x, so in that in this new release "legacy" drivers will be removed (when its count-part uORB exists) or converted.

@jerpelea seems like we have a lot of work before 13.x be released :-/

[linguini1]

@linguini1 @raiden00pl I think the support to fixed math to sensors should come with 13.x, so in that in this new release "legacy" drivers will be removed (when its count-part uORB exists) or converted.

I think getting the fixed math support for 13.0.0 is a good idea, but I don't know when we'll be able to retire the legacy drivers. I don't have any of those devices to test with/convert to uORB.

@jerpelea seems like we have a lot of work before 13.x be released :-/

Yeah....but we can do our best! Maybe some things will need to wait for a 14.0.0 :)

[raiden00pl]

The initial fixed-math implementation is ready, and porting subsequent sensors can be done one by one. The only problem is that I haven't had a chance to finally verify it on HW yet so it's still marked as draft :)

[linguini1]

The initial fixed-math implementation is ready, and porting subsequent sensors can be done one by one. The only problem is that I haven't had a chance to finally verify it on HW yet so it's still marked as draft :)

I have a limited set of sensors available to me (IMU, mag, baro and GNSS) but I would be willing to help perform some testing for it! I have an RP2040-based flight computer from my L1 rocket flight, and I would be very curious to see the performance improvement on it without having to use floating point for uORB!