xiaoxiang781216 edited a comment on pull request #2039: URL: https://github.com/apache/incubator-nuttx/pull/2039#issuecomment-714246971
> Thanks @Donny9 > Yes, of course I don't mean that you should port every driver. I meant that without looking into various drivers it is difficult to know whether this sensor model works in all cases. If we are flexible on this implementation indeed this could be merged and then improve it depending on each case. > > Regarding direct read, I'm not sure if we're talking about the same thing. I wasn't suggesting that you should be able to read I2C registers directly. I was suggesting that the lower part should be able to write into the pointer that read() receives directly. The push_event() interface means that this would not be possible. The only way would be that the upper part be able to _request_ data from the lower part (something like read_sensor(), which would receive a pointer where to read into). This could be a blocking operation, compatible with blocking read. I think it would be good to consider such simple case as an option. It could also be done via signaling (the lower part could invoke a upper half method to signal that new data is available). Here, it's the plan for the new patch: 1. Add read_sensor callback to sensor_lowerhalf_s 2. If lowerhalf implement this callback, upperhalf skip all intermediate buffer stuff 3. upperhalf's read will call the new callback directly in this case On the other hand, the current implelmentation(buffer + push_event) will activate If read_sensor is NULL. So the driver writer can select one approach which is more suitable for his case, but the userspace always use the same method to access the 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
