> > And why there's that issue I mentioned (reported in Janary by > > Wolfgang Mües) about changing the _length_ of an OUT transfer. > > I've some comments I hope to send out, but can't do so much before > > Wednesday. > > It would work if most of the time the interrupt OUT URB could have a > transfer_length of 0 bytes of data, but I'm not surw which HCDs will > choke on that.
I'd think that it would be good to let INTR-OUT behave exactly like INTR-IN, meaning that both (a) zero byte transfers should work, and (b) if no data is ready, no transfer should happen. I'd expect that (a) would be little/no problem, but (b) is an API model issue. > > > As far as I know the only difference between one-shot out interrupt > > > > (which is a UHCI-ism :) > > But that's only a driver issue. I don't believe OHCI/EHCI in hardware > wouldn't be able to implement oneshot interrupt transfers. I may be > wrong here, though. It's also an API model issue. I think OHCI/EHCI could do them too, but that wouldn't address all the API model issues. Like (b) above, which might be addressed by a usb_modify_urb() style approach to change INTR-OUT transfer sizes. > > Another factor is when the transfer happens ... if your device is > > only able to handle data every 16 msec, you're not doing anyone > > a favor by trying to send/recv it more often, it'll just choke. So use > > interrupt transfers, not bulk transfers. > > If there is such a device, yes. I understand there are. It's a fairly typical approach when dealing with limited processing resources: constrain peak loads. When folk design "real-time" systems they often pre-allocate loads in those ways. It'd be like ISO-OUT, but with better error handling. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
