Kỹ thuật phân định / đồng bộ hóa giao thức nối tiếp

Vì giao tiếp nối tiếp không đồng bộ được lan truyền rộng rãi giữa các thiết bị điện tử ngay cả ngày nay, tôi tin rằng nhiều người trong chúng ta thỉnh thoảng gặp phải một câu hỏi như vậy. Xem xét một thiết bị điện tử Dvà máy tính PCđược kết nối với đường nối tiếp (RS-232 hoặc tương tự) và được yêu cầu trao đổi thông tin liên tục . Tức PClà đang gửi từng khung lệnh X msvà Dđang trả lời từng khung báo cáo trạng thái / từ xa Y ms(Báo cáo có thể được gửi dưới dạng phản hồi cho các yêu cầu hoặc độc lập - không thực sự quan trọng ở đây). Các khung giao tiếp có thể chứa bất kỳ dữ liệu nhị phân tùy ý . Giả sử các khung giao tiếp là các gói có độ dài cố định.

Vấn đề:

Vì giao thức là liên tục, phía nhận có thể mất đồng bộ hóa hoặc chỉ "tham gia" ở giữa khung được gửi liên tục, do đó, nó sẽ không biết bắt đầu của khung (SOF) ở đâu. Dữ liệu có ý nghĩa khác nhau dựa trên vị trí của nó tương đối với SOF, dữ liệu nhận được sẽ bị hỏng, có khả năng là mãi mãi.

Các giải pháp cần thiết

Lược đồ phân định / đồng bộ hóa đáng tin cậy để phát hiện SOF với thời gian phục hồi ngắn (nghĩa là không nên mất nhiều hơn, giả sử 1 khung để đồng bộ hóa lại).

Các kỹ thuật hiện có mà tôi biết (và sử dụng một số) về:

1) Tiêu đề / tổng kiểm tra - SOF là giá trị byte được xác định trước. Tổng kiểm tra vào cuối khung.

• Ưu điểm: Đơn giản.
• Nhược điểm: Không đáng tin cậy. Thời gian phục hồi không xác định.

2) Byte nhồi:

• Ưu điểm: Đáng tin cậy, phục hồi nhanh, có thể được sử dụng với bất kỳ phần cứng nào
• Nhược điểm: Không phù hợp với giao tiếp dựa trên khung có kích thước cố định

3) Đánh dấu bit thứ 9 - thêm vào mỗi byte bằng bit bổ sung, trong khi SOF được đánh dấu 1và các byte dữ liệu được đánh dấu bằng 0:

• Ưu điểm: Đáng tin cậy, phục hồi nhanh
• Nhược điểm: Yêu cầu hỗ trợ phần cứng. Không được hỗ trợ trực tiếp bởi hầu hết các PCphần cứng và phần mềm.

4) Đánh dấu bit thứ 8 - loại mô phỏng ở trên, trong khi sử dụng bit thứ 8 thay vì thứ 9, chỉ để lại 7 bit cho mỗi từ dữ liệu.

• Ưu điểm: Đáng tin cậy, phục hồi nhanh, có thể được sử dụng với bất kỳ phần cứng nào.
• Nhược điểm: Yêu cầu sơ đồ mã hóa / giải mã từ / đến biểu diễn 8 bit thông thường đến / từ biểu diễn 7 bit. Hơi lãng phí.

5) Dựa trên thời gian chờ - giả sử SOF là byte đầu tiên đến sau một số thời gian nhàn rỗi được xác định.

• Ưu điểm: Không có dữ liệu trên đầu, đơn giản.
• Nhược điểm: Không đáng tin cậy. Sẽ không hoạt động tốt với các hệ thống thời gian kém như Windows PC. Chi phí thông lượng tiềm năng.

Câu hỏi: Các kỹ thuật / giải pháp khả thi khác tồn tại để giải quyết vấn đề là gì? Bạn có thể chỉ ra những nhược điểm trong danh sách trên có thể dễ dàng làm việc xung quanh, do đó loại bỏ chúng? Làm thế nào để bạn (hoặc bạn sẽ) thiết kế giao thức hệ thống của bạn?

Làm thế nào để bạn (hoặc bạn) thiết kế giao thức hệ thống của bạn?

Theo kinh nghiệm của tôi, mọi người đều dành nhiều thời gian để gỡ lỗi các hệ thống truyền thông hơn họ mong đợi. Và vì vậy tôi thực sự khuyên bạn nên bất cứ khi nào bạn cần đưa ra lựa chọn cho giao thức giao tiếp, bạn chọn bất kỳ tùy chọn nào giúp hệ thống dễ dàng gỡ lỗi hơn nếu có thể.

