USB Serial Receive Speed Improvement

My 2 cents.
Given the abilities of modern COmputers and Microcontrollers It would not make sense for anything related to HID be "the fastest". HID stands for Human Interface Device. Humans are not really fast by any means.

The reason for these guaranteed transfer rates in HID modes is likely that there is a guaranteed response time to human interactions. If you push the mouse, you want for the cursor to move instantly (as perceived by a slow human ;-) ) and not experience lag until the the 4k video has been loaded from the USB Harddrive.
 
I published all this benchmark stuff on the website today.

http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html

I was looking at the website because teensy is mentioned often in #arduino & #43oh (msp430) chatrooms and I noticed in the bottom of the page you tried the benchmarks with the Launchpad LM4F120 (Stellaris) and it didn't work out well. If you haven't been made aware, the msp430 launchpad now has a usb HID/MSC/CDC model and Energia seems to have support now for some type of usb serial with msp430s https://github.com/energia/Energia/commit/92cc703ee3d4c441699e68bbf0ccfda2eb9ce60a , which might be a better one to compare with as it is more popular, also the Tiva C Launchpad(the rebranded and very slightly improved version of the stellaris) has come out with USB On-The-Go so maybe better usb support will be coming in future releases of Energia. Perhaps posting a ticket about the needed feature from usb serial @ https://github.com/energia/Energia/issues might help ensure it is on the checklist in case it was overlooked.
 
Looks like Energia is improving.

Has anyone tried to actually run the benchmark? Since their code is a library, the benchmark would need to be modified slightly to #include the header and create the USBSerial object, but other than that minor detail, the benchmark ought to be able to run.

I'm curious to hear how Energia/MSP430 performs. Right now, probably not curious enough to actually buy that new board and go to the trouble of running it myself. But maybe when I have more time.....

Edit: I did look at their source code just now, but only briefly. They've definitely got some work in there for performance, like DMA-based memcpy. They have interrupt based events, but it seems none are currently used for data movement. I didn't see any optimization on the Arduino API layer. Stream readBytes() just calls available() and read() for each byte. Achieving good performance on this benchmark requires careful design throughout the entire stack, from the hardware all the way up to the Arduino API. I hope someone will run the benchmark and report the results....
 
Last edited:
Here are some recent runs of your benchmark. Host is Ubuntu 12.04.

Code:
teensy 3.0 read: Average bytes per second = 685260
       readbytes:  Average bytes per second = 1150279

teensy 3.1 read:  Average bytes per second = 1150390
        readbytes:  Average bytes per second = 1150244

DUE read:    Average bytes per second = 133103
 readbytes:   Average bytes per second = 123476

maple read: Average bytes per second = 214973

On 3.1 standard read is just as fast as ReadBytes().

teensy 1.0.5/r18, DUE 1.5.4, maple v0.12
 
Last edited:
Hi Guys,
I've read all this post, tested serial with the source code provided. I'm on Teensy 3.1 and with code provided by TeensuDuino environement (not changed with the file provided by Paul at the begining of the post) and the exe file from host. Like that I'm approx 1000 kbytes/sec which is fine.
I'm not a specialist, but does this mean that if I need to transfert bulk data (says about 64Kbytes) at best possible speed I must use USB Serial instead USB HID ?
At first time I thought the best perf should be done by USB HID but it seems I was wrong since USB HID perf is about 1000 * 64 bytes (per second) so 64Kbytes/sec, far less than 900 kbytes/sec with USB serial.
Did I correctly understood ?
Thanks for your help.
 
Charly86 - check out my question earlier in this thread and the subsequent posts. I think it will go a long way to answering your question.
 
anderstod2
Thank's for your quick reply.
For sure I did this, but time passed, and was dreaming someone had a short answer :p
I also throw a eye in code of usb_api.cpp just in case I wanted to allow more than 64 bytes buffer (but seems a very bad idea ;-)

// write bytes from the FIFO
#if (RAWHID_TX_SIZE >= 64)
UEDATX = *buffer++;
#endif
#if (RAWHID_TX_SIZE >= 63)
UEDATX = *buffer++;
#endif
#if (RAWHID_TX_SIZE >= 62)
UEDATX = *buffer++;
#endif
#if (RAWHID_TX_SIZE >= 61)
UEDATX = *buffer++;
#endif
#if (RAWHID_TX_SIZE >= 60)
UEDATX = *buffer++;
#endif
#if (RAWHID_TX_SIZE >= 59)
UEDATX = *buffer++;
#endif

... oup'ssss no way for me to have 8kbytes buffer, too much lines to add ;-)

So as My teensy will use USB only for transfer from host, and will be the only one transfering, I'm gona use USB Serial, it's fast enought for me, no need to check 64 bytes chunk and reassembly, So I will keep things simple (at least for this part)

I also wanted to thank's Paul for his brilliant job on teensy products.
 
At first time I thought the best perf should be done by USB HID but it seems I was wrong since USB HID perf is about 1000 * 64 bytes (per second) so 64Kbytes/sec, far less than 900 kbytes/sec with USB serial.

That's correct. HID is limited in bandwidth.


anderstod2
I also throw a eye in code of usb_api.cpp

That code is for Teensy 2.0. It's also the code that transmits from Teensy to the PC. The benchmarks mentioned above are in the other direction, from PC to the Teensy.

just in case I wanted to allow more than 64 bytes buffer (but seems a very bad idea ;-)

Since the USB packets are limited to 64 bytes, larger buffers will have little benefit. But I wouldn't call bigger buffers a "very bad idea", just an idea without extra benefit beyond a pretty small size.


If you're using Teensy 3.1, the CPU is fast and the USB stack is very efficient. Even very simple 1-byte-at-a-time code works pretty well. If you use even small buffers with Serial.write() and Serial.readBytes(), you'll have lots of extra CPU time.
 
Back
Top