Menu
▾
▴
Re: [Libusb-win32-devel] Libusb-win32-devel Digest, Vol 13, Issue 16
|
From: Kjell E. A. <kje...@ta...> - 2007-06-20 06:53:40
|
Hi Dave ! Thanks for your answer. I don't really see how the length of the timeout makes any difference. The application in question does already run in a separate thread and a FIFO is used for the data received. The timing gap I'm trying to close with the ping-pong solution is from the point where usb_bulk_read() returns with data to the point in time where usb_bulk_read() is entered again. I have also noticed that libusb (or is it windows usb subsystem ?) actually buffers data, but I have no idea of the size of the buffers... Best regards, Kjell Eirik -----Original Message----- From: lib...@li... [mailto:lib...@li...] On Behalf Of lib...@li... Sent: 19. juni 2007 21.09 To: lib...@li... Subject: Libusb-win32-devel Digest, Vol 13, Issue 16 Send Libusb-win32-devel mailing list submissions to lib...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel or, via email, send a message with subject or body 'help' to lib...@li... You can reach the person managing the list at lib...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Libusb-win32-devel digest..." Today's Topics: 1. USB transfers are sometimes lost (Kjell Eirik Andersen) 2. Re: USB transfers are sometimes lost (Dave Higton) ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Jun 2007 15:21:06 +0200 From: "Kjell Eirik Andersen" <kje...@ta...> Subject: [Libusb-win32-devel] USB transfers are sometimes lost To: <lib...@li...> Message-ID: =09 <C02...@EU... > =09 Content-Type: text/plain; charset=3D"us-ascii" =20 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). =20 =20 A bulk endpoint is continously read like this : =20 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 } =20 Q1 : Can anybody confirm that using the libusb API in this way may result in lost packages ? =20 The plan now is to try using the async API with 2 buffers (ping-pong) like shown below and check if the problem disappears : =20 i =3D 0; i +=3D usb_bulk_setup_async( pDevH, &context1, 0x82 ); i +=3D usb_bulk_setup_async( pDevH, &context2, 0x82 ); i +=3D usb_submit_async( context1, ibuf1, 64 ); i +=3D usb_submit_async( context2, ibuf2, 64 ); if ( i !=3D 0 ) printf( "\nErrors : %d", i ); // Close down, replug etc. ?? =20 while ( ! TerminateThread ) =20 { //--- Buffer 1 --- i =3D usb_reap_async( context1, INFINITE ); // INIFINITE =3D -1 if ( i < 0 ) printf( "\nReap 1 error : %d", i ); else { printf( "\nReap 1 received : %d, %c", i, ibuf1[0] ); process data } i =3D 0; =20 //i +=3D usb_free_async( &context1 ); //i +=3D usb_bulk_setup_async( pDevH, &context1, 0x82 ); i +=3D usb_submit_async( context1, ibuf1, 64 ); if ( i !=3D 0 ) printf( "\nErrors : %d", i ); // Close down, replug etc. ?? =20 //--- Buffer 2 --- i =3D usb_reap_async( context2, INFINITE ); if ( i < 0 ) printf( "\nReap 2 error : %d", i ); else { printf( "\nReap 2 received : %d, %c", i, ibuf2[0] ); process data } i =3D 0; =20 //i +=3D usb_free_async( &context2 ); //i +=3D usb_bulk_setup_async( pDevH, &context2, 0x82 ); i +=3D usb_submit_async( context2, ibuf2, 64 ); if ( i !=3D 0 ) printf( "\nErrors : %d", i ); // Close down, replug etc. ?? } =20 i =3D usb_cancel_async( context1 ); i +=3D usb_cancel_async( context2 ); i +=3D usb_free_async( &context1 ); i +=3D usb_free_async( &context2 ); =20 Q2 : Is this the correct way to use the async API ? =20 Q3 : Am I right in assuming that the usb_free_async() and usb_bulk_setup_async() which is commented out inside the loop is really unneccessary ? (it seems to work with a small limited testprogram) =20 Any response on my three questions would be greatly appreciated ! =20 Best regards, Kjell Eirik -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 2 Date: Tue, 19 Jun 2007 15:01:01 +0100 From: "Dave Higton" <DAV...@ni...> Subject: Re: [Libusb-win32-devel] USB transfers are sometimes lost To: <lib...@li...> Message-ID: <B71...@so...> Content-Type: text/plain; charset=3D"us-ascii" > 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 End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy 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 computing practice the recipient should ensure they are actually virus free. ************************************************************************ ************************************************************************ ************************************************************************ **************************** =20 ------------------------------ ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ------------------------------ _______________________________________________ Libusb-win32-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel End of Libusb-win32-devel Digest, Vol 13, Issue 16 ************************************************** |