Tôi khuyến khích bạn chơi với việc thiết kế một vài giao thức tùy chỉnh - thật thú vị và rất giáo dục. Tuy nhiên, tôi cũng khuyến khích bạn xem xét các giao thức đã có từ trước. Nếu tôi cần truyền dữ liệu từ nơi này sang nơi khác, tôi sẽ rất cố gắng sử dụng một số giao thức có sẵn mà người khác đã dành nhiều thời gian để gỡ lỗi.

Viết giao thức giao tiếp của riêng bạn từ đầu rất có khả năng chống lại nhiều vấn đề phổ biến giống như mọi người gặp phải khi họ viết một giao thức mới.

Có hàng tá giao thức hệ thống nhúng được liệt kê tại Giao thức tốt dựa trên RS232 để nhúng vào giao tiếp máy tính - giao thức nào gần nhất với yêu cầu của bạn?

Ngay cả khi một số trường hợp khiến cho không thể sử dụng chính xác bất kỳ giao thức có sẵn nào, tôi vẫn có khả năng làm cho một cái gì đó hoạt động nhanh hơn bằng cách bắt đầu với một số giao thức gần như phù hợp với yêu cầu, và sau đó điều chỉnh nó.

tin xấu

Như tôi đã nói trước đây :

Thật không may, không thể có bất kỳ giao thức giao tiếp nào có tất cả các tính năng dễ có này:

• Độ trong suốt: truyền dữ liệu là trong suốt và "8 bit sạch" - (a) mọi tệp dữ liệu có thể được truyền đi, (b) các chuỗi byte trong tệp luôn được xử lý dưới dạng dữ liệu và không bao giờ hiểu sai như một thứ khác và (c ) đích nhận được toàn bộ tệp dữ liệu mà không có lỗi, không có bất kỳ bổ sung hoặc xóa.
• sao chép đơn giản: hình thành các gói là dễ nhất nếu chúng ta đơn giản sao chép dữ liệu từ nguồn vào trường dữ liệu của gói mà không thay đổi.
• start start duy nhất: biểu tượng start-of-pack rất dễ nhận biết, bởi vì nó là một byte hằng số đã biết không bao giờ xảy ra ở bất kỳ nơi nào khác trong các tiêu đề, CRC tiêu đề, tải trọng dữ liệu hoặc CRC dữ liệu.
• 8 bit: chỉ sử dụng byte 8 bit.

Tôi sẽ ngạc nhiên và vui mừng nếu có bất kỳ cách nào để một giao thức truyền thông có tất cả các tính năng này.

Tin tốt

Các kỹ thuật / giải pháp có thể khác tồn tại để giải quyết vấn đề là gì?

Thông thường, nó làm cho việc gỡ lỗi dễ dàng hơn nhiều, dễ dàng hơn nhiều nếu một người ở thiết bị đầu cuối văn bản có thể thay thế bất kỳ thiết bị giao tiếp nào. Điều này đòi hỏi giao thức phải được thiết kế tương đối độc lập với thời gian (không hết thời gian trong thời gian tạm dừng tương đối dài giữa các lần nhấn phím do con người gõ). Ngoài ra, các giao thức như vậy được giới hạn trong các loại byte dễ dàng cho con người gõ và sau đó đọc trên màn hình.

Một số giao thức cho phép tin nhắn được gửi ở chế độ "văn bản" hoặc "nhị phân" (và yêu cầu tất cả các tin nhắn nhị phân có thể có một số tin nhắn văn bản "tương đương" có nghĩa tương tự). Điều này có thể giúp làm cho việc gỡ lỗi dễ dàng hơn nhiều.

Một số người dường như nghĩ rằng việc giới hạn một giao thức chỉ sử dụng các ký tự có thể in là "lãng phí", nhưng sự tiết kiệm trong thời gian gỡ lỗi thường khiến nó trở nên đáng giá.

Như bạn đã đề cập, nếu bạn cho phép trường dữ liệu chứa bất kỳ byte tùy ý, bao gồm các byte bắt đầu và cuối tiêu đề, khi bộ thu được bật lần đầu tiên, có khả năng bộ thu bị đồng bộ hóa sai trông giống như một byte bắt đầu (SOH) trong trường dữ liệu ở giữa một gói. Thông thường, người nhận sẽ nhận được một tổng kiểm tra không khớp ở cuối gói giả đó (thường là một nửa trong gói thực thứ hai). Sẽ rất hấp dẫn khi chỉ cần loại bỏ toàn bộ tin nhắn giả (bao gồm nửa đầu của gói thứ hai) trước khi tìm SOH tiếp theo - với kết quả là người nhận có thể không đồng bộ hóa cho nhiều tin nhắn.

