> Are you only submitting URBs with 64 byte packets? If
> so, that's likely your problem. Bigger buffers work better
> for bulk, when you want througput. Try 2KB, for example.
> That'll max out one frame (19 packets) and most of the
> next (13 packets), with space for other USB transfers.
Ah,
> Problem-
> The framerate appears to be stuck at 1ms between frames.
That's part of the USB spec ... I think you mean "between requests".
One URB per request.
If your driver doesn't use URB queueing, the host controllers are only
going to get (at best) one request per frame, since host control
> If you have a SA1110, there is a standard "usb device" driver that
> works with the usbnet driver, and a cdc ethernet driver that will
> soon work with the CDCEther driver. Why not just use those?
It's a bootloader, and not SA1110 :). (ARM920T from Samsung) Though
I do plan on porting that
On Fri, 1 Mar 2002 14:18, Shane Nay wrote:
> Situation-
> I have a ARM board that I wrote a small USB stack for so I could
> download my updates quicker. I wrote a linux driver to talk to that
> USB stack and download my code basically.
If you have a SA1110, there is a standard "usb device" drive
Situation-
I have a ARM board that I wrote a small USB stack for so I could
download my updates quicker. I wrote a linux driver to talk to that
USB stack and download my code basically.
Problem-
The framerate appears to be stuck at 1ms between frames. So, if I
queue up a single bulk urb at a
