I cannot seem to find any discussion of this so, here is a new topic. Please point me to an older one if it exists.
There seems to be a limitation on maximum throughput with serial data output from the Uno to USB of around 47k chars/second or so. Running the same code on an older Duemilanova (which uses FTDI chip) does not have this problem. Here are the specifics:
Firmware uses Serial class to set rate to 1M baud. From there on however, data is output via direct interaction with UDR0 and UDRE0 -- no more calls to Serial class are made. As such, I am 100% certain that no data is being lost or corrupted in the ATmega328.
At character rates up to about 47k chars/sec there's no problem, but exceeding that, I start to see characters being dropped.
I think the fact that this works fine on the Due means that there's a limit to how fast the firmware in the 16U2 can transfer data from its serial input to USB host.
Is this a known limitation? Perhaps there's a firmware bug in the 16U2?
Well, I was hoping someone might know the answer and save me the trouble. That said, I had a look at the code and can see a possible problem.
The main loop waits until the buffer for serial data from the ATmega328 is "nearly full" (i.e. 96 bytes), then enters a loop writing it to the USB output data register -- with zero checking to see if the data register can accept the data.
This is in the LUFA code, in CDC.c and Endpoint_AVR8.h. I suggerst that your average fool (I am a fool too, but not average) would be hard pressed to dig into the issue at this level. I was only able to find this because I've messed around with LUFA before.
Anyway, can you have a look at that code and see if I'm reading it correctly?
Right, but that timer seems to be for the purpose of flushing the output so probably is not relevant...?
So, if this really is a problem, it's obvious that it is rarely encountered or it would have been fixed. What are the odds I can report this and get it fixed? I really loathe the idea of having to install a custom bootloader in the Unos I have. Then I have to keep track of which is which, etc.
And there's always a chance it cannot be made to work anyway.
I would probably opt to replace the Unos with some SparkFun Red Boards with the FTDI chip instead of screwing around with the bootloader.
Here's a final post on this topic. The whole speed limit issue is a bit more complicated that it first appeared. For example, I get a faster uncorrupted data stream using a custom reader app (written in C++ on Windows) than is possible with either puTTY or the Arduino serial monitor.
That said, and while I don't know why or how, it has become clear that boards using the FTDI chip outperform boards with the ATmega16U2 USB/serial bridge.
The bottom line is that if you want the fastest serial data transfer over USB from Arduino to USB host, opt for a board using the FTDI chip -- stay away from boards using the ATmega16U2 USB interface.