Như alex.forencich đã chỉ ra, một cách tiếp cận tốt hơn là người nhận loại bỏ byte khi bắt đầu bộ đệm cho đến SOH tiếp theo. Điều này cho phép người nhận (sau khi có thể làm việc thông qua một số byte SOH trong gói dữ liệu đó) để đồng bộ hóa ngay lập tức trên gói thứ hai.

Bạn có thể chỉ ra những nhược điểm trong danh sách trên có thể dễ dàng làm việc xung quanh, do đó loại bỏ chúng?

Như Nicholas Clark đã chỉ ra, nhồi byte trên không nhất quán (COBS) có một chi phí cố định hoạt động tốt với các khung có kích thước cố định.

Một kỹ thuật thường bị bỏ qua là một byte đánh dấu cuối khung chuyên dụng. Khi máy thu được bật ở giữa đường truyền, một byte đánh dấu cuối khung chuyên dụng sẽ giúp máy thu đồng bộ hóa nhanh hơn.

Khi một máy thu được bật ở giữa một gói và trường dữ liệu của gói xảy ra có chứa các byte dường như là một gói bắt đầu (bắt đầu của gói giả), máy phát có thể chèn một chuỗi các byte đánh dấu cuối khung sau gói đó, do đó, các byte giả gói bắt đầu trong trường dữ liệu không can thiệp vào việc đồng bộ hóa ngay lập tức và giải mã chính xác gói tiếp theo - ngay cả khi bạn cực kỳ không may mắn và tổng kiểm tra gói giả đó xuất hiện đúng.

Chúc may mắn.

Kế hoạch nhồi Byte đã làm việc rất tốt cho tôi trong những năm qua. Chúng rất hay vì chúng dễ thực hiện trong phần mềm hoặc phần cứng, bạn có thể sử dụng cáp USB-to-UART tiêu chuẩn để gửi các gói dữ liệu và bạn được đảm bảo có được khung hình chất lượng tốt mà không phải lo lắng về thời gian chờ, trao đổi nóng, hoặc bất cứ điều gì khác như thế.

Tôi sẽ ủng hộ phương pháp nhồi byte kết hợp với byte độ dài (modulo độ dài gói 256) và CRC cấp gói, sau đó sử dụng UART với bit chẵn lẻ. Byte độ dài đảm bảo phát hiện byte bị rớt, hoạt động tốt với bit chẵn lẻ (vì hầu hết các UART sẽ bỏ bất kỳ byte nào không tương đương). Sau đó, CRC cấp gói cung cấp cho bạn bảo mật thêm.

Về chi phí nhồi byte, bạn đã xem giao thức COBS chưa? Đó là một cách thiên tài để thực hiện nhồi byte với chi phí cố định là 1 byte cho mỗi 254 lần truyền (cộng với việc đóng khung, CRC, LEN, v.v.) của bạn.

https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing

Tùy chọn số 1 của bạn, SOH cộng với tổng kiểm tra, IS đáng tin cậy và nó phục hồi trên khung chưa được xử lý tiếp theo.

Tôi giả sử bạn đã biết độ dài của tin nhắn hoặc độ dài được mã hóa theo (các) byte ngay sau SOH. Các byte kiểm tra xuất hiện ở cuối tin nhắn. Bạn cũng cần một bộ đệm phía nhận cho dữ liệu ít nhất là miễn là tin nhắn dài nhất của bạn.

Mỗi khi bạn thấy một byte SOH ở đầu bộ đệm, nó có khả năng bắt đầu một thông báo. Bạn quét qua bộ đệm để tính giá trị kiểm tra cho thông báo đó và xem liệu nó có khớp với các byte kiểm tra trong bộ đệm hay không. Nếu vậy, bạn đã hoàn tất; mặt khác, bạn loại bỏ dữ liệu từ bộ đệm cho đến khi bạn nhận được byte SOH tiếp theo.

Lưu ý rằng nếu một thông báo thực sự có lỗi dữ liệu, thuật toán này sẽ loại bỏ nó - nhưng có lẽ bạn sẽ làm điều đó bằng mọi cách. Nếu thuật toán kiểm tra của bạn bao gồm sửa lỗi chuyển tiếp, bạn có thể kiểm tra từng căn chỉnh thông báo tiềm năng để biết các lỗi có thể sửa được.

Nếu các thông báo có độ dài cố định, bạn có thể phân phối hoàn toàn với byte SOH - chỉ cần kiểm tra MỌI vị trí bắt đầu có thể để tìm giá trị kiểm tra hợp lệ.

