On Fri, 19 Aug 2005, Pete Zaitcev wrote: > On Fri, 19 Aug 2005 11:04:31 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> > wrote: > > On Thu, 18 Aug 2005, Pete Zaitcev wrote: > > > > Just queue two URBs and voila. > > > > It's not that simple. If you queue two bulk URBs, they will generally > > both execute in the same frame. > > But only one will complete if the device supplies data for one.
True. In this situation the URB is simply a request to read a device register. Presumably the device will always answer the request immediately, even if the register's contents aren't interesting. > > To do what Uwe wants, it will be necessary to have a driver or program > > wake up every millisecond to submit a bulk URB. That can be done, > > although not reliably. And only if the computer has its timer interrupt > > rate set at 1000 Hz or higher (which isn't true of all platforms). > > How is it different from interrupt URBs? It differs in a couple of ways. With bulk URBs, if the device has no data available the host will continue to pester it over and over, many times within a single frame -- thus consuming USB bandwidth (which may not matter) and PCI bandwidth. With interrupt URBs, if the device has no data available the host will not send the request again until the next period. Another difference lies in how the host treats resubmissions. If a bulk URB completes and the completion handler resubmits it, there's a very good chance the URB will be re-queued and reissued during that same frame (it depends partly on what other URBs are also queued). If an interrupt URB completes and the completion handler resubmits it, the URB won't be reissued until the next frame at the earliest -- later if the period is greater than 1. Furthermore, in the case we've been discussing, the device will presumably always respond to a bulk request immediately (giving the value of a device register). If an interrupt endpoint were available, the device would have been designed not to respond to requests on that endpoint until something interesting had happened, such as serial-in data available. Alan Stern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
