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
