Hi Matteo, I agree that the sensors that follow the uorb/usensor interface are standardized and it solves a common problem with sensors: the non-uniform/non-standard unit of measure.
However we have some big challenges to get a sensor that was implemented as a usensor to work as a simple character device sensor: 1) Most of the *uorb.c sensors implement a thread inside the sensor, for a simple char dev sensor that will run in a board with few KBs RAM, the cadence of reading should be done in the application. It saves precious KB of stack used by this extra thread 2) uORB/usensor were implemented to work with the pub/sub uORB, so there are many extra things that need to be disabled to reduce space. 3) Currently we have only 29 uorb sensors: $ ls *uorb* adxl362_uorb.c bmm150_uorb.c goldfish_sensor_uorb.c mcp9600_uorb.c adxl372_uorb.c bmp180_uorb.c hyt271_uorb.c mpu9250_uorb.c bh1749nuc_uorb.c bmp280_uorb.c l3gd20_uorb.c ms56xx_uorb.c bme680_uorb.c ds18b20_uorb.c l86xxx_uorb.c sht4x_uorb.c bme688_uorb.c fakesensor_uorb.c lis2mdl_uorb.c wtgahrs2_uorb.c bmi088_uorb.c fs3000_uorb.c lsm6dso32_uorb.c bmi160_uorb.c gnss_uorb.c lsm9ds1_uorb.c bmi270_uorb.c goldfish_gnss_uorb.c ltr308_uorb.c In other hand we have almost 3x more legacy char dev sensors: $ shopt -s extglob $ ls !(*uorb*) adt7320.c bmg160.c hdc1008.c lsm9ds1_base.c scd30.c adt7320.h bmi088_base.c hts221.c lsm9ds1_base.h scd41.c adxl345_base.c bmi088_base.h ina219.c lsm9ds1.c sensor.c adxl345.h bmi088.c ina226.c ltc4151.c sensor_rpmsg.c adxl345_i2c.c bmi160_base.c ina3221.c Make.defs sgp30.c adxl345_spi.c bmi160_base.h isl29023.c max31855.c sht21.c adxl372.c bmi160.c Kconfig max31865.c sht3x.c aht10.c bmi270_base.c kxtj9.c max44009.c sps30.c ak09912.c bmi270_base.h lis2dh.c max6675.c t67xx.c amg88xx.c bmi270.c lis331dl.c mb7040.c tmp112.c apds9922.c bmp180_base.c lis3dh.c mcp9844.c usensor.c apds9960.c bmp180_base.h lis3dsh.c mlx90393.c veml6070.c as5048a.c bmp180.c lis3mdl.c mlx90614.c vl53l1x.c as5048b.c CMakeLists.txt lm75.c mpl115a.c xen1210.c as726x.c cxd5602pwbimu.c lm92.c mpu60x0.c xen1210.h bh1749nuc_base.c dhtxx.c lps25h.c ms58xx.c zerocross.c bh1749nuc_base.h fxos8700cq.c lsm303agr.c msa301.c bh1749nuc.c hall3ph.c lsm330_spi.c nau7802.c bh1750fvi.c hc_sr04.c lsm6dsl.c qencoder.c So, the effort to convert these sensors should be huge, this is why I suggested: https://github.com/apache/nuttx/issues/17365 But we need some creative and inspired minds to be able to make this sensor adaptation. 4) And as KG (Kerogit) commented we need some Documentation explaining how to write uORB sensors, although the existing examples already help, new developers will need some Documentation to understand better (and fast) how to write proper uORB sensor (and char dev compatible) drivers. I think Mateusz (Raiden00) already started working on the first step: adding fixed point support to uORB. BR, Alan On Sat, Nov 29, 2025 at 5:09 PM Matteo Golin <[email protected]> wrote: > 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 >
