RS232 vs USB CDC Dienstgüte / sollten Nachrichten eine Prüfsumme enthalten?

Verfügt USB über eine Servicequalität für Daten, die zwischen meinem USB-CDC-Gerät und dem USB-Host gesendet werden?

Ich weiß, dass mit herkömmlichem RS232 in einer verrauschten Situation (z. B. einem Kfz-Diagnoseanschluss) oft genug schlechte Bits auftreten, die Prüfsummen für das Protokoll wichtig sind. Wenn ich ein solches Protokoll an eine reine USB-Anwendung anpassen würde, kann ich dann die Prüfsumme und die damit verbundenen Fehlerbehandlungsroutinen sicher weglassen?

Als Referenz verwende ich einen AT91SAM7S256 mit dem von Atmel bereitgestellten USB-CDC- Framework.

Aktualisieren:

Ich habe mein Google-Fu etwas länger auf dieses Problem trainiert und diesen Artikel gefunden, der eine CDC-Unterklasse für die Ethernet-Emulation beschreibt und besagt:

Über das USB-Kabel fließen gekapselte Ethernet-Frames ab der Ziel-MAC-Adresse bis kurz vor der Frame-Prüfsumme. (Die Frame-Prüfsumme wird nicht benötigt, da USB ein zuverlässiger Transport ist.)

Dies kann bedeuten, dass USB-CDC ein zuverlässiger Transport ist, nicht USB im Allgemeinen, da einige Geräteklassen, die für Burst-Daten mit hohem Durchsatz (Webcam?) Vorgesehen sind, möglicherweise keine Puffer füllen möchten, wenn ein Programm nicht schnell genug nach Daten suchen kann.

Ich hätte gerne noch eine zusätzliche Bestätigung dazu.

Dies hängt davon ab, welche Endpunkttypen Ihr Gerät verwendet.

Eine kurze Zusammenfassung von USB auf den Punkt gebracht :

Unterbrechen Sie Übertragungen

• Garantierte Latenz
• Stream Pipe - Unidirektional
• Fehlererkennung und nächster Versuch.

Isochrone Übertragungen

• Isochrone Übertragungen bieten garantierten Zugriff auf die USB-Bandbreite.
• Beschränkte Latenz.
• Stream Pipe - Unidirektional
• Fehlererkennung über CRC, aber keine Wiederholung oder Garantie der Lieferung.
• Nur Voll- und Hochgeschwindigkeitsmodi.
• Keine Datenumschaltung.

Massentransfers

• Dient zum Übertragen großer Datenmengen.
• Fehlererkennung über CRC mit Liefergarantie.
• Keine Garantie für Bandbreite oder minimale Latenz.
• Stream Pipe - Nur unidirektionale Voll- und Hochgeschwindigkeitsmodi.

Um Ihre Frage richtig zu beantworten, müssen Sie herausfinden, welche Übertragungsmodi zur Implementierung des CDC-Geräts verwendet werden. Die CDC-Einheitenklassenspezifikation kann ein Ausgangspunkt sein. Wenn Sie Quellcode für das Gerät haben, wäre das sogar noch besser. Ich bin mit der CDC-Klasse nicht vertraut, daher kann ich ihre Implementierungsstandards nicht kommentieren, aber auf den ersten Blick scheinen einige Dokumente und Google eine gewisse Flexibilität bei der Implementierung zu haben.

BEARBEITEN

Nachdem Sie das von Ihnen verlinkte Atmel-Dokument gelesen haben, liegt es an Ihnen!

Das abstrakte Steuerungsmodell erfordert zwei Schnittstellen, eine Kommunikationsklassenschnittstelle und eine Datenklassenschnittstelle. Jeder von ihnen muss zwei zugeordnete Endpunkte haben. Ersterer verfügt über einen Endpunkt für die Geräteverwaltung (Standard-Steuerendpunkt 0) und einen für die Ereignisbenachrichtigung (zusätzlicher Interrupt IN-Endpunkt).

Die Datenklassenschnittstelle benötigt zwei Endpunkte, über die Daten zum und vom Host übertragen werden. Abhängig von der Anwendung können diese Endpunkte entweder Bulk oder Isochron sein. Bei einem USB-zu-Seriell-Konverter ist die Verwendung von Bulk-Endpunkten wahrscheinlich angemessener, da die Zuverlässigkeit der Übertragung wichtig ist und die Datenübertragung nicht zeitkritisch ist.

Stellen Sie daher in Ihrer Implementierung sicher, dass Sie Massenübertragungen auf Ihrer Datenklassenschnittstelle verwenden, um einen zuverlässigen Transport sicherzustellen.

USB ist möglicherweise ein relativ zuverlässiges Protokoll, aber nicht alle Geräte und Treiber, die CDC verwenden, sind zuverlässig. Ich habe ein paar verschiedene Geräte gesehen, bei denen es ziemlich ärgerlich war, Datenbytes zu überspringen, die vom PC gesendet wurden. Das Beobachten der Daten auf einem Bereich zeigte, dass das Problem nicht darin bestand, dass das empfangende Gerät überlastet wurde - einige Datenbytes gingen einfach verloren (ich konnte das gesamte Paket auf dem Bereich erfassen; die Kopf- und Fußzeile waren beide vorhanden, aber einige der Bytes zwischen ihnen fehlten). Ich bin nicht sicher, was genau schief gelaufen ist, um dieses Verhalten zu verursachen, aber der Versuch, Daten zu schnell zu senden, schien ein beitragender Faktor zu sein.