acassis commented on PR #17363: URL: https://github.com/apache/nuttx/pull/17363#issuecomment-3567107909
> > I think char device sensor still important on NuttX because for boards with low resource adding uORB will be too much. This is the same relation with CAN char device and SocketCAN, both implementations should exist to live together peacefully. > > Honestly I disagree. The requirement going forward for all sensor drivers was that they must support uORB, so we have a few drivers already that are uORB capable but do not have a legacy-style version, since most people do not want to do double the work. We definitely can't require people to submit both styles, so I don't think we should be supporting additional legacy drivers unless there's a use-case for them. I think supporting both versions is confusing to users and makes maintenance difficult. I also don't think uORB is that resource-intensive besides the floating point requirement, but it was decided when uORB became a requirement that the `float` dependency was fine. > > If the community still wants to support legacy sensor drivers in addition to uORB that's fine, I will yield, but the drivers will be perpetually out of sync which I think is a problem. Regardless, I still think the implementation in this PR needs changes if both styles are to be kept, since it currently requires shared header and C files that expose private parts of the API which are not exposed in any other sensor drivers on NuttX. Yes, I agree that it could generate some drivers only supporting one or other implementation. Same also happens with CAN. It should be nice if uORB was just a wrapper around the char device, this way we could avoid this issue. But I don't know if it is possible. Maybe @xiaoxiang781216 has some suggestion. -- 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]
