Uno/ATmega16U2 maximum serial throughput

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?

You have the sources so you can check:
hardware/arduino/avr/firmwares/atmegaxxu2

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?

Or until a timer expires.

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.

Okay, I submitted an issue on github. That'll work, right? :wink:

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.