Qualité de service RS232 vs USB CDC / les messages doivent-ils contenir une somme de contrôle?

L'USB a-t-il une garantie de qualité de service pour les données envoyées entre mon périphérique USB-CDC et l'hôte USB?

Je sais qu'avec le RS232 traditionnel dans une situation bruyante (par exemple un port de diagnostic automobile), les mauvais bits se produisent assez souvent pour que les sommes de contrôle soient importantes pour le protocole. Si je devais adapter un tel protocole à une application purement USB, puis-je omettre en toute sécurité la somme de contrôle et les routines de gestion des erreurs associées?

Pour référence, j'utilise un AT91SAM7S256 avec le cadre USB-CDC fourni par Atmel.

Mise à jour:

J'ai exercé mon Google-Fu un peu plus longtemps sur ce problème et j'ai trouvé cet article qui décrit une sous-classe CDC pour l'émulation Ethernet et déclare:

Sur le câble USB, les trames Ethernet encapsulées circulent en commençant par l'adresse MAC de destination et se terminant juste avant la somme de contrôle de la trame. (La somme de contrôle du cadre n'est pas nécessaire car l'USB est un moyen de transport fiable.)

Ils peuvent signifier que l'USB-CDC est un transport fiable, pas l'USB en général, car certaines classes d'appareils destinées aux données en rafale à haut débit (webcam?) Pourraient ne pas vouloir remplir les tampons si un programme ne peut pas interroger les données assez rapidement.

J'aimerais encore une confirmation supplémentaire à ce sujet.

Cela dépend des types de terminaux utilisés par votre appareil.

Un bref résumé tiré de l' USB en quelques mots :

Transferts d'interruption

• Latence garantie
• Tuyau de flux - unidirectionnel
• Détection d'erreur et nouvelle tentative de période suivante.

Transferts isochrones

• Les transferts isochrones offrent un accès garanti à la bande passante USB.
• Latence bornée.
• Tuyau de flux - unidirectionnel
• Détection d'erreurs via CRC, mais pas de nouvelle tentative ni garantie de livraison.
• Modes pleine vitesse et haute vitesse uniquement.
• Pas de basculement de données.

Transferts en vrac

• Utilisé pour transférer de grandes données en rafale.
• Détection d'erreurs via CRC, avec garantie de livraison.
• Aucune garantie de bande passante ou de latence minimale.
• Stream Pipe - Modes unidirectionnel pleine vitesse et haute vitesse uniquement.

Pour répondre correctement à votre question, vous devrez découvrir les modes de transfert utilisés ci-dessous pour implémenter le périphérique CDC. La spécification de classe d'unité CDC peut être un point de départ. Si vous avez du code source pour l'appareil, ce serait encore mieux. Je ne connais pas la classe CDC donc je ne peux pas commenter ses normes d'implémentation, mais à première vue sur certains documents et google, il semble qu'il y ait une certaine flexibilité dans l'implémentation.

ÉDITER

Après avoir lu le document Atmel que vous avez lié, il semble que cela dépend de vous!

Le modèle de contrôle abstrait nécessite deux interfaces, une interface de classe de communication et une interface de classe de données. Chacun d'eux doit avoir deux points de terminaison associés. Le premier doit avoir un point d'extrémité dédié à la gestion des dispositifs (point d'extrémité de contrôle par défaut 0) et un pour la notification des événements (point d'extrémité IN d'interruption supplémentaire).

L'interface de classe de données a besoin de deux points de terminaison pour transporter des données vers et depuis l'hôte. Selon l'application, ces points de terminaison peuvent être en bloc ou isochrones. Dans le cas d'un convertisseur USB vers série, l'utilisation de points de terminaison en masse est probablement plus appropriée, car la fiabilité de la transmission est importante et les transferts de données ne sont pas urgents.

Donc, dans votre implémentation, assurez-vous d'utiliser des transferts en masse sur votre interface Data Class pour assurer un transport fiable.

L'USB peut être un protocole relativement fiable, mais tous les périphériques et pilotes qui utilisent CDC ne sont pas fiables. J'ai vu quelques appareils différents qui avaient l'habitude plutôt ennuyeuse de sauter des octets de données envoyés par le PC. L'observation des données sur une portée a montré que le problème n'était pas lié au dépassement du périphérique récepteur - certains octets de données étaient simplement manquants (j'ai pu capturer un paquet entier sur la portée; l'en-tête et le pied de page étaient tous les deux présents, mais certains des octets entre eux manquaient). Je ne sais pas exactement ce qui s'est mal passé pour provoquer ce comportement, mais essayer d'envoyer des données trop rapidement semblait être un facteur contributif.