Hi All,
Id like to knew the maximum serial communication speed via the usb ports for the arduino DUE board. I have downloaded the datasheet for the AT91SAM and found that description :- USB 2.0 Device/Mini Host: 480 Mbps, 4-kbyte FIFO, up to 10 bidirectional Endpoints, dedicated DMA. So im wondering how can i use the USB communication in the arduino DUE with this speed ! ( 480Mbps ). Is the Native USB port able to reach this speed ! or both USB ports ( native and programmer ) are not able to reach this speed !
I havent bought the DUE board yet but im planing to use it for an autopilot project so im exploring if it will be good or not for me. To be more obvious, The Arduino DUE board will work as a ( hub ) for all sensors and motors, it will get tha data from all sensors and send it very fast to a Beagle board which will do all the control algorithms very fast ( faster than the DUE ) and then send the outputs to the DUE and finally the DUE controls the motors. As you know this loop must be processed with at least 200Hz frequency, so the due must receive sensors data, send it using USB, receive the output and control the motors 200 times per second. thats why i need the serial communication to be very fast enough to make the loop processed at 200Hz.
I hope any one can help me determining the maximum speed for communication using the USB in this board.
I was using a DUE on a project last spring and I went through great pains to try and get it to work at USB 2.0 speeds but was not successful. I posted here as well to try and get help but at the time it seemed as though nobody else had been able to send and receive data at these speeds either. The native port is connected directly to the SAM chip, so it is the only one that could possibly run at these speeds. There may be better support for these speeds now, but a few months ago I was not able to utilize the full speed communication.
I recently tested with 64 bit Linux, measuring several megabytes/sec in the Due-to-PC direction, and about 128 kbytes/sec in the PC-to-Due direction. If you're sending from Due to your PC, it's about 10% of the theoretical USB 480 Mbit/sec speed (with protocol overhead), which I believe is the fastest Arduino compatible board on the market today.
Sending in the opposite direction isn't nearly as fast.
Here's a page I published with the benchmark results for PC-to-board testing. The complete code is available, so you can run the benchmark yourself. There's even a pre-compiled Windows utility, since building the PC-side code on Windows isn't as easy as Linux and Mac.
An important point is the speed can depend heavily on how you do things on the PC side, especially regarding transfer sizes. You might think a 64 bit, many-GHz, multi-core CPU with gigabytes of high bandwidth RAM could not possibly be the limiting factor, but sadly the design of the PC side software can have a pretty dramatic impact on the speed.
Another thing to consider is your communication protocol. Using USB, you'll have a difficult but not impossible task to sustain a 200 Hz update rate if your approach requires sending data to the Beaglebone, doing computation, and then sending control data back to Due.
That sort of receive sensor data, do computation, send control message approach is ALWAYS SLOW.
USB host controllers allocate bandwidth on 1 ms frames. Typically you'll see 1 ms latency with USB. Since you're looking for a 5 ms cycle, maybe that's not too bad? But when you throw non-realtime operating system scheduling (Linux) in the mix, things can get worse... much worse.
If you design your Linux application with 2 thread or processes, or 2 handlers within within 1 program (eg, using select, poll or async i/o), you can do much better. But this requires more sophisticated design. Usually you need to do something like have the sensors continuously measuring and transmitting, never waiting for the control messages, and likewise have the control side send messages on its own schedule, with the receiving code on the Arduino side regularly checking Serial.available(), but never waiting when Serial.available() returns zero.
Perhaps your control algorithm requires so much CPU time that it absolutely can't run on Due? If that's true, then I suppose you have no choice? But if you can optimize your code to run on Due, I've confident you'll achieve much faster response speed than a 2-board system that will suffer so much inefficiency from all the USB I/O.
Hi Paul,
To make all thing clear to you, Im trying to put a Kinect on the Quadcopter to make 3D modeling via Quadcopter. So i need the bealgeboard to be connected to the Kinect through USB. But the beagle board cant be accepted as an autopilot board because of alot of problems, for example i need 4 PWM pins to control the 4 motors while beagle has only 3 pins, also its not easy to use i2c and other features like micro-controllers. Thatswhy i decided to use another simple and fast micro-controller board to control 4 motors and get all sensors data using i2c. I chooses the DUE board because its running on 84MHz SAM micro-controller and has w fast USB interface. But i wanted to make sure of this theoretical speed and you have cleared this point to me.
The procedure will be like this:-
Kinect is connected to beagleboard using USB ( linux OS ).
Due is connected to the beagleboard as well using USB.
All sensors and motors are connected to the DUE.
USB WIFI module is connected to beagle as well.
All of these are connected to beagle using a USB Hub, as beagle board only has 1 usb port available.
The DUE gets data from IMU using i2c.
The Due sends these data to the beagle.
Beagle board do complex calculations like DCM and PID using the data received from the DUE on a 200 Hz rate.
Beagle board receive the 3D data from the Kinect and get the distance from any obstacles and uses algorithms to make the Quadcopter move autonomously.
The beagle board also sends the Kinect data using WIFI to a PC which process this data to create the 3D map of the place.
in the same time, the Due receives the automatic control signals from the beagleboard, and the DUE controls motors depending on these signals, sothat the Quad moves autonomously depending on the beagle commands.
The final output is a 3D mapping using kinect via autonomous Quadcopter. The Quad creates a 3D map for the whole building by automatically exploring it.
And i don`t think that the DUE can run complex algorithms like DCM and run i2c, serial ... etc at 200Hz rate.