Làm thế nào không an toàn là \ n \ r là byte dừng?

Trong giao tiếp UART của tôi, tôi cần biết byte bắt đầu và byte dừng của tin nhắn được gửi. Byte bắt đầu dễ dàng nhưng byte dừng, không quá nhiều. Tôi đã triển khai hai byte dừng ở cuối tin nhắn của mình, đó là \ n và \ r (10 và 13 thập phân). UART chỉ hoạt động trên các giá trị byte 0-255, vậy làm thế nào là không an toàn? Tôi có thể tưởng tượng, mặc dù xác suất thấp, thông điệp của tôi có thể chứa các giá trị "10 và 13" sau khi chúng không phải là byte dừng.

Có cách nào tốt hơn để thực hiện điều này?

Có nhiều cách khác nhau để ngăn chặn điều này:

• Hãy chắc chắn rằng bạn không bao giờ gửi kết hợp 10/13 trong các tin nhắn thông thường của bạn (vì vậy chỉ là các byte dừng). Ví dụ: gửi 20 21 22 23 24 25:

20 21 22 23 24 25 10 13 13

• Thoát 10 và 13 (hoặc tất cả các ký tự không phải ASCII có ký tự thoát, ví dụ: để gửi 20 21 10 13 25 26 gửi: (xem nhận xét về / tín dụng cho: DanW)

20 21 1b 10 1b 13 25 26

• Xác định một gói khi gửi tin nhắn. Ví dụ: nếu bạn muốn gửi tin nhắn 20 21 22 23 24 25 thay vì thêm số byte cần gửi, thì gói là:

<nr_of_data_bytes> <data>

Nếu tin nhắn của bạn tối đa 256 byte gửi:

06 20 21 22 23 24 25

Vì vậy, bạn biết sau khi nhận được 6 byte dữ liệu là kết thúc; bạn không phải gửi 10 13 sau đó. Và bạn có thể gửi 10 13 trong một tin nhắn. Nếu tin nhắn của bạn có thể dài hơn, bạn có thể sử dụng 2 byte cho kích thước dữ liệu.

Cập nhật 1: Một cách khác để xác định gói

Một cách khác là gửi các lệnh có độ dài cụ thể và có thể có nhiều phương sai, ví dụ:

10 20 30 (Lệnh 10 luôn có 2 byte dữ liệu)

11 30 40 50 (Lệnh 11 luôn có 3 byte dữ liệu)

12 06 10 11 12 13 14 15 (Lệnh 12 + 1 byte cho số byte dữ liệu theo sau)

13 01 02 01 02 03 ... (Lệnh 13 + 2 byte (01 02 cho 256 + 2 = 258 byte dữ liệu theo sau)

14 80 90 10 13 (Lệnh 14 được theo sau bởi chuỗi ASCII kết thúc bằng 10 13)

Cập nhật 2: Mất kết nối / mất byte

Tất cả các cách trên chỉ hoạt động khi dòng UART đang gửi byte chính xác. Nếu bạn muốn sử dụng các cách gửi đáng tin cậy hơn, cũng có nhiều khả năng. Dưới đây là một vài:

1. Gửi một tổng kiểm tra trong gói (kiểm tra google cho CRC: Kiểm tra dự phòng chu kỳ). Nếu CRC ổn, người nhận biết tin nhắn đã được gửi ok (với xác suất cao).
2. Nếu bạn cần gửi lại tin nhắn, hơn cơ chế xác nhận (ACK / trả lời) cần được sử dụng (ví dụ: người gửi gửi một cái gì đó, người nhận nhận dữ liệu bị hỏng, gửi NACK (không được xác nhận), người gửi có thể gửi lại.
3. Hết thời gian: Trong trường hợp người nhận không nhận được ACK hoặc NACK kịp thời, một tin nhắn cần phải được gửi lại.

Lưu ý rằng tất cả các cơ chế trên có thể đơn giản hoặc phức tạp như bạn muốn (hoặc cần). Trong trường hợp gửi lại tin nhắn, cũng cần một cơ chế xác định tin nhắn (ví dụ: thêm số thứ tự vào gói).

Làm thế nào không an toàn là \ n \ r là byte dừng?

Nếu bạn gửi gửi dữ liệu tùy ý -> có thể không đủ an toàn.

Một giải pháp phổ biến là sử dụng thoát:

Hãy xác định rằng các ký tự 0x02 (STX - bắt đầu khung) và 0x03 (ETX - kết thúc khung) cần phải là duy nhất trong luồng dữ liệu được truyền. Bằng cách này, phần đầu và phần cuối của tin nhắn có thể được phát hiện một cách an toàn.

Nếu một trong những ký tự này phải được gửi trong khung thông báo, nó sẽ được thay thế bằng tiền tố một ký tự thoát (ESC = 0x1b) và thêm 0x20 vào ký tự gốc.

Nhân vật gốc được thay thế bởi

0x02 -> 0x1b 0x22  
0x03 -> 0x1b 0x23  
0x1b -> 0x1b 0x3b  

Người nhận đảo ngược quá trình này: Bất cứ khi nào anh ta nhận được một nhân vật thoát, nhân vật này bị loại bỏ và nhân vật tiếp theo bị trừ đi 0x20.

Điều này chỉ thêm một số chi phí xử lý nhưng đáng tin cậy 100% (giả sử không có lỗi truyền nào xảy ra, mà bạn có thể / nên xác minh bằng cách thực hiện bổ sung cơ chế tổng kiểm tra).

Bạn biết đấy, ASCII đã có byte cho các hàm này.

• 0x01: bắt đầu tiêu đề - bắt đầu byte
• 0x02: bắt đầu văn bản - tiêu đề kết thúc, bắt đầu tải trọng
• 0x03: kết thúc văn bản - tải trọng cuối
• 0x04: kết thúc truyền - dừng byte
• 0x17: kết thúc khối truyền - thông báo tiếp tục trong khối tiếp theo

Nó cũng có mã cho các mục đích sử dụng khác nhau bên trong tải trọng.

• 0x1b: esc (thoát ký tự tiếp theo - sử dụng trong tải trọng để chỉ ra ký tự tiếp theo không phải là một trong các cấu trúc mô tả mã được sử dụng trong giao thức của bạn)
• Lần lượt 0x1c, 0x1d, 0x1e, 0x1f: tệp, nhóm, bản ghi và dấu phân cách đơn vị - được sử dụng làm byte dừng và khởi động đồng thời cho các phần của dữ liệu phân cấp

Giao thức của bạn nên chỉ định mức độ chi tiết tốt nhất của ACK (0x06) và NAK (0x15), để dữ liệu được thừa nhận tiêu cực có thể được truyền lại. Theo mức độ chi tiết tốt nhất này, nên có trường độ dài ngay sau bất kỳ chỉ báo bắt đầu (không được giải thích) nào và (như được giải thích trong câu trả lời khác), nên tuân theo bất kỳ chỉ báo dừng (không thoát) nào với CRC.

UART không phải là không an toàn bởi bản chất của nó - chúng ta đang nói về công nghệ những năm 1960 ở đây.

Nguyên nhân của vấn đề là UART chỉ đồng bộ hóa một lần trên 10 bit, cho phép rất nhiều lời nói vô nghĩa giữa các giai đoạn đồng bộ hóa đó. Không giống như ví dụ CAN có thể lấy mẫu mỗi bit riêng lẻ nhiều lần.

Bất kỳ lỗi bit kép nào xảy ra bên trong dữ liệu sẽ làm hỏng khung UART và vượt qua mà không bị phát hiện. Lỗi bit trong bit start / stop có thể hoặc không thể được phát hiện ở dạng lỗi tràn.

Do đó, bất kể bạn sử dụng dữ liệu thô hay gói dữ liệu nào, luôn có xác suất xảy ra lỗi bit do EMI gây ra trong dữ liệu không mong muốn.

Có tồn tại rất nhiều cách "thủ thuật UART truyền thống" để cải thiện tình hình từng chút một. Bạn có thể thêm byte đồng bộ hóa, bit đồng bộ hóa, chẵn lẻ, bit stop đôi. Bạn có thể thêm tổng kiểm tra đếm tổng của tất cả các byte (và sau đó đảo ngược nó - bởi vì tại sao không) hoặc bạn có thể đếm số lượng nhị phân là tổng kiểm tra. Tất cả điều này được sử dụng rộng rãi, cực kỳ không khoa học và có xác suất thiếu lỗi cao. Nhưng đây là những gì mọi người đã làm từ những năm 1960 đến 1990 và rất nhiều điều kỳ lạ như những cuộc sống ngày nay.

Cách chuyên nghiệp nhất để đối phó với việc truyền an toàn qua UART là kiểm tra CRC 16 bit ở cuối gói. Mọi thứ khác không an toàn và có xác suất cao bị thiếu.

Sau đó, ở cấp độ phần cứng, bạn có thể sử dụng vi sai RS-422 / RS-485 để cải thiện đáng kể độ chắc chắn của đường truyền. Đây là điều bắt buộc để truyền an toàn trên khoảng cách xa hơn. UART cấp độ TTL chỉ nên được sử dụng cho giao tiếp trên tàu. RS-232 không nên được sử dụng cho bất kỳ mục đích nào khác mà tương thích ngược với những thứ cũ.

Nhìn chung, cơ chế phát hiện lỗi của bạn càng gần phần cứng thì hiệu quả càng cao. Về tính hiệu quả, các tín hiệu vi sai bổ sung nhiều nhất, tiếp theo là kiểm tra các lỗi đóng khung / tràn ngập vv. CRC16 thêm một số, và sau đó "thủ thuật UART truyền thống" thêm một chút.

... Tôi có thể tưởng tượng, mặc dù xác suất thấp, thông điệp của tôi có thể chứa các giá trị "10 và 13" sau khi chúng không phải là byte dừng.

Một tình huống khi một phần dữ liệu bằng chuỗi kết thúc nên được xem xét khi thiết kế định dạng của gói dữ liệu nối tiếp. Một điều khác cần xem xét là bất kỳ nhân vật nào cũng có thể bị hỏng hoặc bị mất trong quá trình truyền tải. Ký tự bắt đầu, ký tự dừng, byte tải trọng dữ liệu, byte tổng kiểm tra hoặc byte CRC, byte sửa lỗi chuyển tiếp không tránh khỏi tham nhũng. Cơ chế đóng khung phải có khả năng phát hiện khi một gói có dữ liệu bị hỏng.

Có một số cách để tiếp cận tất cả điều này.

Tôi đang đưa ra giả định làm việc rằng các gói chỉ được đóng khung với các byte nối tiếp. Các dòng bắt tay không được sử dụng để đóng khung. Thời gian trễ không được sử dụng để đóng khung.

Gửi chiều dài gói

Gửi độ dài của gói ở đầu, thay vì [hoặc thêm vào] ký tự kết thúc ở cuối.

ưu điểm: Tải trọng được gửi ở định dạng nhị phân hiệu quả.

Nhược điểm: Cần biết chiều dài gói khi bắt đầu truyền.

Thoát khỏi những nhân vật đặc biệt

Thoát các ký tự đặc biệt khi gửi dữ liệu tải trọng. Điều này đã được giải thích trong một câu trả lời trước đó .

ưu điểm: Người gửi không cần biết chiều dài của gói khi bắt đầu truyền.

Nhược điểm: Ít hiệu quả hơn, tùy thuộc vào số lượng byte tải trọng cần được thoát.

Dữ liệu tải trọng được mã hóa sao cho không thể chứa các ký tự bắt đầu và dừng

Tải trọng của gói được mã hóa sao cho nó không thể chứa các ký tự bắt đầu hoặc dừng. Thông thường, điều này được thực hiện bằng cách gửi các số dưới dạng đại diện ASCII hoặc Hex-ASCII của chúng.

ưu điểm: Con người có thể đọc được với các chương trình thiết bị đầu cuối phổ biến. Không cần mã để xử lý thoát. Không cần biết chiều dài của gói khi bắt đầu truyền

Nhược điểm: Hiệu quả thấp hơn. Đối với một byte dữ liệu tải trọng, một vài byte được gửi.