raiden00pl commented on PR #10077:
URL: https://github.com/apache/nuttx/pull/10077#issuecomment-1681815762
> 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.
> 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?
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? 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 ? It seems
to me that most drivers don't follow this approach and use bus interface
(I2C/SPI) directly.
> 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.
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.
--
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]
