Menu
▾
▴
Re: [Libusb-win32-devel] =?iso-8859-15?q?Libusb-win32-devel_Digest=2C?= =?iso-8859-15?q?_Vol_13=2C_Issue_16?=
|
From: Stephan M. <ste...@we...> - 2007-06-25 18:49:28
|
> > 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. There is no 'gap' you have to close because there's no data being send between the two read requests. Libusb and Windows only transfer data when you send a read or write request to your device. > > 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... Neither libusb nor Windows buffers any data. All data read from your device is written straight into your read buffer. Stephan > > 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: > > <C02...@EU... > > > > Content-Type: text/plain; charset="us-ascii" > > > > 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 = usb_bulk_read( pDevH, 0x82, buffer, 64, 1000 ); // 1 sec > timeout > > if ( i > 0 ) > > process the data > > else if ( i != TIMEOUT ) > > process error > > } > > > > Q1 : Can anybody confirm that using the libusb API in this way may > result in lost packages ? > > > > The plan now is to try using the async API with 2 buffers (ping-pong) > like shown below and check if the problem disappears : > > > > i = 0; > > i += usb_bulk_setup_async( pDevH, &context1, 0x82 ); > > i += usb_bulk_setup_async( pDevH, &context2, 0x82 ); > > i += usb_submit_async( context1, ibuf1, 64 ); > > i += usb_submit_async( context2, ibuf2, 64 ); > > if ( i != 0 ) > > printf( "\nErrors : %d", i ); // Close down, replug etc. ?? > > > > while ( ! TerminateThread ) > > { > > //--- Buffer 1 --- > > i = usb_reap_async( context1, INFINITE ); // INIFINITE = -1 > > if ( i < 0 ) > > printf( "\nReap 1 error : %d", i ); > > else > > { > > printf( "\nReap 1 received : %d, %c", i, ibuf1[0] ); > > process data > > } > > i = 0; > > //i += usb_free_async( &context1 ); > > //i += usb_bulk_setup_async( pDevH, &context1, 0x82 ); > > i += usb_submit_async( context1, ibuf1, 64 ); > > if ( i != 0 ) > > printf( "\nErrors : %d", i ); // Close down, replug etc. ?? > > > > //--- Buffer 2 --- > > i = 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 = 0; > > //i += usb_free_async( &context2 ); > > //i += usb_bulk_setup_async( pDevH, &context2, 0x82 ); > > i += usb_submit_async( context2, ibuf2, 64 ); > > if ( i != 0 ) > > printf( "\nErrors : %d", i ); // Close down, replug etc. ?? > > } > > > > i = usb_cancel_async( context1 ); > > i += usb_cancel_async( context2 ); > > i += usb_free_async( &context1 ); > > i += usb_free_async( &context2 ); > > > > Q2 : Is this the correct way to use the async API ? > > > > 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) > > > > Any response on my three questions would be greatly appreciated ! > > > > 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="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 = usb_bulk_read( pDevH, 0x82, buffer, 64, 1000 ); // 1 sec > timeout > > if ( i > 0 ) > > process the data > > else if ( i != 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. > > ************************************************************************ > ************************************************************************ > ************************************************************************ > **************************** > > > > > > > ------------------------------ > > ------------------------------------------------------------------------ > - > 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 > ************************************************** > > > ------------------------------------------------------------------------- > 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 > _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 |
