Patras, George wrote:
> I'm having a performance (I think) related issue using libusb.
> Firstly about the device, it's a Cypress FX2 USB2.0 based fingerprint
> reader that provides a 1.3MB image over bulk endpoint (maxpacket size
> 512 bytes). No frame buffering on the device, only the 2K fifo on the
> Cypress, so basically the host has to keep up with the camera rate on
> the device or there is a data overrun. I calculated the required
> (sustained) bulk data rate I need to be ~19.7MB/s.
Whoo, that's a gamble. If the user has a web camera running, there's a
very good chance you wouldn't be able to sustain 20MB/s under the best
of conditions. You should very seriously consider adding a FIFO RAM to
hold one frame. That eliminates both of these issues.
> When I call usb_bulk_read (for the full image size), I see the first
> 32 packets (16K) come across fine (I have a USB protocol analyzer
> hooked up). At this point the host is fast enough - getting about
> 5 IN transactions per microframe, and plenty of NACKED requests.
> Suddenly at the 16K boundary the host stops polling (no IN transaction
> requests) for 3ms (seems like a really long time). At this point there
> is an overrun and loss of data on the device. Tried with smaller sized
> read requests - same issue...
True. Libusb chops the request up into 16k byte transfers, because some
versions of the Linux usbfs driver had a limit of 16k bytes per URB. I
don't know if that limit still exists or not.
Because libusb is synchronous, it submits one URB and waits for the
result. Between the time the URB completes and it is able to resubmit
the request, you miss whole frames.
The only way to do sustained, continuous transfers is to have multiple
URBs submitted at once, so that the host controller never runs dry. You
can't do that with libusb. You'll have to write directly to the usbfs
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.