Pages: 1 [2]   Go Down
Author Topic: Arduino Due - Serial speed?  (Read 11649 times)
0 Members and 1 Guest are viewing this topic.
Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2741
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I only got about 230Kbyte/sec into the Due - but most of the data was lost, only short sections near the beginning and end got copied back. Something to look into.

Running your code, I only get 10.67KHz (~330Kbyte/sec)  (I cross checked with stty -F /dev/ttyACM0 raw ; time cat /dev/ttyACM0 >out )


Are you sure that there are no other devices on the USB sharing it with your device?
Often it can be difficult to tell since there can be internal hubs on the motherboard.

Since USB is time sliced among devices, if there are multiple devices on the bus,
then the available bandwidth drops because even devices with no data to transfer consume bandwidth.
It gets worse if the other devices are slower as the clock slows down for them during their
timeslot which cause their timeslot to eat up more of the total bandwidth.

--- bill
Logged

0
Offline Offline
God Member
*****
Karma: 26
Posts: 625
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I repeated the test using "stty -F /dev/ttyACM0 raw ; time cat /dev/ttyACM0 >out" rather than the python script.  I got 27.2 kHz, or 843 kbytes/sec.

However, if I move my mouse around rapidly while the test is running, the number shown on the multimeter varies wildly between about 21 kHz to 25 kHz.
Logged

Offline Offline
God Member
*****
Karma: 32
Posts: 507
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

(sorry, I was distracted by Project Euler, back now)

I am getting 10.67Khz on my desktop regardless of what I do, whether running your Python script, my command line (on a disk, ramdisk or /dev/null), on a hub, directly into the computer, with and without the keyboard/mouse plugged in. It does go up (to about 67KHz) when nothing is eating the data. On a Raspberry Pi I got about 4KHz, but that platform is known to have USB issues.

I am running an AMD Phenom II X6 1090T / Gigabyte GA-890 (about 2.5 years old). The computer can run RTL-SDR fine at 3Msps (a USB bandwidth of 6Mbytes/s) - so can the Raspberry Pi. OS is Kubuntu 12.10 64 bit.

The 'loopback' sketch is as follows:
Code:
void setup() {
  Serial.begin(115200);
  SerialUSB.begin(115200);
}
void loop() {
  if(Serial.available()){byte c=Serial.read();Serial.write(c);}
  if(SerialUSB.available()){byte c=SerialUSB.read();SerialUSB.write(c);}
}
Using any terminal program that can send a reasonably large file (I used gtkterm), send something to the Due at 115200. When connected to the programming port, it echos back fine. On the native port, only short sections at the beginning and end get echoed.
« Last Edit: November 17, 2012, 05:32:55 pm by stimmer » Logged


Wahiawa, Hawaii
Online Online
God Member
*****
Karma: 31
Posts: 640
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The Native port may take longer to initialize.
You may want to try adding this to your stetup().

Code:
void setup() {
  Serial.begin(115200);
  SerialUSB.begin(115200);
  while (!SerialUSB);
}


Logged

Offline Offline
God Member
*****
Karma: 32
Posts: 507
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The Native port may take longer to initialize.
You may want to try adding this to your stetup().

Code:
void setup() {
  Serial.begin(115200);
  SerialUSB.begin(115200);
  while (!SerialUSB);
}


Thanks, I have added the while line now. However it has made no difference - it still loses data as before. The code works for individual characters - if you type in the terminal window your typing is echoed back. Also, if I set gtkterm to add 20ms of delay after each line, less data gets lost (most lines get echoed mostly correct, but some characters go missing). And the data is lost - I have not seen any data corruption, lines are echoed back correctly or with chunks missing but never garbled data.
Logged


Wahiawa, Hawaii
Online Online
God Member
*****
Karma: 31
Posts: 640
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I was looking thru the \arduino-1.5.1r2\hardware\arduino\sam\cores\arduino\USB\CDC.cpp code and notice that the ring buffering is being set to a different size.  It is initializing the buffer size to 512 but then only is using 64 bytes (defined elsewhere SERIAL_BUFFER_SIZE is 64).  I don't know if this is intentional or not.

Code:
#define CDC_SERIAL_BUFFER_SIZE  512

...

struct ring_buffer
{
        uint8_t buffer[CDC_SERIAL_BUFFER_SIZE];
        volatile uint32_t head;
        volatile uint32_t tail;
};

But later on in the code it has a different size.

Code:
void Serial_::accept(void)
{
        ring_buffer *buffer = &cdc_rx_buffer;
        uint32_t c = USBD_Recv(CDC_RX);
        uint32_t i = (uint32_t)(buffer->head+1) % SERIAL_BUFFER_SIZE;

        // if we should be storing the received character into the location
        // just before the tail (meaning that the head would advance to the
        // current location of the tail), we're about to overflow the buffer
        // and so we don't write the character or advance the head.
        if (i != buffer->tail) {
                buffer->buffer[buffer->head] = c;
                buffer->head = i;
        }
}

