Hello all, I have an application I'm testing that uses bi-directional communication on the native USB port of the Due. It sends 32 to 64 byte packets back and forth at 2400 times per second both directions. I don't have any problems going from the Due to the pc at even 4800 times per second. However, as soon as I start sending any data even at slower speeds like 1200 times per second from the PC to the Due while the Due is also sending at any speed, I get massive errors, data loss, and after about 5 seconds or so it will even hang the Due and it must be reset to recover. Here are a few things I've already tried:

- Making sure data being sent/received is isolated so I'm not running into any concurrency issues (although I'm not sure how that would be a problem anyway since this thing doesn't really appear to be multi-threaded)

- Currently output from the Due is on a timer (TC1, ch2 so TC5_Handler) but I've tried just processing it in the main loop "as fast as it can" as well but I see the same behavior.

- I tried synchronizing the I/O so that the Due doesn't send it get's the response from the PC and the PC doesn't send until it gets a response from the Due. That solves the problems, makes it stable and run fine, but us WAAAY too slow at around 250 packets per second.

- I have standard packet sizes. I've tried both 32 byte and 64 byte packets and I get the exact same results.

I'm about ready to give using SerialUSB as the read line and Serial as the write line a try to see if I can make that work. Ugly as heck but I figured it was worth a try. Can anyone help me understand why as soon as I try to go bi-directional with the USB I/O everything goes to crap?

Ok. I'm fine with ugly code and having to change some names of stuff. Teensy does indeed have native USB, which is part of the reason I'd like to try running your benchmark. Like Leonardo's native USB, it's called "Serial", not "SerialUSB". That's pretty easy to change.

It does take a LOT of time to do good benchmarks, make the code nice to use, and write up the results well. I've done a lot of benchmarks, but published very few so far because of how much work it is to go from ugly but useful info to something worth of publishing to a wide audience.

Don't worry... I'm only interested to run it and see how simultaneously data flow, perhaps in ways I've not anticipated, actually works. So ugly code is fine, really.

Linux is not an issue. I use all 3 systems and Ubuntu is my primary desktop.

But if you're got a lot of complex stuff going on with timers, perhaps this isn't a good benchmark that shows Due's actual native USB performance? Maybe the problem is unrelated to the USB speed at all. Complicated timing issues are pretty common with programs that directly manipulate the timers and other hardware.

If you post some code, I'll give it a try here on a couple other boards. I have a collection of every Arduino compatible board which currently supports native USB: Arduino Leonardo & Due, every Teensy, Maple, and Fubarino Mini.

It could at least be a sanity check. But until you actually post something, nobody could even begin to guess why you're experiencing these speed issues.

13 seconds is exactly as expected. The programming port is a hardware serial port that communicates to the 16u2 chip. You set the baud rate to 115200, which gives 11.52 kbytes/sec. Sending 153600 bytes at that speed should take 13.3 seconds.

I believe the problems you've been seeing are caused by incorrect baud rate settings on the programming port.

Using "stty" to set the baud rate is not reliable. Here is a copy of your code using the proper termios functions to set the baud rate after the port is open. This version always receives the 2400 32-byte packets in 6 or 7 seconds.

I really don't think I can keep following this thread. You posted code, I tried to help. You could have posted code demonstrating the actual bidirectional problem, but didn't. I just can't keep wasting time on this.

I thought it might have been caused by binary data, but reading this thread, I see that I also was doing bidirectional comms. The exact same sketch works 100% if I switch to the Programming port, at 57600 baud. It seems the SerialUSB on the Due, and the Serial on the Leonardo, are too flaky to be used for real life two way comms.

My sketch is a biggish system, and uses MavLink to third party software, so its hard to extract a simple test. Exedor - did you get a stripped down test written?

Does just sending data TO the PC using SerialUSB.print at speeds 115200 or higher work flawlessly?

It did work when I tested several months ago. The speed was in the hundreds of kbytes/sec range, which is dramatically faster than 11 kbytes/sec, but far less than Due's hardware ought to be capable of providing.

Maybe I ought to re-run these tests? Now I have a nice collection of all the Arduino compatible boards with native USB (each with their own USB stacks that have vastly different performance): Arduino Due & Leonardo, Maple, Teensy 2.0 & 3.0, and Fubarino Mini.

EDIT: I had hoped to adapt the OP's test into a bidirectional bandwidth benchmark..... but after many messages he never actually posted even a test program that demonstrated the problem, and has since deleted almost all his prior writings.

I just dug out an old transmit benchmark program, ported it to Arduino and ran it.

Using Arduino 1.5.4, Due's speed has improved about 10X since I tested many months ago. On my Linux machine, I measured 4700.86 kbyte/sec transmit-only speed from Arduino Due. That's 408 times faster than using hardware serial at 115200 baud.

Here's the benchmark test, if you'd like to try running it on your own system:

Quote

// USB Serial Transmit Bandwidth Test// Written by Paul Stoffregen, paul@pjrc.com// This benchmark code is in the public domain.//// Within 5 seconds of opening the port, this program// will send a message as rapidly as possible, for 10 seconds.//// To run this benchmark test, use serial_read.exe (Windows) or// serial_listen (Mac, Linux) program can read the data efficiently// without saving it.// http://www.pjrc.com/teensy/serial_listen.c// http://www.pjrc.com/teensy/serial_read.c// http://www.pjrc.com/teensy/serial_read.exe//// You can also run a terminal emulator and select the option// to capture all text to a file. However, some terminal emulators// may limit the speed, depending upon how they update the screen// and how efficiently their code processes the imcoming data. The// Arduino Serial Monitor is particularly slow. Only use it to// verify this sketch works. For actual benchmarks, use the// efficient receive tests above.//// Full disclosure: Paul is the author of Teensyduino. //// Results can vary depending on the number of other USB devices// connected. For fastest results, disconnect all others.