RS232 vs USB CDC qualità del servizio / i messaggi devono contenere un checksum?

USB ha una garanzia di qualità del servizio per i dati inviati tra il mio dispositivo USB-CDC e l'host USB?

So che con RS232 tradizionale in una situazione rumorosa (ad es. Porta diagnostica automobilistica) si verificano spesso brutti bit che i checksum sono importanti per il protocollo. Se dovessi adattare un protocollo del genere a un'applicazione USB pura, posso omettere in modo sicuro il checksum e le relative routine di gestione degli errori?

Per riferimento, sto usando un AT91SAM7S256 con il framework USB-CDC fornito da Atmel.

Aggiornare:

Ho esercitato il mio Google-Fu un po 'più a lungo su questo problema e ho trovato questo articolo che descrive una sottoclasse CDC per l'emulazione Ethernet e afferma:

Tramite il cavo USB, i frame Ethernet incapsulati scorrono a partire dall'indirizzo MAC di destinazione e terminano poco prima del checksum dei frame. (Il checksum del frame non è necessario poiché l'USB è un trasporto affidabile.)

Possono significare che USB-CDC è un trasporto affidabile, non USB in generale, poiché alcune classi di dispositivi destinate a dati costosi ad alta velocità (webcam?) Potrebbero non voler riempire i buffer se un programma non è in grado di eseguire il polling dei dati abbastanza velocemente.

Vorrei ancora un'ulteriore conferma su questo.

Dipende dai tipi di endpoint utilizzati dal dispositivo.

Un breve riassunto tratto da USB in breve :

Trasferimenti interrotti

• Latenza garantita
• Stream Pipe - Unidirezionale
• Rilevamento errori e nuovo periodo successivo.

Trasferimenti isocroni

• I trasferimenti isocroni forniscono accesso garantito alla larghezza di banda USB.
• Latenza limitata.
• Stream Pipe - Unidirezionale
• Rilevamento errori tramite CRC, ma nessun tentativo o garanzia di consegna.
• Solo modalità alta e alta velocità.
• Nessun passaggio dati.

Trasferimenti collettivi

• Utilizzato per trasferire dati di grandi dimensioni.
• Rilevazione errori tramite CRC, con garanzia di consegna.
• Nessuna garanzia di larghezza di banda o latenza minima.
• Stream Pipe: solo modalità unidirezionali ad alta velocità.

Per rispondere correttamente alla tua domanda, dovrai scoprire quali modalità di trasferimento vengono utilizzate sotto per implementare il dispositivo CDC. Le specifiche della classe di dispositivi CDC possono essere un punto di partenza. Se hai il codice sorgente per il dispositivo, sarebbe ancora meglio. Non ho familiarità con la classe CDC, quindi non posso commentare i suoi standard di implementazione, ma a prima vista alcuni documenti e Google, sembra che ci sia una certa flessibilità nell'implementazione.

MODIFICARE

Dopo aver letto il documento Atmel che hai collegato, sembra che dipende da te!

Il modello di controllo astratto richiede due interfacce, un'interfaccia di classe di comunicazione e un'interfaccia di classe di dati. Ognuno di essi deve avere due endpoint associati. Il primo deve avere un endpoint dedicato alla gestione dei dispositivi (endpoint di controllo 0 predefinito) e uno per la notifica degli eventi (endpoint IN di interruzione aggiuntivo).

L'interfaccia della classe di dati necessita di due endpoint attraverso i quali trasportare i dati da e verso l'host. A seconda dell'applicazione, questi endpoint possono essere Bulk o Isochronous. Nel caso di un convertitore da USB a seriale, l'utilizzo di endpoint in blocco è probabilmente più appropriato, poiché l'affidabilità della trasmissione è importante e il trasferimento dei dati non è critico in termini di tempo.

Pertanto, nella tua implementazione, assicurati di utilizzare i trasferimenti in blocco sull'interfaccia della classe di dati per garantire un trasporto affidabile.

L'USB può essere un protocollo relativamente affidabile, ma non tutti i dispositivi e i driver che utilizzano CDC sono affidabili. Ho visto un paio di dispositivi diversi che avevano l'abitudine piuttosto fastidiosa di saltare byte di dati inviati dal PC. Osservando i dati su un ambito è emerso che il problema non riguardava il sovraccarico del dispositivo ricevente: alcuni byte di dati sono semplicemente scomparsi (sono stato in grado di acquisire l'intero pacchetto sull'ambito; l'intestazione e il piè di pagina erano entrambi presenti, ma alcuni dei byte mancanti tra loro). Non sono sicuro di cosa sia andato esattamente storto a causare quel comportamento, ma cercare di inviare dati troppo velocemente sembrava essere un fattore che ha contribuito.