Menu
▾
▴
Re: [Libusb-win32-devel] Libusb-win32-devel Digest, Vol 13, Issue 6 INFINITE
|
From: Par L. <par...@ls...> - 2007-06-06 20:50:27
|
Hi You can use INFINITE in calls with timeout property. WaitForSingleObject(c->ol.hEvent, INFINITE); INFINIT == 0xFFFFFFFF This will solve your problem with infinite timeout pär lib...@li... wrote: > 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_interrupt_read timeouts (Dave Higton) > 2. Re: usb_interrupt_read timeouts (Dan Ellis) > 3. Re: Help, please (Bertrik Sikken) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 6 Jun 2007 16:54:55 +0100 > From: "Dave Higton" <DAV...@ni...> > Subject: [Libusb-win32-devel] usb_interrupt_read timeouts > To: <lib...@li...> > Message-ID: > <B71...@so...> > Content-Type: text/plain; charset="US-ASCII" > > In the Linux version of libusb, the usb_interrupt_read () function can > accept a value of 0 for the timeout, which is interpreted as "infinite". > In the win32 version, this is not accepted. OK, I can put any finite > timeout that I choose, and loop round infinitely on a separate thread, > putting any resulting input into a FIFO. > > But what happens if a USB message comes in immediately after the > timeout, but before the new call? Is any such message lost? > > 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. > > **************************************************************************************************************************************************************************************************************************************************** > > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 06 Jun 2007 17:34:30 +0100 > From: Dan Ellis <dan...@ne...> > Subject: Re: [Libusb-win32-devel] usb_interrupt_read timeouts > To: lib...@li... > Message-ID: <466...@ne...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Dave Higton wrote: > >> In the Linux version of libusb, the usb_interrupt_read () function can >> accept a value of 0 for the timeout, which is interpreted as "infinite". >> In the win32 version, this is not accepted. OK, I can put any finite >> timeout that I choose, and loop round infinitely on a separate thread, >> putting any resulting input into a FIFO. >> >> But what happens if a USB message comes in immediately after the >> timeout, but before the new call? Is any such message lost? >> >> > After the timeout, the host will no longer be sending IN requests, so > the device will not be able to return any data. > > There's possibly a tiny hole - after the timeout has elapsed, libusb > then cancels the IO. The IO could have validly completed between these 2 > events, but the data would be lost. > > if(WaitForSingleObject(c->ol.hEvent, timeout) == WAIT_TIMEOUT) > { > /* request timed out */ > if(cancel) > { > _usb_cancel_io(c); > > /* wait until the request is cancelled */ > WaitForSingleObject(c->ol.hEvent, 0); > } > > usb_error("usb_reap: timeout error"); > return -ETIMEDOUT; > } > > > Dan. > > > > ------------------------------ > > Message: 3 > Date: Wed, 06 Jun 2007 18:53:13 +0200 > From: Bertrik Sikken <be...@si...> > Subject: Re: [Libusb-win32-devel] Help, please > To: lib...@li... > Message-ID: <466...@si...> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephan Meyer wrote: > >> Try to replace: >> >> uci = usb_claim_interface (udev, 0); >> >> with >> >> usb_set_configuation(udev, 1); >> uci = usb_claim_interface (udev, 0); >> >> It should work then. >> > > I think I recently saw a recommendation on the libusb list to NOT > do an explicit usb_set_configuration. If I remember correctly > Linux already picks a configuration for you (usually devices > only have one configuration anyway). > > What is the proper thing to do when writing something for > both Linux and Windows? > > Bertrik > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGZuZ5ETD6mlrWxPURAtnYAKC7W8MBiP9BX7T0hAO+FmkkYWwiTwCffRzX > 8sYXDF1I8zqjbrFgAzgi3nA= > =YZxP > -----END PGP SIGNATURE----- > > > > ------------------------------ > > ------------------------------------------------------------------------- > 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 6 > ************************************************* > > |
