Is the Arduino's serial over USB protocol lossy (like UDP), or lossless (like TCP)? I have examined the USB specification and it appears to support at least four major operational modes: Control Transfers, Bulk Data Transfers, Interrupt Data Transfers, and Isochronous Data Transfers. All of these modes except Isochronous appear to be lossless, though I could be misunderstanding. Which of these four modes does the Arduino serial over USB implementation use? The target hardware is the Arduino Due, connected to a PC running Windows 7. The reason I ask is because if serial over USB is in fact lossless, then CRCs, retry loops, etc. at the application level would be redundant or even counterproductive.
While the communications between the PC and the USB chip use protocol that can in some circumstances correct for errors, then the serial data to the USB chip does not include anything that would correct errors.
Like any transfer of data it can be subject to errors.
Grumpy_Mike:
While the communications between the PC and the USB chip use protocol that can in some circumstances correct for errors, then the serial data to the USB chip does not include anything that would correct errors.
Like any transfer of data it can be subject to errors.
Thanks for your reply. But I'm still not with you sir (As Mandrake says in "Dr. Strangelove".) Arduino's serial over USB behaves like an ordinary COM port, but it's an emulation. AFAIK there's no actual serial hardware involved, RS-232 or otherwise, on either end. Presumably the Windows side is a USB driver emulating a serial driver, and the Arduino side is a USB stack doing something similar but in reverse. So whether serial over USB is lossless should depend entirely on the USB implementation, no? Is the Arduino's USB code available for inspection somewhere? I'd rather not wade through the source but if I must, I must.
there's no actual serial hardware involved, RS-232 or otherwise, on either end.
Wrong.
On the Arduino is a USB to serial converter chip. Then there is a serial connection between this chip and the Arduino's processor. So it is serial for part of its journey.
Note this applies to most Arduinos, exceptions being the Leonardo which does indeed do it all in software.
Grumpy_Mike is right that the USB communication on most Arduino boards is not done by the main processor, he's not completely correct in the case of the Due (as is the same for the UNO and the Mega2560). There it's not a USB to serial converter chip but a co-processor (ATmega16U2) which is doing that, in software as the Leonardo (and the Yun) is doing in the main processor. And the firmware for that processor is available for you to inspect:
hardware/arduino/firmwares/atmegaxxu2/arduino-usb2serial/
That's inside your IDE so you already have that source code.
There it's not a USB to serial converter chip but a co-processor (ATmega16U2) which is doing that
So what do you think the difference is between this and a USB to serial converter chip? They are both software based processors that do an actual conversion between real serial and te USB protocol.
So what do you think the difference is between this and a USB to serial converter chip? They are both software based processors that do an actual conversion between real serial and te USB protocol.
They are different in the detail that on the ATmega16U2 I can change the software it is running while an FTDI chip is preprogrammed and it's firmware cannot be modified (I'm eager to learn that this is wrong but that's my current knowledge). I think, given the OP's question, this is relevant and not being covered in your answer.
I think, given the OP's question, this is relevant and not being covered in your answer.
I don't think it has any relevance to the OPs question, just because one has it's code in a PROM and the other in Flash makes no difference to anything to do with the conversion process does it?
I don't think it has any relevance to the OPs question, just because one has it's code in a PROM and the other in Flash makes no difference to anything to do with the conversion process does it?
It might be that I misinterpreted the OP's question but I thought he likes to see how the USB serial emulation is implemented on the Arduino side. He thought that the SAM3X is doing that but on the Due an ATmega16U2 is doing it, nevertheless that source code is available and he can inspect it. That's what I tried to show in my post. Excuse me if I've chosen the wrong words for that, I never intended to snub somebody.