Bạn cũng có thể phân phối với thuật toán kiểm tra và chỉ giữ byte SOH, nhưng điều này làm cho thuật toán ít xác định hơn. Ý tưởng là để sắp xếp tin nhắn hợp lệ, SOH sẽ luôn xuất hiện khi bắt đầu tin nhắn. Nếu bạn có căn chỉnh không chính xác, byte tiếp theo trong luồng dữ liệu không chắc là một SOH khác (phụ thuộc vào tần suất SOH xuất hiện trong dữ liệu thông báo). Bạn chỉ có thể chọn ra các byte SOH hợp lệ trên cơ sở này. (Về cơ bản, cách đóng khung trên các dịch vụ viễn thông đồng bộ như T1 và E1 hoạt động.)

Một tùy chọn không được đề cập nhưng được sử dụng rộng rãi (đặc biệt là trên internet) là mã hóa ASCII / văn bản (thực ra, hầu hết các triển khai hiện đại đều giả định UTF-8). Theo kinh nghiệm của tôi, những người làm phần cứng ghét làm điều này nhưng những người làm phần mềm có xu hướng thích điều này hơn hầu hết mọi thứ khác (chủ yếu là vì truyền thống Unix làm cho mọi thứ dựa trên văn bản).

Ưu điểm của mã hóa văn bản là bạn có thể sử dụng các ký tự không in được để đóng khung. Ví dụ, đơn giản nhất sẽ là sử dụng một cái gì đó như 0x00để chỉ bắt đầu của khung và 0xffcho cuối khung.

Tôi đã thấy hai cách chính dữ liệu được mã hóa thành văn bản:

1. Khi một anh chàng phần cứng / lắp ráp được yêu cầu làm điều này thì rất có thể nó sẽ được thực hiện dưới dạng mã hóa hex. Điều này chỉ đơn giản là chuyển đổi các byte thành giá trị hex của chúng trong ASCII. Chi phí trên cao. Về cơ bản, bạn sẽ truyền hai byte cho mỗi byte dữ liệu thực tế.

2. Khi một anh chàng phần mềm được yêu cầu làm điều này thì có lẽ nó sẽ được thực hiện dưới dạng mã hóa base64. Đây là mã hóa thực tế của internet. Được sử dụng cho tất cả mọi thứ từ email đính kèm MIME đến mã hóa dữ liệu URL. Chi phí chính xác là 33%. Tốt hơn nhiều so với mã hóa hex đơn giản.

Ngoài ra, bạn hoàn toàn có thể từ bỏ dữ liệu nhị phân và truyền văn bản. Trong trường hợp này, kỹ thuật phổ biến nhất là phân định dữ liệu bằng dòng mới (chỉ "\n"hoặc hoặc "\r\n"). Các lệnh NMEA (GPS), Modem AT và cảm biến ADAM Adventech là một số ví dụ phổ biến nhất về điều này.

Tất cả các giao thức / khung dựa trên văn bản này đều có những ưu và nhược điểm sau:

Chuyên nghiệp:

• Dễ gỡ lỗi
• Dễ dàng thực hiện bằng ngôn ngữ kịch bản
• Phần cứng đơn giản có thể được kiểm tra bằng Hyperterminal / minicom
• Dễ dàng thực hiện trên phần cứng (trừ khi đó là một vi thực sự nhỏ như PIC)
• Có thể là khung kích thước cố định hoặc kích thước khác nhau.
• Đóng khung có thể dự đoán và thời gian khôi phục đồng bộ hóa nhanh (phục hồi ở cuối khung hiện tại)

Con:

• Chi phí rất lớn so với truyền nhị phân thuần túy (sau đó, một lần nữa, I / O văn bản cũng có thể "nén" các số như gửi một byte "0"(0x30) thay vì bốn byte 0x00000000)
• Không sạch sẽ để thực hiện trên các micrô rất nhỏ như PIC (trừ khi thư viện của bạn có sprintf()chức năng)

Cá nhân với tôi những ưu điểm vượt trội hơn nhiều so với nhược điểm. Sự dễ dàng của việc gỡ lỗi một mình được tính là 5 điểm (do đó chỉ một điểm đã vượt trội hơn cả hai nhược điểm).

Sau đó, có những giải pháp không được suy nghĩ cẩn thận thường đến từ những kẻ phần mềm: gửi dữ liệu được mã hóa mà không nghĩ về việc đóng khung.

