acassis commented on PR #17363: URL: https://github.com/apache/nuttx/pull/17363#issuecomment-3567800577
> The major problem of legacy char driver is that userspace can't write the general code to handle the sensor in unified way. For example, we have the following accelerometer sensor legacy char driver: https://github.com/apache/nuttx/blob/master/drivers/sensors/kxtj9.c https://github.com/apache/nuttx/blob/master/drivers/sensors/lis2dh.c https://github.com/apache/nuttx/blob/master/drivers/sensors/lis3dh.c https://github.com/apache/nuttx/blob/master/drivers/sensors/lis3dsh.c https://github.com/apache/nuttx/blob/master/drivers/sensors/mpu60x0.c You have to write the different code to extract the real x/y/z accelerator from them: https://github.com/apache/nuttx-apps/blob/master/examples/lis3dsh_reader/lis3dsh_reader_main.c#L67-L80 https://github.com/apache/nuttx-apps/blob/master/examples/sensor_fusion/sensor_fusion_main.c#L134-L163 Now, we add a new one into the list. > > From the design point of view, the legacy char driver is no much difference that we acccess sensor hardware through i2c/spi directly. So, whether using uORB is a minor issue comparing that the same type sensor expose the different driver interface. Yes, I think accelerometers and other char devices sensor need a standardization, this way we avoid creating different applications for each sensor. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
