btashton commented on pull request #2039: URL: https://github.com/apache/incubator-nuttx/pull/2039#issuecomment-714251530
> > 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 regardless wether the buffer exist or not. I don't think that addresses the issue. Its not if the the lower half driver implements a buffer it is if the _user_ can provide the buffer to be used. Perhaps we could allow the user application to register an actual FIFO? Right now I can have a temperature sensor and simply say I want to read 10 samples starting now. I do that by issuing a read of 10 bytes to the driver and providing it the buffer. This is nice and thin. Now for an IMU this is likely terrible. I want to be sampling data and processing it at the same time, this is where this interface here really shines. The question is how do we also support that give me 10 temperature samples to this buffer starting now case. ---------------------------------------------------------------- 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
