[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? 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. 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? > 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). > Details of system: host is a PC running Fedora Core 5 with libusb > 0.1.12. The device is of our own design, running on an ST STR711FR2T6 > on an Olimex STR-H711 board. Embedded code is built using the IAR > STR711 Kickstart kit. The class/subclass/protocol are FF/FF/FF. > Commands are sent to interrupt mode output endpoint 2; status etc. are > read from interrupt mode input endpoint 1. You could suspect that my > embedded code is faulty; but I also have a test bed, using an entirely > different OS, on which the reads never fail. The test bed platform is > an Acorn Risc PC running RISC OS and the Simtec USB stack, the test > application being written in BBC BASIC. This gives me non-blocking > buffered reads. On the test bed, the read operation has never failed, > not even once. This is circumstantial evidence. You'd be better off using a USB bus analyzer to measure what's really happening instead of just making assumptions. 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
