If I could get the one-microframe period to work with interrupts that would get me very close to my original goal of 10Mbyte throughput.
See the spec for wMaxPacketSize ... it makes more sense
in hex, since you're interpreting the high bandwidth
multiplier bitfield incorrectly.
Oh yes, I see what you mean here. The wMaxPacketSize element in the structure is not really a byte count but is an exact duplicate of the element in the endpoint descriptor I set up in the FX2. That includes the high bandwidth bits. That's what I get for blindly following the usb-skeleton.c code. It just assumes the high bandwidth bits won't be set.
That's because nobody's needed the high bandwidth support
yet. Do you need that to work?
I'd love high bandwidth as well as 1-microframe scheduling. Then I could support both the current generation of our camera and the next.
This is a variant of a known restriction in the periodic scheduling, that's been there for ages. Though ENOMEM is the wrong thing to report. (The restriction is that only one interrupt endpoint per frame can be scheduled. It's not been a restriction many people have noticed ...
I was thinking of setting up the FX2 to run all four of its large endpoints in parallel. It seems this won't work to improve throughput, if I understand correctly what you're saying. But perhaps it would work for bulk transfers?
Thanks for your assistance.
Richard
-- Richard Stover email: [EMAIL PROTECTED] Detector Development Laboratory http://www.ccd.ucolick.org UCO/Lick Observatory Natural Sciences Bldg. 2, Room 160 University of California Santa Cruz, CA 95064 USA
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
