Loại khung hình nào để sử dụng trong giao tiếp nối tiếp

Question

Trong liên kết truyền thông nối tiếp, phương pháp khung/đồng bộ được ưu tiên là gì?

• khung bằng SOF và trình tự thoát, như trong HDLC?
• dựa vào việc sử dụng tiêu đề có thông tin về độ dài và CRC?

Đây là hệ thống được nhúng sử dụng chuyển DMA dữ liệu từ UART sang bộ nhớ. Tôi nghĩ rằng phương pháp khung với SOF là hấp dẫn nhất, nhưng có lẽ một phương pháp khác là đủ tốt?

Có ai có ưu và nhược điểm cho hai phương pháp này không?

Answer 1

Theo sau dựa trên trải nghiệm nối tiếp UART, không phải nghiên cứu.

Tôi đã tìm thấy ít vấn đề về giao tiếp hơn khi những điều sau đây được bao gồm - hoặc nói cách khác, thực hiện cả SOF/EOF và (chiều dài - có thể)/mã kiểm tra. Frame:

1. SOFrame
2. (Chiều dài có thể)
3. dữ liệu (địa chỉ, đến, từ, chủng loại, chuỗi #, opcode, byte, vv)
4. CheckCode
5. EOFrame

Lúc nào đó, "fames" nhận được bao gồm:

1. những cái tốt - không có vấn đề gì.
2. Hỏng do người gửi không gửi tin nhắn đầy đủ (nó treo, tắt nguồn hoặc truyền lại nguồn bật) (người nhận sẽ hết thời gian chờ tin nhắn chưa hoàn thành.)
3. Hỏng do nhiễu hoặc nhiễu truyền. (lỗi khung byte, chẵn lẻ, dữ liệu không chính xác)
4. Lỗi do người nhận bắt đầu ở giữa thư đã gửi hoặc thiếu một vài byte do bộ đệm đầu vào quá tải.
5. Va chạm xe buýt dùng chung.
6. Break - đây có phải là hệ thống trong hệ thống của bạn không?

Bất kỳ khung nào bạn sử dụng, đảm bảo mạnh mẽ để giải quyết các loại thư này, nhanh chóng xác thựC# 1 và nhanh chóng xác định 2-5 và sẵn sàng cho khung tiếp theo.

SOF có lợi thế rất lớn của nó cho nó dễ dàng để bắt đầu một lần nữa, nếu người nhận bị mất do một khung tào lao trước vv

Chiều dài là tốt, nhưng IMHO hữu ích nhất. Nó có thể giới hạn thông qua đặt, nếu độ dài cần phải ở đầu của một tin nhắn. Một số hoạt động độ trễ thấp chỉ không biết độ dài trước khi chúng sẵn sàng để bắt đầu truyền.

CRC Đề xuất nhiều hơn 2 byte. Một mã kiểm tra ngắn không cải thiện đủ thứ cho tôi. Tôi không muốn có mã kiểm tra hơn mã 1 byte. Nếu lỗi xảy ra từ thời gian để thời gian chỉ bị bắt bởi mã kiểm tra, tôi muốn một cái gì đó tốt hơn so với 99 của 2-byte.999% thời gian, tôi thích 99,99999997%

EOF 4 byte của mình rất hữu ích!

BTW: Nếu giao thức của bạn là ASCII (thay vì nhị phân), khuyên bạn nên không sử dụng cr hoặc lf làm EOFrame. Có thể chỉ sử dụng chúng ngoài khung mà chúng không phải là một phần của thông điệp.

BTW2: Nếu người nhận của bạn có thể tự động phát hiện baud, nó sẽ tiết kiệm được rất nhiều vấn đề cấu hình.

BTW3: Người gửi có thể xem xét việc gửi một byte "không có gì" (trước SOF) để đảm bảo đồng bộ SOF thích hợp.