Author Topic: uC USB throughput  (Read 2079 times)

0 Members and 1 Guest are viewing this topic.

Offline HarvsTopic starter

  • Super Contributor
  • ***
  • Posts: 1204
  • Country: au
uC USB throughput
« on: February 05, 2013, 01:22:44 am »
Just wondering if those with some practical experience could give me some pointers on what the likely expected throughput of HID (i.e. Interrupt) and Bulk transfers are on a modern 32bit uC are in a practical situation (that is, still leaving enough CPU time to service other tasks.)


I've been learning HID USB on the PIC32 and Windoze C# of late.  At the moment I'm maxing out at about 2kB/s up and down (obviously need to send a report to get one back).  Turn around time is about 30ms from initiating a transfer on the PC to getting a report back. I haven't had the chance to properly benchmark the different sections of code on both the computer and uC but I suspect there's some significant latency on how I'm initiating the transfers under windoze.


I've just been using HID at the moment, due to it's relative simplicity in windows using the default Windows drivers.


I just don't want to spend too much time investigating Windows and the microchip usb library timing if this is about what's to be expected.  I probably just need to move over to Bulk transfers.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27883
  • Country: nl
    • NCT Developments
Re: uC USB throughput
« Reply #1 on: February 05, 2013, 01:32:04 am »
The fastest I got was about 600kbps on a serial port emulation using Y-modem (or X-modem). The problem wasn't the uC but the serial port program and the fact the 'protocol' sends chunks of 128 bytes.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: uC USB throughput
« Reply #2 on: February 05, 2013, 03:53:37 am »
To get high transfer rates you have to construct your application so there is always an outstanding transfer request. In practice you will have to split the USB handling into a separate thread, and be careful to prevent it from being blocked by the main processing thread. I don't know how much overhead the C# environment will incur, but 2KB/s is definitely at the low end.

Offline HarvsTopic starter

  • Super Contributor
  • ***
  • Posts: 1204
  • Country: au
Re: uC USB throughput
« Reply #3 on: February 05, 2013, 04:09:28 am »
Thanks.  At the moment I've just got a timer event firing on the main UI thread, which initiates a transfer and spawns a new async thread with a callback to the UI once the IN report is received.  I imagine that process of initiating a new thread for each report read, and all the marshaling that needs to go on between managed and unmanaged code is killing the throughput.  Also I believe from the "USB Complete" book that the bus latency for an interrupt transfer to actually get a time slice on the bus can be between 1-10ms.


I might setup a simple pin toggling on the uC to indicate the time between a report being received and response sent to see what portion of the turn around time is the uC.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf