DeviceFS call for a single USB read
Dave Higton (1515) 3497 posts |
I’d like to see a DeviceFS call for a single read from a USB bulk IN endpoint, so that the message boundaries are preserved. One call must return exactly one or zero USB messages. Blocking and padding should be specified as parameters to the call. |
Rick Murray (539) 13806 posts |
…provided you can specify a timeout so after X centiseconds it will set V and return. Otherwise, what happens if you are waiting on a byte that never arrives? |
Dave Higton (1515) 3497 posts |
That’s exactly what blocking is about. It has to return one or zero USB messages. No fractions, no multiples. |
Rick Murray (539) 13806 posts |
? My interpretation of “blocking” is that if you ask for a USB message, it will return one – even if that means busy-waiting in a loop for seventeen days (or failing with an error/exception). This is why non-blocking was a revelation. It wouldn’t be difficult if the return was zero or one to just “poll” the blocking device from time to time, however because it was a blocking device (as to a pollable one), asking for a response would wait – forever if necessary – for the required conditions to be met in order that a response be provided. |
Dave Higton (1515) 3497 posts |
Ah, I see how you’ve construed my words. I suggested blocking should be a parameter to the call – therefore the call could be set to be blocking or non-blocking. You should have the choice. I didn’t expect to have to spell out that the “blocking” parameter could be set to either of two values. |