I think 1) is easily solved by implementing the 'fetch' function, as some sensors do already.
For 2), I haven't looked directly at what would need to be modified on the existing standard sensor drivers to make them work without uORB. To my knowledge I don't think there is anything major? ioctl calls are a pass through to basically all of the standard driver functions except for data fetching. A read operation either reads from an internal circular buffer that data is pushed to by the driver (often times by a thread as you say, sometimes in an interrupt handler) or it uses the "fetch" function to read on demand. At least, that is my understanding. I'm not sure what extras really need to be fixed besides making sure that "fetch" exists for these drivers? For 3), I don't really think it's possible to make a wrapper around the legacy drivers to make them compatible with the standard interface. It'll require a custom wrapper for each sensor most likely. Nor do I think it's worth it; just use the legacy interface or write a new driver in the standard interface. I agree that the docs could be better about how to write "uORB" sensors. That being said, at least the docs exist now! Maybe I can help write some in the near future. Matteo On Sat, Nov 29, 2025, 4:46 PM Alan C. Assis <[email protected]> wrote: > 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 > > >
