Re: [Libusb-win32-devel] About the GN3S application and lib functions"usb_reap_async" and "usb_submit_async"

[Michael P. <mic...@gm...>]

Feng wrote:
>> 1) What is procedures of reading data, especially, what do the
>> functions "usb_reap_async" and "usb_submit_async" do?

Based on the question, this is someone else's code, not yours?  If I
understand correctly, "submit" tells the OS to schedule the transfer, and
"reap" cleans up (which involves getting the requested data back on a read).
Evidently, usb_reap_async() can block for USB_TIMEOUT (a number you didn't
include) in your case.  Take this with a grain of salt, as I've only used
synchronous interfaces, and am figuring what I can from your code and the
libusb source.  If you want to see a simpler example, you might read the
source to _usb_transfer_sync().  It uses these functions.


>> 2) What is the inspiration of reading, by interrupt or something.

Not sure I understand what you mean by "inspiration".  Maybe you could
rephrase that?


>> 3) Is there any ways to check the data number in the buffer. The code
>> uses usb_control_msg to check the buffer is overflow or not, but it
>> doesn't provide the data number.

Which buffer?  You could write a member function that returns
d_input_leftover, but I don't know about OS or driver buffers.  It looks
like (maybe?) calling with nbytes<=d_input_leftover will not cause it to
block, but might still schedule another transfer.  Eventually, you're going
to have to let it call reap, though (at some rate related to the GPS
device's update rate), so you'll either need to plan for that, or else
thread.  If you do thread, don't access the same device from more than one
thread; copy to a buffer and make sure that buffer is accessed
synchronously.  This stuff is nice, since you can submit the read and then
block on buffer access in the reader thread, if need be.



Michael