RS232 vs USB CDC 서비스 품질 / 메시지에 체크섬이 포함되어야합니까?

USB에 USB-CDC 장치와 USB 호스트간에 전송 된 데이터에 대한 서비스 품질 보증이 있습니까?

시끄러운 상황 (예 : 자동차 진단 포트)에서 기존 RS232를 사용하면 체크섬이 프로토콜에 중요 할 정도로 불량 비트가 자주 발생합니다. 이러한 프로토콜을 순수 USB 응용 프로그램에 적용하려는 경우 체크섬 및 관련 오류 처리 루틴을 안전하게 생략 할 수 있습니까?

참고 로 Atmel에서 제공 하는 USB-CDC 프레임 워크 와 함께 AT91SAM7S256을 사용하고 있습니다.

최신 정보:

이 문제에 대해 Google-Fu를 조금 더 연습 했으며 이더넷 에뮬레이션 및 상태에 대한 CDC 하위 클래스를 설명하는 이 기사를 찾았습니다 .

USB 케이블을 통해 캡슐화 된 이더넷 프레임은 대상 MAC 주소에서 시작하여 프레임 체크섬 직전에 종료됩니다. (USB는 안정적인 전송이므로 프레임 체크섬이 필요하지 않습니다.)

처리량이 많은 버스트 데이터 (웹캠?) 용으로 설계된 일부 장치 클래스는 프로그램이 데이터를 충분히 빨리 폴링 할 수없는 경우 버퍼를 채우지 않을 수 있기 때문에 USB-CDC는 일반적으로 USB가 아니라 안정적인 전송을 의미 할 수 있습니다.

나는 여전히 이것에 대한 추가 확인을 원합니다.

장치에서 사용 하는 엔드 포인트 유형 에 따라 다릅니다 .

간단히 말해서 USB에서 가져온 요약 :

인터럽트 전송

• 지연 시간 보장
• 스트림 파이프-단방향
• 오류 감지 및 다음 기간 재시도

등시성 전송

• 등시성 전송은 USB 대역폭에 대한 액세스를 보장합니다.
• 제한된 대기 시간.
• 스트림 파이프-단방향
• CRC를 통한 오류 감지, 재시도 또는 전달 보장은 없습니다.
• 완전 및 고속 모드 만 해당.
• 데이터 전환이 없습니다.

대량 전송

• 큰 버스트 데이터를 전송하는 데 사용됩니다.
• 배송을 보장하는 CRC를 통한 오류 탐지 .
• 대역폭 또는 최소 대기 시간을 보장하지 않습니다.
• 스트림 파이프-단방향 완전 및 고속 모드 만 해당.

질문에 올바르게 대답하려면 CDC 장치를 구현하기 위해 어떤 전송 모드가 사용되고 있는지 확인해야합니다. CDC 디바이스 클래스 스펙은 시작점이 될 수 있습니다. 장치의 소스 코드가 있다면 더 좋습니다. CDC 클래스에 익숙하지 않으므로 구현 표준에 대해서는 언급 할 수 없지만 처음에는 일부 문서와 Google을 보면 구현에 유연성이있는 것으로 보입니다.

편집하다

링크 한 Atmel 문서를 읽은 후 자신에게 달려있는 것으로 보입니다!

추상 제어 모델에는 통신 클래스 인터페이스와 데이터 클래스 인터페이스의 두 가지 인터페이스가 필요합니다. 각각에는 두 개의 연관된 엔드 포인트가 있어야합니다. 전자는 장치 관리 전용 엔드 포인트 (기본 제어 엔드 포인트 0)와 이벤트 알림 용 엔드 포인트 (추가 인터럽트 IN 엔드 포인트)를 갖습니다.

데이터 클래스 인터페이스에는 호스트와 데이터를주고받을 수있는 두 개의 엔드 포인트가 필요합니다. 애플리케이션에 따라 이러한 엔드 포인트는 벌크 또는 등 시일 수 있습니다. USB- 직렬 변환기의 경우 전송의 신뢰성이 중요하고 데이터 전송이 시간 결정적이지 않기 때문에 벌크 엔드 포인트를 사용하는 것이 더 적합 할 것입니다.

따라서 구현시 안정적인 전송을 위해 데이터 클래스 인터페이스에서 대량 전송을 사용해야합니다.

USB는 비교적 안정적인 프로토콜 일 수 있지만 CDC를 사용하는 모든 장치와 드라이버가 신뢰할 수있는 것은 아닙니다. PC에서 보낸 데이터 바이트를 건너 뛰는 다소 성가신 습관을 가진 몇 가지 다른 장치를 보았습니다. 스코프에서 데이터를 관찰하면 수신 장치가 오버런하는 데 문제가 없었습니다. 일부 바이트의 데이터가 단순히 사라졌습니다 (스코프에서 전체 패킷을 캡처 할 수 있었지만 헤더와 바닥 글이 모두 있었지만 일부는 존재했습니다) 그들 사이의 바이트 중 누락되었습니다). 그 동작을 유발하는 원인이 정확히 무엇인지 확실하지 않지만 데이터를 너무 빨리 보내려고하면 기여 요인으로 보입니다.