RS232 vs USB CDCサービス品質/メッセージにチェックサムを含める必要がありますか？

USBには、USB-CDCデバイスとUSBホスト間で送信されるデータのサービス品質保証がありますか？

ノイズの多い状況（自動車の診断ポートなど）で従来のRS232を使用している場合、不良ビットが頻繁に発生するため、プロトコルにとってチェックサムが重要です。そのようなプロトコルを純粋なUSBアプリケーションに適応させる場合、チェックサムと関連するエラー処理ルーチンを安全に省略できますか？

参考のため、Atmelが提供するUSB-CDCフレームワークでAT91SAM7S256を使用しています。

更新：

この問題についてGoogle-Fuをもう少し試したところ、イーサネットエミュレーションと状態のCDCサブクラスについて説明している次の記事が見つかりました。

カプセル化されたイーサネットフレームは、USBケーブルを介して、宛先MACアドレスから始まり、フレームチェックサムの直前で終わります。（USBは信頼できるトランスポートであるため、フレームチェックサムは必要ありません。）

プログラムが十分な速度でデータをポーリングできない場合、高スループットのバーストデータ（webcam？）を対象とする一部のデバイスクラスはバッファーを満杯にしたくない場合があるため、USB-CDCは一般的なUSBではなく信頼性の高いトランスポートを意味する場合があります。

私はまだこれに関する追加の確認をお願いします。

これは、デバイスが使用しているエンドポイントタイプによって異なります。

一言で言えばUSBから取られた簡単な要約：

割り込み転送

• 遅延保証
• ストリームパイプ-単方向
• エラー検出と次の期間の再試行。

アイソクロナス転送

• アイソクロナス転送により、USB帯域幅へのアクセスが保証されます。
• 制限されたレイテンシ。
• ストリームパイプ-単方向
• CRCによるエラー検出。ただし、再試行や配信の保証はありません。
• フルモードと高速モードのみ。
• データの切り替えはありません。

バルク転送

• 大規模なバーストデータの転送に使用されます。
• CRCによるエラー検出、配信の保証。
• 帯域幅または最小遅延の保証はありません。
• ストリームパイプ-単方向フル＆高速モードのみ。

質問に適切に回答するには、CDCデバイスを実装するためにどの転送モードが使用されているかを調べる必要があります。CDCデバイスクラスの仕様が出発点になる場合があります。デバイスのソースコードがある場合は、さらに良いでしょう。私はCDCクラスに精通していないため、その実装標準についてコメントすることはできませんが、いくつかのドキュメントとGoogleを一見すると、実装にはある程度の柔軟性があるように見えます。

編集

リンクしたAtmelドキュメントを読んだ後、それはあなた次第のようです！

抽象制御モデルには、1つの通信クラスインターフェイスと1つのデータクラスインターフェイスの2つのインターフェイスが必要です。それぞれに2つのエンドポイントが関連付けられている必要があります。前者には、デバイス管理専用のエンドポイントが1つ（デフォルトの制御エンドポイント0）、イベント通知用に1つ（追加の割り込みINエンドポイント）があります。

データクラスインターフェイスには、ホストとの間でデータをやり取りするための2つのエンドポイントが必要です。アプリケーションに応じて、これらのエンドポイントはバルクまたはアイソクロナスのいずれかになります。USBからシリアルへのコンバーターの場合、バルクエンドポイントを使用するのがおそらくより適切です。これは、伝送の信頼性が重要であり、データ転送がタイムクリティカルではないためです。

したがって、実装では、データクラスインターフェイスでバルク転送を使用して、信頼性の高いトランスポートを確保してください。

USBは比較的信頼できるプロトコルですが、CDCを使用するすべてのデバイスとドライバーが信頼できるわけではありません。私は、PCから送信されたデータのバイトをスキップするというかなり厄介な習慣を持っているいくつかの異なるデバイスを見てきました。スコープでデータを観察すると、問題は受信デバイスがオーバーランすることではなく、データの一部のバイトが失われるだけではないことがわかりました（スコープでパケット全体をキャプチャできました;ヘッダーとフッターの両方が存在しましたが、それらの間のバイトが欠落していました）。何がその振る舞いを引き起こしたのか正確にはわからないが、データを速すぎて送信しようとすることは一因であるように思われた。