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 theirtimeslot which cause their timeslot to eat up more of the total bandwidth.

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.

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.

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.

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.

// 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; }}

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.

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.

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 timesbased 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.

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!

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.