Full Speed Bandwidth

[DanTebbs]

<rage> So I have made the mistake of designing in the new Atmel D21 part. They say in the specs that it is USB 2.0....  but if you look more closely, it is 2.0-full-speed (for whatever THAT'S worth).  I don't get 480 Mb/s, I only get 12!  Those of you considering the D21, watch out! I consider saying USB 2.0 when it is only 12 Mb/s to be false advertising.</rage>

So I have to make the best of it and maximize the 1023 KB / s available in full-speed ISO. As the application is interactive user video, even more critical is the minimum latency.

At this point I have the libusb-win32 stuff working pretty well, and am able to spew packets and have 495 KB / s moving to the host. I have found the culprit for 1/2 bandwidth. For some reason my Atmel core is returning a STATUS_PENDING when the host does the IN-ISO phase. The data is then sent after the _following_ SOF. Do any of you have experience with the Atmel cores and / or have any ideas why it wouldn't be sending within the current frame? I have the buffer queued up and the core primed ready to go before SOF, but that evidently isn't enough.

A perhaps related question. Do I always have to create pipes as OUT/IN pairs? Does the spec require it, or is it an expected convention? Also, is there any advantage to having multiple IN pipes? I've seen references where Bulk mode can sometimes go faster by using multiple pipes. There is a section in Atmel's data sheet about ping-pong which doesn't seem to be related, since I don't need the extra CPU processing time, but...  ?

[Barry Twycross]

USB 2 defines full, low and high, so "USB 2" tells you not a lot about the speed the device operates at. That's separate. It can be annoying, but its something you need to look out for.

The behavior with regard to frames you're seeing is mandated by the spec (5.12.5). Data should be buffered during one frame and latched at the SOF to be sent during the next frame. This allows the host to send the IN wherever it wants in the frame. If it sent the IN immediately following the SOF, you'd have missed it anyway. If you want to sent packets every frame, you'd need to see what facilities to buffer the packet ahead there are, or be very quick to send the next packet after one completes. I send the next Isoc packet from my interrupt path to effect this (with a different device chip).

Pipes do not need to be created in pairs.

Ping-pong is probably what you need to do the packet per frame, it allows you to set up a transaction ahead of the next one completing on the bus.