Chất lượng dịch vụ của RS232 vs USB CDC / tin nhắn có nên chứa tổng kiểm tra không?


13

USB có đảm bảo chất lượng dịch vụ cho dữ liệu được gửi giữa thiết bị USB-CDC của tôi và máy chủ USB không?

Tôi biết với RS232 truyền thống trong tình huống ồn ào (ví dụ cổng chẩn đoán ô tô) các bit xấu thường xảy ra đủ để tổng kiểm tra rất quan trọng đối với giao thức. Nếu tôi thích ứng một giao thức như vậy với ứng dụng USB thuần túy, tôi có thể bỏ qua kiểm tra và các thói quen xử lý lỗi liên quan một cách an toàn không?

Để tham khảo, tôi đang sử dụng AT91SAM7S256 với khung USB-CDC do Atmel cung cấp.

Cập nhật:

Tôi thực Google-Fu của tôi lâu hơn một chút về vấn đề này và tìm thấy này bài viết trong đó mô tả một lớp con của CDC cho Ethernet thi đua và các quốc gia:

Qua cáp USB, các khung Ethernet được đóng gói bắt đầu với địa chỉ MAC đích và kết thúc ngay trước khi kiểm tra khung. (Không cần kiểm tra khung vì USB là phương tiện di chuyển đáng tin cậy.)

Chúng có thể có nghĩa là USB-CDC là phương tiện truyền tải đáng tin cậy, không phải USB nói chung, vì một số loại thiết bị dành cho dữ liệu bùng nổ thông lượng cao (webcam?) Có thể không muốn lấp đầy bộ đệm nếu chương trình không thể thăm dò dữ liệu đủ nhanh.

Tôi vẫn muốn xác nhận thêm về điều này.

Câu trả lời:


12

Điều này phụ thuộc vào loại thiết bị đầu cuối mà thiết bị của bạn đang sử dụng.

Tóm tắt nhanh lấy từ USB một cách ngắn gọn :

Chuyển gián đoạn

  • Độ trễ đảm bảo
  • Stream Stream - một chiều
  • Phát hiện lỗi và thử lại giai đoạn tiếp theo.

Chuyển giao đồng bộ

  • Truyền đồng bộ cung cấp quyền truy cập được đảm bảo vào băng thông USB.
  • Độ trễ giới hạn.
  • Stream Stream - một chiều
  • Phát hiện lỗi thông qua CRC, nhưng không thử lại hoặc đảm bảo giao hàng.
  • Chế độ đầy đủ và tốc độ cao chỉ.
  • Không có dữ liệu chuyển đổi.

Chuyển số lượng lớn

  • Được sử dụng để chuyển dữ liệu lớn.
  • Phát hiện lỗi thông qua CRC, với sự đảm bảo của việc giao hàng.
  • Không đảm bảo băng thông hoặc độ trễ tối thiểu.
  • Stream ống - Chỉ có các chế độ tốc độ cao và đầy đủ một chiều.

Để trả lời đúng câu hỏi của bạn, bạn sẽ cần tìm hiểu các chế độ truyền nào đang được sử dụng bên dưới để triển khai thiết bị CDC. Đặc tả lớp thiết bị CDC có thể là điểm khởi đầu. Nếu bạn có mã nguồn cho thiết bị thì điều đó sẽ còn tốt hơn nữa. Tôi không quen thuộc với lớp CDC vì vậy tôi không thể nhận xét về các tiêu chuẩn thực hiện của nó, nhưng thoạt nhìn vào một số tài liệu và google, có vẻ như có một sự linh hoạt trong việc thực hiện.

BIÊN TẬP

Sau khi đọc tài liệu Atmel mà bạn liên kết, có vẻ như nó tùy thuộc vào bạn!

Mô hình điều khiển trừu tượng yêu cầu hai giao diện, một Giao diện lớp giao tiếp và một giao diện lớp dữ liệu. Mỗi người trong số họ phải có hai điểm cuối liên quan. Cái trước sẽ có một điểm cuối dành riêng cho quản lý thiết bị (điểm cuối Điều khiển mặc định 0) và một điểm cuối cho thông báo sự kiện (điểm cuối IN gián đoạn bổ sung).

Giao diện lớp dữ liệu cần hai điểm cuối để thông qua dữ liệu đến và từ máy chủ lưu trữ. Tùy thuộc vào ứng dụng, các điểm cuối này có thể là Hàng loạt hoặc Đồng bộ. Trong trường hợp bộ chuyển đổi USB sang nối tiếp, sử dụng điểm cuối hàng loạt có lẽ phù hợp hơn, vì độ tin cậy của việc truyền là quan trọng và việc truyền dữ liệu không phải là thời gian quan trọng.

Vì vậy, trong quá trình triển khai của bạn, hãy đảm bảo sử dụng chuyển số lượng lớn trên giao diện Lớp dữ liệu của bạn để đảm bảo vận chuyển đáng tin cậy.


Câu trả lời chính xác. Tóm tắt các loại điểm cuối là rất hữu ích. Mã Atmel cho dự án nối tiếp CDC được mô tả trong pdf được liên kết được thiết lập để hoạt động như một bộ chuyển đổi USB sang nối tiếp, do đó, nó đã được cấu hình để sử dụng các điểm cuối hàng loạt. Thông minh!
Steven T. Snyder

3

USB có thể là một giao thức tương đối đáng tin cậy, nhưng không phải tất cả các thiết bị và trình điều khiển sử dụng CDC đều đáng tin cậy. Tôi đã thấy một vài thiết bị khác nhau có thói quen khá khó chịu là bỏ qua byte dữ liệu được gửi bởi PC. Quan sát dữ liệu trên một phạm vi cho thấy vấn đề không phải là do thiết bị nhận bị tràn ngập - một số byte dữ liệu bị mất (tôi có thể chụp toàn bộ gói trên phạm vi; cả tiêu đề và chân trang đều có mặt, nhưng một số trong số các byte giữa chúng bị thiếu). Tôi không chắc chính xác những gì đã sai để gây ra hành vi đó, nhưng cố gắng gửi dữ liệu quá nhanh dường như là một yếu tố góp phần.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.