RS232 против качества обслуживания CDC USB / должны ли сообщения содержать контрольную сумму?

Есть ли у USB гарантия качества обслуживания для данных, передаваемых между моим устройством USB-CDC и хостом USB?

Я знаю, что с традиционным RS232 в шумной ситуации (например, автомобильный диагностический порт) плохие биты случаются достаточно часто, поэтому контрольные суммы важны для протокола. Если бы мне пришлось адаптировать такой протокол для приложения, использующего только USB, могу ли я безопасно пропустить контрольную сумму и соответствующие процедуры обработки ошибок?

Для справки я использую AT91SAM7S256 с платформой USB-CDC, предоставленной Atmel.

Обновить:

Я немного потренировал свой Google-Fu над этой проблемой и нашел эту статью, которая описывает подкласс CDC для эмуляции Ethernet и заявляет:

Через USB-кабель инкапсулированные кадры Ethernet проходят, начиная с MAC-адреса назначения и заканчивая непосредственно перед контрольной суммой кадра. (Контрольная сумма кадра не нужна, поскольку USB - надежный транспорт.)

Они могут означать, что USB-CDC является надежным транспортным средством, а не USB в целом, поскольку некоторые классы устройств, предназначенные для высокопроизводительных пакетных данных (веб-камера?), Могут не захотеть заполнять буферы, если программа не может достаточно быстро запросить данные.

Я все еще хотел бы дополнительное подтверждение по этому поводу.

Это зависит от того, какие типы конечных точек использует ваше устройство.

Краткий обзор по USB :

Переводы прерываний

• Гарантированная задержка
• Stream Pipe - однонаправленный
• Обнаружение ошибок и повторная попытка следующего периода.

Изохронные переводы

• Изохронные передачи обеспечивают гарантированный доступ к пропускной способности USB.
• Ограниченная задержка.
• Stream Pipe - однонаправленный
• Обнаружение ошибок через CRC, но без повторных попыток или гарантии доставки.
• Только полный и высокоскоростной режимы.
• Нет данных переключения.

Массовые переводы

• Используется для передачи больших пакетных данных.
• Обнаружение ошибок через CRC, с гарантией доставки.
• Нет гарантии пропускной способности или минимальной задержки.
• Stream Pipe - только однонаправленный режим Full и high speed.

Чтобы правильно ответить на ваш вопрос, вам необходимо выяснить, какие режимы передачи используются для реализации устройства CDC. Спецификация класса устройства CDC может быть отправной точкой. Если у вас есть исходный код для устройства, это было бы еще лучше. Я не знаком с классом CDC, поэтому я не могу комментировать его стандарты реализации, но на первый взгляд некоторые документы и Google показывают, что есть некоторая гибкость в реализации.

РЕДАКТИРОВАТЬ

После прочтения документа Atmel, который вы связали, кажется, что это ваше дело!

Абстрактная модель управления требует двух интерфейсов, одного интерфейса класса связи и одного интерфейса класса данных. Каждый из них должен иметь две связанные конечные точки. Первый должен иметь одну конечную точку, выделенную для управления устройством (конечная точка управления по умолчанию 0) и одну для уведомления о событиях (дополнительная конечная точка IN прерывания).

Интерфейсу класса данных нужны две конечные точки, через которые можно переносить данные на хост и с него. В зависимости от приложения, эти конечные точки могут быть либо массовыми, либо изохронными. В случае преобразователя USB в последовательный интерфейс, вероятно, более целесообразно использовать групповые конечные точки, поскольку надежность передачи важна, а передача данных не критична по времени.

Поэтому в своей реализации обязательно используйте массовые передачи в интерфейсе класса данных, чтобы обеспечить надежную передачу.

USB может быть относительно надежным протоколом, но не все устройства и драйверы, которые используют CDC, являются надежными. Я видел несколько разных устройств, у которых была довольно раздражающая привычка пропускать байты данных, отправленных ПК. Наблюдение за данными в области показало, что проблема не была в переполнении принимающего устройства - некоторые байты данных просто пропали (я смог перехватить весь пакет в области; и заголовок, и нижний колонтитул оба присутствовали, но некоторые из байтов между ними не было). Я не уверен, что именно пошло не так, чтобы вызвать такое поведение, но попытка отправить данные слишком быстро, казалось, способствовал.