4
\$\begingroup\$

I develop a USB protocol which transfer about 5 Mbits/s from the device to my PC. The mcu is the tm4c123 from TI. The MCU clock is created by a 16 MHZ which is feed into a PPL resulting in a 80 MHZ system frequency.

I want to nail down what is the current bottleneck in my USB protocol because, I am far from the 12 Mbits/s Theoretical (9.5 Mbits/s practical) max rate for USB 2 full-speed. Is it the hardware or the software in a nutshell.

So my question, what is the maximal bitrate you can get on a USB protocol with a 80 Mhz system. I don't need a precise answer, a thumbs rule would certainly do the job.

Here you can find the USB apis from TI, I implement a bulk device.

Here you can find the LibUSBdotNET api used on window side.

\$\endgroup\$
5
  • \$\begingroup\$ Actual Full Speed max is around 9.5 Mbits/s. What usb driver/class are you using? \$\endgroup\$
    – Passerby
    Aug 27, 2015 at 16:24
  • \$\begingroup\$ I will edit that immediatly. I use the TI USB API and I use LibUSBdotNET on window side. \$\endgroup\$
    – MathieuL
    Aug 27, 2015 at 16:25
  • \$\begingroup\$ @Passerby Do you want the links to the APIs documentation into the question? \$\endgroup\$
    – MathieuL
    Aug 27, 2015 at 16:36
  • \$\begingroup\$ I'm sure whomever can actually answer this would find it useful. (oh, and the 9.5 is the practical max speed you can get. 12 is the theoretical max. I fixed that) \$\endgroup\$
    – Passerby
    Aug 27, 2015 at 16:39
  • \$\begingroup\$ How far are you? How many bps do you get through? Is that TI MCU's USB endpoint double buffered, e.g. can you fill it with another packet even when it's sending the first to the PC so that it doesn't NAK the next IN packet, but sends out data immediately? \$\endgroup\$
    – PkP
    Aug 27, 2015 at 18:58

1 Answer 1

4
\$\begingroup\$

Your problem is almost certainly not due to hardware. USB uses fixed bit rates. The bit rate on the line should be 12.000 Mbps +/-0.25% regardless of how much data you transmit. If your bit rate were incorrect, you would not be able to send any data at all, and you'd see error messages in Windows. The TM4C123 has a separate PLL just for the USB module. Here's part of a block diagram from the datasheet:

USB PLL at 480 MHz with a /8 divider on the output

At the protocol level, make sure you're using bulk endpoints to transfer data, and try not to have other devices attached to that controller on the PC side. You can see this in Device Manager's connection view. This will allow a maximum of 19 64-byte bulk packets per frame (millisecond), giving 1216 kilobytes/second of application data. This is the fastest possible real data rate for full-speed USB.

There are two possible software bottlenecks in your system. The first is on the MCU side. If there's no data available when the host (PC) sends an IN packet, the MCU will NAK and the host will try again later. If your MCU is busy doing other things, it may take a long time to get into the USB interrupt. The easiest way to detect this is by using a bus analyzer. It'll cost you several hundred dollars for the hardware, but can save you a lot of headaches in the long run. I like Teledyne-LeCroy's analyzers, personally.

The other possible bottleneck is on the PC side. For some reason, Windows does not like to max out USB bandwidth. Using multiple endpoints with asynchronous transfers running in parallel works well. If you only have one data stream, try requesting much more data than you need when you set up the transfer. Again, a bus analyzer can tell you what's going on. You might also get useful information from a software USB analyzer that runs on the PC, but I've never tried those.

\$\endgroup\$
3
  • \$\begingroup\$ I will look into that more closely this week \$\endgroup\$
    – MathieuL
    Aug 31, 2015 at 11:04
  • 1
    \$\begingroup\$ The FS bit rate is 12.000 Mbits/s, not 12.500. \$\endgroup\$ Nov 1, 2016 at 19:46
  • 1
    \$\begingroup\$ Right you are! Not sure how that error got in. Thanks for the heads-up. \$\endgroup\$
    – Adam Haun
    Nov 1, 2016 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.