On Tue, 8 Aug 2006, Dave Higton wrote: > > -----Original Message----- > > From: Alan Stern [mailto:[EMAIL PROTECTED] > > Sent: 2006-Aug-07 15:57 > > To: Dave Higton > > Cc: USB development list > > Subject: Re: [Linux-usb-users] Linux-usb-users > > > > [Moved to linux-usb-devel because it seemed more appropriate] > > > > On Mon, 7 Aug 2006, Dave Higton wrote: > > > > > I'm writing driver functions for a system that I'm working > > on (see below > > > for details). The device in question has two interrupt > > mode endpoints: > > > one in, one out. I'm having an unexpected problem: read > > from the input > > > endpoint is unreliable. > > > > > > If I call usb_interrupt_read() with a timeout of 1, on average about > > > half of the reads simply fail to return any data, i.e. the returned > > > value is -110 despite the device having sent one or more > > messages. I > > > can increase the duration of timeouts, but this is clearly a highly > > > undesirable waste of time for the calling programme, and in > > any case, > > > afaics, this will only reduce the probability of missing > > data, but not > > > to zero. > > > > Do you understand that the timeout value is in milliseconds? > > Yes. > > > So when you > > give a timeout of 1, that means you have allowed no more than > > 1 USB frame > > to get the data. You probably should make the timeout be at > > least 2 or 3 > > times the endpoint's period, to allow for missed messages and retries. > > I want to check repeatedly /whether/ any data have come in since > the last call to usb_interrupt_read(). Normally, none will. I > don't want to waste any time waiting for stuff that won't arrive. > The calling task has other things to do!
It sounds like you really do want to use an asynchronous request. Alternatively, you could use pthreads and set up a separate thread of your program devoted to waiting for those interrupt messages. > > Are you certain that the device sent one or more messages? > > Given that the > > timeout was one frame, how could it have possibly sent more than one > > message? > > Not one or more messages: zero or one message. Messages are only > sent when there is a change in state of any of the switches. That "one or more" was a direct quote from your previous message. Bear in mind also that there's a difference between the device generating a message (queuing it to be sent) and actually sending the message. Messages are generated whenever the switches change state, but they can't be sent over USB until the host polls for them. > > > I have tried calling usb_detach_kernal_driver_np(); the call > > > succeeded (returned value 0), but there was no change to > > the symptoms. > > > So: > > > > > > 1) How can I make the read 100% reliable, > > > > Give it a longer timeout. > > > > > 2) How can I call non-blocking, buffered reads? > > > > Use asynchronous requests (now supported in the newest versions of > > libusb). > > This sounds like exactly what I need. Is it documented somewhere? > The docs I've read still say that asynchronous operation is some > time in the future. Have you installed the most recent version of libusb? I don't know in which release async support was added and I haven't looked at it in years, but I've heard that it's there now. Alan Stern ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
