On Fri, 15 Apr 2011, Richard Ash wrote: > I have a custom board with an STM32 (arm-based) microcontroller with > built-in USB peripheral, running a modified version of ST's USB Serial > device code which makes it appear as a CDC-ACM class device. It's a > Full Speed (12Mbit) device, not High Speed. As a result, the bulk > in/out endpoints are limited in max packet size to 64 bytes, which > shows up in the lsusb -v output as expected. > > This works great with the Linux CDC-ACM class driver at speeds below ~ > 3 Mbit/second. Above that, the data rate fails to rise as more data is > offered, I think sections of data are being lost. It's also very > sensitive to how fast the application reads the data off the serial > device in user space - my impression is that if there is a gap of any > length between read() calls, then it slows down disproportionately. > > These issues are showing up with both Windows and Linux to some > extent, so I suspect a problem on the ARM, however I'm struggling to > make sense of usbmon to tell me what that problem is. > > On the host side I'm currently testing using Greg's usb-2.6 GIT tree > (2.6.39rc2, pulled on Wednesday as git through corporate LAN doesn't > work) with Johan Hovold's patch set (as sent to this list, with 16v2) > applied. This seems to be the quickest of all the kernels I've tried, > which is good. It's running on an Atom motherboard, so UHCI > controllers. Board is plugged directly into the motherboard USB > socket. > > On the device side the ARM is being fed data as fast as it can take it > (I believe), and should be driving the USB peripheral continuously in > double-buffered mode, allowing continuous sending of data up the USB > link. > > Once it's got going, the usbmon trace looks like this: > > f5146880 554152969 C Bi:4:002:1 0 128 = e6232508 0020e72e 3afcf03a > 03933424 250800b0 e72e3afc f03a030e 83242508 > f5146880 554152997 S Bi:4:002:1 -115 128 < > f5146500 554153005 C Bi:4:002:1 0 128 = 260800f0 e72e3afc f03a0326 > cf4e2608 00d0e72e 3afcf03a 03a21d4f 260800e0 ... > This is where I get confused - my device is apparently being asked for > 128 bytes of data, and replying with 128 bytes, but only 32 bytes end > up in the output. This is for a 64 byte endpoint ... > > The last two replies (with reported lengths of 19 and 23 bytes) do > have 19 and 23 bytes of output data respectively. > > Can anyone explain when a length in usbmon output is not a length, and > separately why a device with 64byte max packet size is doing 128 byte > reads? Read the Documentation/usb/usbmon.txt file. Briefly, usbmon's text interface displays only the first 32 bytes of each transfer. If you want to see the complete data for each transfer, you need to use the binary interface. The easiest way to do that is to run Wireshark, although Pete Zaitcev has written a command-line program to do the same thing: http://people.redhat.com/zaitcev/linux/usbmon-5.4.tar.gz Alan Stern -- 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
