yes, to host PC via USB.after some experimenting it seems like I can transmit with Serial.begin(250000);I tried increasing it to 251000 but failed to receive any data.MEGA can accept practically any number ( I tried up to 2048000), but real transmission speed is like 40% less then maximum speed of DUE

As I said above, MEGA accepts 2M, but it does not affect communication speed. Speed stopes raising ~ after 250000.

There are two things at play...

1. With the new interrupt driven Serial, the sustained data rate will be lower (overhead of the interrupt service routine) than with the old blocking Serial.

2. The processor is only running at 16 MHz. If your program is doing anything more than pumping data out the serial port it is unlikely you will get a sustained data rate much past 250K. The highest sustained data rate I'm seeing is 463611 bits per second and the sketch does nothing but pump data.

Quote

DUE with speed>250000 transmits garbage.

Is an indication that there may be a problem with Serial on the Due. I suggest you post more details so others can try to reproduce what you are seeing.

If you increase speed to, say, 252000 or even 251000, Putty shows garbadge.I played for couple hours trying to find any combination of Arduino/terminal program speed settings >250000 which does not produce garbage, and I failed.With Arduino MEGA same code generates correct transmission up to 2048000 May be even with bigger numbers, but I feel it does not make sense to go further, because it is not the actual transmission speed. It is just some correct handling of parameters, like, if speed>2500000 then speed=250000.

It's worth mentioning the speed changes dramatically depending on the software receiving the data. The Arduino Serial Monitor gives much lower speeds. Even the seyon terminal emulator gave speeds slower than the python script.

At least with Linux, after a program closes the serial port and the kernel drivers' buffers are filled, data transmission stops. In that case, Serial.print() returns very quickly and a much higher frequency appears on pin 2. If anyone tries to repeat this test, please be sure to measure the frequency while the python script or some other program is actually receiving the data.

Yes, your point is valid, the theoretical speed is not limited to 1216 kbytes/sec. In fact, I just looked at the USB 2.0 spec. Table 5-10 on page 55 (83rd page of the PDF) says the theoretical maximum (with packet overhead, but not bit stuffing overhead) is 53.248 Mbyte/sec.

But in practice, the actual speed is 849 kbytes/sec, at least with this particular test. I'm pretty sure the test is not limiting Due's speed, since Teensy 3.0 is able to run 28% faster on the same test. Teensy 3.0 is only a 12 Mbit/sec device, so it does face the 1216 upper limit.

I believe Due could run much faster, with a *LOT* of programming work. The SAM3X datasheet says the chip supports both software polled FIFO and DMA. I've looked briefly at Due's USB code, which seems to be Atmel's reference code. It appears to be using the FIFO approach. The Teensy 3.0 code is using DMA, because Freescale's chip does not support a polled FIFO interface. Maybe someone from Atmel will take notice of the actual speed their top-end chip achieves relative to another silicon vendor's low-end chip... and dedicate some time to improving their reference software to use DMA?

Then again, 849 kbytes/sec is pretty speedy, in the context of most projects where Arduino is used.

Wow, that's quite a difference. I am running on a very fast desktop machine (an i7-3930k) and I'm using the Due beta hardware, since the release Dues I purchased on still on backorder. Still, I wouldn't expect such a huge difference.

Edit: I noticed you're redirecting the data to "out". Sending to /dev/null might be a better test? On most modern PCs, I wouldn't expect this to make much difference. But in the early days of testing Teensy 2.0, I saw a laptop where attempting disk I/O in the same test as USB caused a significant slowdown. The same test on a desktop machine (both a few years ago) showed nearly the same speed with and without disk I/O.

If you post a complete benchmark program and specific steps, I'll run it here and share the results.

Bytes are written into USB packet buffers (on Due, using a hardware register that accesses the buffer in a fifo manner). When the software and drivers on the PC are ready to accept data, the USB host controller on the PC schedules USB bandwidth and sends tokens when the device is allowed to transfer data. If data is waiting in a packet buffer, Due's hardware automatically transfers the data at the full USB speed. The net transfer rate depends on how often the PC software and drivers request data, when the computer's USB host controller chip schedules USB bandwidth (other USB devices are the main factor) and how frequently there is a packet buffer ready to transmit when the host controller sends the token allowing the transfer.

That is absolutely unlike hardware serial used on the programming port, where a fixed baud rate is used and it's up to the receiver to respond to the incoming data quickly enough (or implement additional handshaking lines to cause the transmitter to pause).

It makes no sense, in the context of the native port, to say "allows receiver recognize characters correctly". The speed is fixed at the native USB bit rate, 480 Mbit/sec for Due, but data is only transmitted when all 3 components (receiving software, host controller chip, and Due's packet buffers) are ready to transfer data.

Quote

I'd suggest to use Putty as reference receiving terminal program.

Displaying the data in a scrolling window is a poor benchmark for native port. The rate putty requests data will depend on many complex factors of the windowing system and graphic card driver.

Quote

the native one accepts any speed settings (as was noticed above, it just ignores it) but real data transfer is very slow, like, few characters per second.

Your measurement of a few characters per second differs tremendously from my measurement of 894 kbytes/sec. I specified exactly how I tested, with complete code for both the Due and PC side. If you would do the same, perhaps someone can try reproducing your test results?