RS232 vs USB CDC quality of service / should messages contain a checksum?

Question

Does USB have a quality of service guarantee for data sent between my USB-CDC device and the USB host?

I know with traditional RS232 in a noisy situation (e.g. automotive diagnostic port) bad bits happen often enough that checksums are important to the protocol. If I were to adapt such a protocol to a pure-USB application, can I safely omit the checksum and related error handling routines?

For reference, I am using an AT91SAM7S256 with the USB-CDC framework provided by Atmel.

Update:

I exercised my Google-Fu a bit longer on this problem and found this article which describes a CDC subclass for Ethernet emulation and states:

Over the USB cable, encapsulated Ethernet frames flow starting with the destination MAC address and ending just before the frame checksum. (The frame checksum is not needed since USB is a reliable transport.)

They may mean USB-CDC is reliable transport, not USB in general, since some device classes intended for high-throughput bursty data (webcam?) might not want to fill up buffers if a program can't poll for data fast enough.

I would still like additional confirmation on this.

Answer 1

This depends on what endpoint types your device is using.

A quick summary taken from USB in a nutshell:

Interrupt Transfers

• Guaranteed Latency
• Stream Pipe - Unidirectional
• Error detection and next period retry.

Isochronous Transfers

• Isochronous Transfers provide Guaranteed access to USB bandwidth.
• Bounded latency.
• Stream Pipe - Unidirectional
• Error detection via CRC, but no retry or guarantee of delivery.
• Full & high speed modes only.
• No data toggling.

Bulk Transfers

• Used to transfer large bursty data.
• Error detection via CRC, with guarantee of delivery.
• No guarantee of bandwidth or minimum latency.
• Stream Pipe - Unidirectional Full & high speed modes only.

To properly answer your question, you will need to find out what transfer modes are being used underneath to implement the CDC device. The CDC device class specification may be a starting point. If you have source code for the device then that would be even better. I am not familiar with the CDC class so I can't comment on its implementation standards, but at first glance at some documents and google, it appears that there is some flexibility in implementation.

EDIT

After reading the Atmel document that you linked, it appears that it is up to you!

The Abstract Control Model requires two interfaces, one Communication Class Interface and one Data Class Interface. Each of them must have two associated endpoints. The former shall have one endpoint dedicated to device management (default Control endpoint 0) and one for events notification (additional Interrupt IN endpoint).

The Data Class Interface needs two endpoints through which to carry data to and from the host. Depending on the application, these endpoints can either be Bulk or Isochronous. In the case of a USB to serial converter, using Bulk endpoints is probably more appropriate, since the reliability of the transmission is important and the data transfers are not time-critical.

So in your implementation, be sure to use bulk transfers on your Data Class interface to ensure reliable transport.

Answer 2

USB may be a relatively reliable protocol, but not all devices and drivers that use CDC are reliable. I've seen a couple of different devices which had a rather annoying habit of skipping bytes of data that were sent by the PC. Observing the data on a scope showed that the problem wasn't with the receiving device getting overrun--some bytes of data simply went missing (I was able to capture whole packet on the scope; the header and footer were both present, but some of the bytes between them were missing). I'm not sure what exactly went wrong to cause that behavior, but trying to send data too fast seemed to be a contributing factor.