On Mon, 14 Feb 2005, Uwe Bonnes wrote: > Alan, > > thanks for you time. We are close now, but still the main answer is > touched NYET :-)
Making progress, anyway... :-) > The bitbanging happens with controlmessages sent via libusb, like: > usb_control_msg(ftdi->usb_dev, 0xC0, 0x0C, 0, ftdi->index, (char *)&usb_val, > 1, ftdi->usb_read_timeout) > > With these control messages, the pins effectivly change state at 125 /1000 > us steps. The scope clearly tells that. So it seems that control messages > are not queued, at least not sent that way via libusb/usbdevfs. That's right. It is possible to submit them and have them queued, by using USBDEVFS_SUBMITURB (asynchronous submission). > But my original question: Why does pin state changes caused by sending of > control messages happen at 1000 us intervals when the USB2.0 full speed > device is connected direct to the PC, while it happens 8 times faster at 125 > us intervalls, when a USB 2.0 hub is connected in between PC and device. As I said before, since you aren't queuing URBs, your program submits one when it is notified that the previous one has completed. Those notifications occur at a frame boundary (every 1 ms) for a full-speed controller and at a microframe boundary (every 125 us) for a high-speed controller. Since the URBs get sent every 1 ms or 125 us, that's how often you see the pin change state. When your device is connected directly to the computer, the USB controller hardware on the computer recognizes that the device runs at full speed and hooks it up to a full-speed controller. When your device is connected through a high-speed hub it uses the same controller as the hub, which will be a high-speed controller (since the hub is high speed). So the explanation is that in one case your device is using a full-speed controller and in the other case it's using a high-speed controller. > I think this is a missbehaviour of our USB stack... No, that's how it's supposed to work. The design is an engineering compromise. USB host controllers only interrupt at frame boundaries, not whenever a transfer is completed. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
