Якість обслуговування RS232 vs USB CDC / чи мають повідомлення містити контрольну суму?

Чи має гарантія якості USB для даних, що надсилаються між моїм пристроєм USB-CDC та USB-хостом?

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

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

Оновлення:

Я трохи більше попрацював над своєю проблемою в Google-Фу і знайшов цю статтю, яка описує підклас CDC для емуляції Ethernet і заявляє:

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

Вони можуть означати, що USB-CDC є надійним транспортом, а не USB взагалі, оскільки деякі класи пристроїв, призначені для пропускних даних з високою пропускною здатністю (веб-камера?), Можливо, не хочуть заповнювати буфери, якщо програма не може запитати дані досить швидко.

Я все одно хотів би додаткового підтвердження щодо цього.

Це залежить від того, які кінцеві точки використовує ваш пристрій.

Короткий підсумок, взятий з USB у двох словах :

Переривання перерв

• Гарантована затримка
• Потокова труба - односпрямована
• Виявлення помилок та повторний повторний повторний період.

Ізохронні перекази

• Ізохронні передачі забезпечують гарантований доступ до пропускної здатності USB.
• Обмежена затримка.
• Потокова труба - односпрямована
• Виявлення помилок через CRC, але без повторних спроб або гарантії доставки.
• Тільки режими повного та високого швидкості.
• Немає перемикання даних.

Масові перекази

• Використовується для передачі великих пакетних даних.
• Виявлення помилок через CRC з гарантією доставки.
• Немає гарантії пропускної здатності або мінімальної затримки.
• Потокова труба - лише однонаправлені повні та швидкісні режими.

Щоб правильно відповісти на ваше запитання, вам потрібно буде з’ясувати, які режими передачі використовуються під реалізацією пристрою CDC. Специфікація класу пристроїв CDC може бути відправною точкою. Якщо у вас є вихідний код для пристрою, це було б ще краще. Я не знайомий з класом CDC, тому я не можу коментувати його стандарти впровадження, але на перший погляд на деякі документи та google виявляється, що є певна гнучкість у застосуванні.

EDIT

Прочитавши документ Atmel, який ви зв'язали, виявляється, що саме від вас залежить!

Модель абстрактного управління вимагає двох інтерфейсів, одного інтерфейсу класу комунікацій та одного інтерфейсу класу даних. Кожна з них повинна мати дві пов'язані кінцеві точки. Перша має одну кінцеву точку, призначену для управління пристроєм (кінцева точка управління за замовчуванням 0), та одну для сповіщення про події (додаткова кінцева точка переривання IN).

Інтерфейс класу даних потребує двох кінцевих точок, через які можна переносити дані до та від хоста. Залежно від застосування, ці кінцеві точки можуть бути як об'ємними, так і ізохронними. Що стосується USB-послідовного перетворювача, то використання кінцевих точок групового зв'язку, ймовірно, є більш доцільним, оскільки надійність передачі важлива і передача даних не є критичною за часом.

Тож у своїй реалізації не забудьте використовувати масові передачі на інтерфейсі класу даних, щоб забезпечити надійний транспорт.

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