Tôi đã phải giao diện với phần cứng đã gửi XML thô trong quá khứ. XML là tất cả các khung có. May mắn thay, thật dễ dàng để tìm ra ranh giới khung hình bằng các <xml></xml>thẻ. Đối tượng lớn đối với tôi là nó sử dụng nhiều hơn một byte để tạo khung. Ngoài ra, bản thân khung có thể không được sửa vì thẻ có thể chứa các thuộc tính: <tag foo="bar"></tag>vì vậy bạn phải đệm trong trường hợp xấu nhất để tìm điểm bắt đầu của khung.

Gần đây tôi đã thấy mọi người bắt đầu gửi JSON ra khỏi các cổng nối tiếp. Với khung JSON là tốt nhất là một dự đoán. Bạn chỉ có ký tự "{"(hoặc "[") để phát hiện khung nhưng chúng cũng được chứa trong dữ liệu. Vì vậy, cuối cùng bạn cần một trình phân tích cú pháp gốc đệ quy (hoặc ít nhất là bộ đếm dấu ngoặc) để tìm ra khung. Ít nhất cũng không quan trọng nếu biết khung hiện tại kết thúc sớm: "}{"hay "]["là bất hợp pháp trong JSON và do đó chỉ ra rằng khung cũ đã kết thúc và một khung mới đã bắt đầu.

Những gì bạn mô tả là "đánh dấu bit X" có thể được khái quát thành các mã khác có thuộc tính mở rộng dữ liệu theo một phần không đổi, để lại một số từ mã được sử dụng làm dấu phân cách. Thông thường các mã này cũng cung cấp các lợi ích khác; Các CD sử dụng tám đến mười bốn điều chế , đảm bảo độ dài chạy tối đa là 0 bit giữa mỗi 1. Ví dụ khác bao gồm mã khối Sửa lỗi Chuyển tiếp , cũng sử dụng các bit bổ sung để mã hóa thông tin phát hiện và sửa lỗi.

Một hệ thống khác mà bạn chưa đề cập là sử dụng hết thông tin băng tần, chẳng hạn như dòng chọn chip, để phân định các giao dịch hoặc gói.

Một lựa chọn khác là những gì được gọi là mã hóa dòng . Mã hóa đường truyền cho tín hiệu một số đặc tính điện nhất định giúp truyền tải dễ dàng hơn (đảm bảo độ dài chạy tối đa và cân bằng DC) và chúng hỗ trợ các ký tự điều khiển để tạo khung và đồng bộ hóa đồng hồ. Mã dòng được sử dụng trong tất cả các giao thức nối tiếp tốc độ cao hiện đại - 10M, 100M, 1G và 10G Ethernet, ATA nối tiếp, FireWire, USB 3, PCIe, v.v. Mã dòng phổ biến là 8b / 10b , 64b / 66b và 128b / 130b. Ngoài ra còn có các mã dòng đơn giản hơn không cung cấp thông tin định khung, chỉ có cân bằng DC và đồng bộ hóa đồng hồ. Ví dụ trong số này là Machester và NRZ. Bạn có thể muốn sử dụng 8b / 10b nếu bạn muốn đồng bộ hóa nhanh chóng; các mã dòng khác không được thiết kế để đồng bộ vội vàng. Sử dụng mã dòng như cung cấp ở trên sẽ yêu cầu sử dụng phần cứng tùy chỉnh để truyền và nhận.

Đối với tùy chọn 5 của bạn, nối tiếp chuẩn RS232 được cho là hỗ trợ gửi và nhận ngắt trong đó dòng không hoạt động trong một vài lần byte. Tuy nhiên, điều này có thể không được hỗ trợ trên tất cả các hệ thống.

Nói chung, phương pháp đóng khung đơn giản và đáng tin cậy nhất là tùy chọn 1 của bạn, kết hợp với trường độ dài và CRC đơn giản hoặc thói quen kiểm tra. Thói quen giải mã rất đơn giản: loại bỏ byte cho đến khi bạn nhận được byte bắt đầu, đọc trường độ dài, chờ toàn bộ khung, kiểm tra tổng kiểm tra, giữ nếu tốt. Nếu tổng kiểm tra là xấu, bắt đầu loại bỏ byte khỏi bộ đệm cho đến khi bạn nhận được một byte bắt đầu và lặp lại. Vấn đề chính của kỹ thuật này là tìm ra sự bắt đầu của byte khung mà thực sự không phải là bắt đầu của byte khung. Để giảm bớt vấn đề này, một kỹ thuật là thoát các byte có cùng giá trị với bắt đầu của byte khung với một ký tự điều khiển khác, sau đó thay đổi byte thoát để nó có giá trị khác. Trong trường hợp này, bạn cũng sẽ phải làm điều tương tự với byte điều khiển mới.