xiaoxiang781216 commented on PR #10077:
URL: https://github.com/apache/nuttx/pull/10077#issuecomment-1682470450
> > The old interface couple with the hardware directly, which make the
userspace write a general sensor program become an impossible task. For
example, lis2dh, lis3dh, lis3dsh and mpu60x0 report the different measurement
result.
>
> You might as well standardize the character driver interface for sensors
without forcing the user to use uorb. So that's not an argument.
>
The fact is that all sensors expose the different interface util uorb try to
unify the interface across all possible sensors. It welcome other people
provide a new solution to unify the interface, but it's
> > So, it isn't good to write the new senor driver with the old driver
model(actually, there is no common upper half at all).
>
> Why not ? Will uorb be good for all possible use cases? What are the
differences in resources used between uorb and the old approach?
I am not sure whether uorb is good for all possible cases, but it's always
bad that each driver exposes the different IOCTL to userspace just like lis2dh,
lis3dh, lis3dsh and mpu60x0.
> Will it work for applications where we need a high frequency stream of
sensor data (let's say IMU for gimbal controller)? What about small systems?
It's fine with sample rate around 1KHz.
For example, the implementation of an intelligent sensor for industrial
applications, where we only need to read sensor data and send it over
industrial protocol. I don't think we have enough information at the moment.
>
> > Separate upperhalf and lowerhalf
>
> Since when separate upperhalf and lowerhalf is nuttx driver model ?
Most driver which expose file ioctl to userspace follow upperhalf/lowerhalf
model.
> It seems to me that most drivers don't follow this approach and use bus
interface (I2C/SPI) directly.
>
could you give more examples except sensor? at least, analog, audio, crypto,
efuse, input, ioexpander, lcd, leds, math, mmcsd, motor, mtd, net, battery, rc,
rptun, serial, timer, video follow the
> > Define the common IOCTL and struct
>
> Totally agree here. A unified interface is something we must strive for.
But uorb interface is only one way to achieve this.
>
Yes, but before another interface similar interface exist,
> The old approach seems to use less resources (memory, CPU and hence power
consumption) so there are situations where uorb just doesn't make sense. There
are a lot of applications where uorb seems redundant and there is no reason to
force the user to use it.
Nobody forces user to use uorb, both interfaces keep in this patch. But we
don't have enough resource to improve the raw driver interface which we don't
use, so it's better to decouple both implementations.
--
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]