int Serial_::available(void)
{
        ring_buffer *buffer = &cdc_rx_buffer;
        return (unsigned int)(SERIAL_BUFFER_SIZE + buffer->head - buffer->tail) % SERIAL_BUFFER_SIZE;
}


Code:
int Serial_::read(void)
{
        ring_buffer *buffer = &cdc_rx_buffer;

        // if the head isn't ahead of the tail, we don't have any characters
        if (buffer->head == buffer->tail)
        {
                return -1;
        }
        else
        {
                unsigned char c = buffer->buffer[buffer->tail];
                buffer->tail = (unsigned int)(buffer->tail + 1) % SERIAL_BUFFER_SIZE;
                return c;
        }
}
Logged

Offline Offline
God Member
*****
Karma: 32
Posts: 507
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Changing SERIAL_BUFFER_SIZE to CDC_SERIAL_BUFFER_SIZE in CDC.cpp has improved things a little - now when the file is sent with a 1ms end-of-line delay it appears to be received correctly. Without the delay though the file is still mostly lost.

Looking at the code, acccept() appears to silently drop characters when the buffer is full - maybe that is where the data is being lost.
Logged


0
Offline Offline
Newbie
*
Karma: 0
Posts: 23
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

how it works with handshaking?
xon/xoff is possible??
Which settings in Putty?
Logged

France
Offline Offline
Sr. Member
****
Karma: 0
Posts: 262
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

On some other recent threads, it is clearly observed that the Serial USB link wether HW or SW (low level or high level) have serious speed issue. One way to perceive this, there are many other methods and practical tests, is by observing the same *.INO project loaded on mega takes almost no time to USB download but HUGE time to download on DUE.
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 23
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

OK,
but what have it to do with the handshaking?
Logged

0
Offline Offline
God Member
*****
Karma: 26
Posts: 625
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm curious about the upload speed issue.  Could you link to the specific threads or messages?
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2741
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

On some other recent threads, it is clearly observed that the Serial USB link wether HW or SW (low level or high level) have serious speed issue. One way to perceive this, there are many other methods and practical tests, is by observing the same *.INO project loaded on mega takes almost no time to USB download but HUGE time to download on DUE.
Comparing upload times for the same sketch isn't particularly a good method to compare transfer rates.
It might be that the same sketch generates much larger code on the DUE than on the Mega.
To be fair when comparing upload times,
you need to look at the sizes of the .hex files and adjust the times
based on the ratios of their sizes.
i.e. if the DUE takes twice as long to upload but the .hex is twice is large,
then the upload speed is actually the same.

--- bill
Logged

France
Offline Offline
Sr. Member
****
Karma: 0
Posts: 262
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

well, it is not just doubling download time, it takes 10 times more so I doubt the same code takes 10 times size more on DUE than on MEGA.
Logged

0
Offline Offline
God Member
*****
Karma: 26
Posts: 625
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Could you be more specific about this 10X loading time?  Maybe with links to these other topics?

Has anyone actually measured the times?  Are the measurements on each operating system, or only one specific system?  Does it happen on multiple computers, or is all this from only 1 machine?  Is this with the programming port or native port?

So far, I'm only used the beta version of Due (which had only the native port), and only on Linux.  I loaded many programs during the beta test period, where I discovered and reported several bugs, with Christian fixed before release.  Much of that testing was before the auto-reset was working, so I do recall the cumbersome 3-button sequence, but the loading speed was quite reasonable.  I did not measure the specific programming speed, but if it were significantly slower than Uno, I certainly would have noticed.  (upload speed is something I really do care about.... I put a huge amount of work into Teensy 3.0 for best possible upload speed)

There.  I've specified the hardware, port, software version (early betas), and which operating system I used.  It's not hard.  You can do this too, rather than simply saying it's 10X slower with no specific facts to back up your claim!
« Last Edit: December 14, 2012, 06:03:23 am by Paul Stoffregen » Logged

France
Offline Offline
Sr. Member
****
Karma: 0
Posts: 262
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello Paul,

Again I insist, the download time is 10x

Here are some threads dealing with I think a more global issue related to Programmer USB port, in my case, I use MacBook Air where my code has been running for years on mega, it is Serial protocol using HDLC on to of USB.

http://arduino.cc/forum/index.php/topic,134847
http://arduino.cc/forum/index.php/topic,135011
http://arduino.cc/forum/index.php/topic,135095

P.S. My arduino DUE is not a beta, just bought in belgium recently at antratek company

Albert
« Last Edit: December 14, 2012, 06:26:05 am by selfonlypath » Logged

Pages: 1 [2]   Go Up
Jump to: