I believe we should move all drivers to uORB. It is deceiving to call it "uORB", as the uORB features don't need to be included for the sensor driver to work. It is just a standardized sensor interface that can be interacted with as a char driver (the POSIX way). uORB does build on top of that to provide additional features if enabled.
The biggest issue, as pointed out, is that the standardized interface relies on floating point. This is pretty unfortunate for systems that need to bundle (typically large) floating point math libraries in order to handle floats. However, as was suggested, we can add the proposed solution of choosing between floating point and fixed point numbers which can resolve this problem. I think (?) from memory uORB is mentioned in the contribution guidelines as well as the documentation about sensor drivers (at the top level page), but I'm not certain. For old sensors, I think they have to stay in the kernel until someone has time to migrate them to the standardized approach. This seems unlikely to happen unless someone has a use-case, but there's not point deprecating those features until we can replace them. I just think that all new sensors should take the standardized approach coming in or we'll never have a unified interface to be used. The floating point is more of an issue now that KR (who I believe works almost exclusively on AVR) cannot easily integrate that onto their devices. We should probably get a fixed-point version implemented quickly. Matteo On Sat, Nov 29, 2025 at 1:52 PM spudaneco <[email protected]> wrote: > The traditional driver interface is defined in the POSIX standard and must > be preserved in any case. My naive understanding is that uORB buils on the > traditional, standard driver interface. True?Sent from my Galaxy > -------- Original message --------From: Tomek CEDRO <[email protected]> > Date: 29/11/25 11:29 am (GMT-06:00) To: [email protected] Subject: > [DISCUSSION] sensor drivers / uORB / floats / integers Hello world :-)It > seems that new way of implementing sensor drivers is the uORB way[1][2][3]. > There were two contributions recently that added IMU andTemperature sensor > drivers, first provided old and new way, secondonly the old way.Question is > if we really want to switch all sensors to the uORB style?If so what do we > do with the old sensors (in terms of existing andincoming code)?What are > the benefits (standard interface and datastream, etc) anddisadvantages > (more memory used, driver rewrite, etc)?Lets discuss about how to better > communicate that we now prefer theuORB aligned sensor drivers. True deep in > the documentation it is hardto find and not very obvious. Someone may feel > bad that they alreadyput an effort in the driver that will be > rejected.Another discussion is that uORB for now uses Floating Point > numbers,that is a problem on MCUs without FPU, and even worse on 8-bit > ones(like AVR). Raiden already opened an Issue on this on GH [4] > andproposes build time selectable fixed point or floating > pointrepresentation of uORB sensor data stream.Any hints welcome > :-)Tomek[1] > https://nuttx.apache.org/docs/latest/components/drivers/special/sensors.html[2] > https://nuttx.apache.org/docs/latest/components/drivers/special/sensors/sensors_uorb.html[3] > https://nuttx.apache.org/docs/latest/applications/system/uorb/index.html[4] > https://github.com/apache/nuttx/issues/10644--CeDeROM, SQ7MHZ, > http://www.tomek.cedro.info
