Re: [Libusb-win32-devel] USB transfers are sometimes lost

[Dave H. <DAV...@ni...>]

> From: lib...@li...
> [mailto:lib...@li...]
> On Behalf Of Kjell Eirik Andersen
> Sent: 2007 June 19 14:21
> To: lib...@li...
> Subject: [Libusb-win32-devel] USB transfers are sometimes lost
>
> After having used libusb-win32 exstensively for more than a year
> I have come across a problem with usb_bulk_read().
>
> After several hours of errorfree communication, an usb bulk read
> package is lost (it shows on a SW bus analyzer).
>
> A bulk endpoint is continously read like this :
>
> while ( ! TerminateThread )
> {
>      i =3D usb_bulk_read( pDevH, 0x82, buffer, 64, 1000 );   // 1 sec
timeout
>      if ( i > 0 )
>            process the data
>      else if ( i !=3D TIMEOUT )
>            process error
> }
>
> Q1 : Can anybody confirm that using the libusb API in this way
> may result in lost packages ?

Not strictly an answer to your question, but I have used the
Linux version of libusb with interrupt transfers, in other
respects like you show above.  Yes, I lost packets occasionally.
I had to buy a USB analyser to show where the problem occurred.

You need to set the timeout high enough that it will only ever
be invoked in the case of a genuine failure.

If this gives you a problem of responsiveness in your programme,
i.e. you really need asynchronous transfers, then yes, it's a
problem.  I solved it by using pthreads and a FIFO.  I'm pleased
to report that pthreads seems to work OK under win32 too.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20