RS232 vs USB CDC calidad de servicio / ¿deberían los mensajes contener una suma de verificación?

¿Tiene USB una garantía de calidad de servicio para los datos enviados entre mi dispositivo USB-CDC y el host USB?

Sé que con RS232 tradicional en una situación ruidosa (p. Ej., Puerto de diagnóstico automotriz), los bits defectuosos suceden con la frecuencia suficiente para que las sumas de verificación sean importantes para el protocolo. Si tuviera que adaptar dicho protocolo a una aplicación puramente USB, ¿puedo omitir con seguridad la suma de verificación y las rutinas relacionadas con el manejo de errores?

Como referencia, estoy usando un AT91SAM7S256 con el marco USB-CDC proporcionado por Atmel.

Actualizar:

Ejercité mi Google-Fu un poco más sobre este problema y encontré este artículo que describe una subclase de CDC para la emulación de Ethernet y afirma:

A través del cable USB, las tramas Ethernet encapsuladas fluyen comenzando con la dirección MAC de destino y terminando justo antes de la suma de verificación de la trama. (La suma de comprobación del marco no es necesaria ya que el USB es un transporte confiable).

Pueden significar que USB-CDC es un transporte confiable, no USB en general, ya que algunas clases de dispositivos destinados a datos de ráfaga de alto rendimiento (¿cámara web?) Pueden no querer llenar buffers si un programa no puede sondear datos lo suficientemente rápido.

Todavía me gustaría una confirmación adicional sobre esto.

Esto depende de qué tipos de punto final esté utilizando su dispositivo.

Un resumen rápido tomado de USB en pocas palabras :

Transferencias de interrupción

• Latencia garantizada
• Tubo de corriente - unidireccional
• Detección de errores y reintento del próximo período.

Transferencias isócronas

• Las transferencias isócronas proporcionan acceso garantizado al ancho de banda USB.
• Latencia acotada.
• Tubo de corriente - unidireccional
• Detección de errores a través de CRC, pero sin reintentos ni garantía de entrega.
• Solo modos de velocidad completa y alta.
• Sin alternar datos.

Transferencias masivas

• Se utiliza para transferir grandes datos de ráfagas.
• Detección de errores vía CRC, con garantía de entrega.
• No hay garantía de ancho de banda o latencia mínima.
• Stream Pipe: modos unidireccionales de velocidad completa y alta solamente.

Para responder adecuadamente a su pregunta, deberá averiguar qué modos de transferencia se utilizan debajo para implementar el dispositivo CDC. La especificación de clase de dispositivo CDC puede ser un punto de partida. Si tiene un código fuente para el dispositivo, eso sería aún mejor. No estoy familiarizado con la clase CDC, así que no puedo comentar sobre sus estándares de implementación, pero a primera vista en algunos documentos y google, parece que hay cierta flexibilidad en la implementación.

EDITAR

Después de leer el documento de Atmel que vinculó, ¡parece que depende de usted!

El modelo de control abstracto requiere dos interfaces, una interfaz de clase de comunicación y una interfaz de clase de datos. Cada uno de ellos debe tener dos puntos finales asociados. El primero tendrá un punto final dedicado a la gestión de dispositivos (punto final de control 0 predeterminado) y uno para notificación de eventos (punto final adicional de interrupción IN).

La interfaz de clase de datos necesita dos puntos finales a través de los cuales transportar datos hacia y desde el host. Dependiendo de la aplicación, estos puntos finales pueden ser Bulk o Isochronous. En el caso de un convertidor de USB a serie, el uso de puntos finales masivos probablemente sea más apropiado, ya que la confiabilidad de la transmisión es importante y las transferencias de datos no son críticas.

Entonces, en su implementación, asegúrese de usar transferencias masivas en su interfaz de clase de datos para garantizar un transporte confiable.

USB puede ser un protocolo relativamente confiable, pero no todos los dispositivos y controladores que usan CDC son confiables. He visto un par de dispositivos diferentes que tenían el hábito bastante molesto de omitir bytes de datos enviados por la PC. La observación de los datos en un alcance mostró que el problema no era que el dispositivo receptor se desbordara: algunos bytes de datos simplemente desaparecieron (pude capturar un paquete completo en el alcance; el encabezado y el pie de página estaban presentes, pero algunos de los bytes entre ellos faltaban). No estoy seguro de qué salió mal exactamente para causar ese comportamiento, pero tratar de enviar datos demasiado rápido parecía ser un factor contribuyente.