Jakość usługi RS232 vs USB CDC / czy komunikaty powinny zawierać sumę kontrolną?

Czy USB ma gwarancję jakości usługi dla danych przesyłanych między moim urządzeniem USB-CDC a hostem USB?

Wiem, że z tradycyjnym RS232 w hałaśliwej sytuacji (np. Samochodowy port diagnostyczny) zdarzają się bity na tyle często, że sumy kontrolne są ważne dla protokołu. Gdybym miał dostosować taki protokół do aplikacji wykorzystującej wyłącznie USB, czy mogę bezpiecznie pominąć sumę kontrolną i powiązane procedury obsługi błędów?

Dla porównania używam AT91SAM7S256 ze strukturą USB-CDC dostarczoną przez Atmel.

Aktualizacja:

Ćwiczyłem trochę Google-Fu na tym problemie i znalazłem ten artykuł, który opisuje podklasę CDC do emulacji Ethernet i stwierdza:

Przez kabel USB zamknięte są ramki enkapsulowane Ethernet, zaczynając od docelowego adresu MAC i kończąc tuż przed sumą kontrolną ramki. (Suma kontrolna ramki nie jest potrzebna, ponieważ USB to niezawodny transport).

Mogą oznaczać, że USB-CDC to niezawodny transport, a nie USB w ogóle, ponieważ niektóre klasy urządzeń przeznaczone do szybkich danych seryjnych (kamera internetowa?) Mogą nie chcieć zapełniać buforów, jeśli program nie może wystarczająco szybko sondować danych.

Nadal chcę dodatkowe potwierdzenie w tej sprawie.

Zależy to od typów punktów końcowych używanych przez urządzenie.

Krótkie podsumowanie zaczerpnięte z USB w pigułce :

Przerwać przelewy

• Gwarantowane opóźnienie
• Strumień potoku - jednokierunkowy
• Wykrywanie błędów i ponowna próba następnego okresu.

Transfery izochroniczne

• Transfery izochroniczne zapewniają gwarantowany dostęp do przepustowości USB.
• Ograniczone opóźnienie.
• Strumień potoku - jednokierunkowy
• Wykrywanie błędów za pomocą CRC, ale bez ponownej próby ani gwarancji dostawy.
• Tylko tryby Full i High Speed.
• Brak przełączania danych.

Przelewy zbiorcze

• Służy do przesyłania dużych danych wybuchowych.
• Wykrywanie błędów za pomocą CRC, z gwarancją dostawy.
• Brak gwarancji przepustowości lub minimalnych opóźnień.
• Stream Pipe - tylko jednokierunkowe tryby pełnej i wysokiej prędkości.

Aby poprawnie odpowiedzieć na twoje pytanie, musisz dowiedzieć się, jakie tryby przesyłania są używane poniżej do implementacji urządzenia CDC. Punktem wyjścia może być specyfikacja klasy urządzenia CDC. Jeśli masz kod źródłowy dla urządzenia, byłoby to jeszcze lepsze. Nie jestem zaznajomiony z klasą CDC, więc nie mogę komentować jej standardów implementacyjnych, ale na pierwszy rzut oka na niektóre dokumenty i google wydaje się, że istnieje pewna elastyczność we wdrażaniu.

EDYTOWAĆ

Po przeczytaniu połączonego dokumentu Atmel wydaje się, że to zależy od Ciebie!

Abstrakcyjny model sterowania wymaga dwóch interfejsów, jednego interfejsu klasy komunikacyjnej i jednego interfejsu klasy danych. Każdy z nich musi mieć dwa powiązane punkty końcowe. Ten pierwszy powinien mieć jeden punkt końcowy dedykowany do zarządzania urządzeniami (domyślny punkt kontrolny 0) i jeden do powiadamiania o zdarzeniach (dodatkowy punkt końcowy Przerwanie IN).

Interfejs klasy danych wymaga dwóch punktów końcowych, przez które można przesyłać dane do iz hosta. W zależności od aplikacji te punkty końcowe mogą być masowe lub izochroniczne. W przypadku konwertera USB na szeregowy użycie masowych punktów końcowych jest prawdopodobnie bardziej odpowiednie, ponieważ niezawodność transmisji jest ważna, a transfer danych nie ma krytycznego czasu.

Dlatego we wdrożeniu należy używać przesyłania zbiorczego w interfejsie klasy danych, aby zapewnić niezawodny transport.

USB może być stosunkowo niezawodnym protokołem, ale nie wszystkie urządzenia i sterowniki korzystające z CDC są niezawodne. Widziałem kilka różnych urządzeń, które miały dość irytujący zwyczaj pomijania bajtów danych wysyłanych przez komputer. Obserwacja danych w zakresie pokazała, że ​​problem nie polegał na przepełnieniu urządzenia odbierającego - niektóre bajty danych po prostu zaginęły (byłem w stanie przechwycić cały pakiet w zakresie; zarówno nagłówek, jak i stopka były obecne, ale niektóre brakujących bajtów między nimi). Nie jestem pewien, co dokładnie poszło nie tak, aby spowodować takie zachowanie, ale próba zbyt szybkiego przesłania danych wydawała się być czynnikiem.