David Brownell wrote: > > but I guess it's one of the transfer types most likely to regress since > > many gadgets don't require such transfers. > > Gadget zero, for testing; and the RNDIS/Ethernet link. > Most AVR32AP boards have Real Ethernet links. :) Yeah, things like mass storage and CDC ACM tend to be more interesting. > > I've been doing a bit of bare-metal USB programming on UC3 chips > > lately...I guess I should take a look and see if anything looks stupid > > in the light of that additional experience... > > Those have the full-speed OTG controller that some AVR8 > chips have, yes? Yes, but they've got mostly the same logic under the hood that AP7000 has, except for high-speed support. > There might be something. But these > two PING/NAK issues couldn't show up at full speed. >From a programming standpoint, a PING/NAK loop at high speed isn't much different from an OUT/NAK loop at full speed. The underlying problem with both is usually that the driver isn't reading data from the FIFO as it should, so the device controller is NAKing while waiting for some available buffer space to show up. The ACK/NAK/NYET logic is just a function of the FIFO state; the driver doesn't have much control over it (other than indirectly through manipulating the FIFO.) Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
