On 12/2/2011 9:57 AM, Ekkehard wrote:
> Hello,
> I try to read from an bulk endpoint with usb_bulk_read. I want to read a big
> buffer (e.g. 256KByte) in once, but the function returns immediatly with a
> positive return value, but less then given buffer size. I can see, that the
> buffer is only partly filled.
usb_bulk_read() will always return when the device returns a short
packet. This is expected.
libusbK has an IGNORE_SHORT_PACKETS pipe policy that works well for
this. Functionality could be further enhanced with the stream API.
> If I use my cypress usb testkit, the function waits until the buffer is
> filled and returns the full length or -116 for timeout.
If your device is returning short packets then somewhere the cypress
codes are submitting multiple or re-submitting transfer URBs to make
this work; similar to what you would do with the libusb-win32 async api.
> Also an alternative loop with usb_submit_async .. usb_reap_async dont work
> because the very short truncs of data does not allow a continously read.
> Any idea where to search?
>
>
I think you could create your own pipe thread and use the libusb-win32
async api to keep several request pending at once. As the small
transfers complete, copy them into your "big buffer" and re-submit
them. As the big buffer(s) fill up, signal a big buffer(s) ready
event/semaphore. This is more work but performance should be as high as
possible.
Regards,
Travis
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Locked
