嵌入式系統(tǒng)中串口通信幀的同步方法

引 言

串口通信是日前單片機和DSP等嵌入式系統(tǒng)之間，以及嵌入式系統(tǒng)與PC機或無線模塊之間的一種非常重要且普遍使用的通信方式。在嵌入式系統(tǒng)的硬件結構中，通常只有一個8位或16位的CPU，不僅要完成主流程的工作，同時還要處理隨時發(fā)生的各種中斷，因而嵌入式系統(tǒng)中的串口通信程序設計與PC機有很大的不同。若嵌入式系統(tǒng)中.中斷服務子程序在系統(tǒng)運行過程中占用了較多的時間，就有可能在中斷眼務子程序正運行時，又產生一個同類型或其他類型的中斷，從而造成主程序得不到執(zhí)行或后續(xù)中斷數(shù)據(jù)丟失。所以，嵌入式系統(tǒng)中的串口通信雖然看似簡單，但其中仍有許多問題值得研究，例如串口通信過程中的幀同步問題。本文針對該問題給出了逐次比較、基于FIFO隊列和基于狀態(tài)機的3種幀同步方法。通過測試、分析和比較得出，基于有限狀態(tài)機的方法是嵌入式系統(tǒng)串口通信中很有效的幀同步方法，同時也是一種很不錯的串口通信程序設計結構。

1 串口通信的數(shù)據(jù)幀結構

現(xiàn)代工業(yè)控制，往往需要由多個獨立的控制模塊來共同完成。它們之間通過串口通信完成復雜的控制過程，必須在通信過程中加入必要的通信協(xié)議，以提高系統(tǒng)的可靠性和穩(wěn)定性;而要完成特定的通信協(xié)議，就得有一定的同步機制。下面介紹一下簡化的串口通信數(shù)據(jù)幀結構，以便分析說明嵌入式系統(tǒng)串口通信過程中的幀同步方法。

假定串口發(fā)送的數(shù)據(jù)幀結構為：

其中：包頭用于同步，一般是一個或多個ASCII字符，本文中假定數(shù)據(jù)幀同步頭有2字節(jié)(0xAA、0x55);包長表示數(shù)據(jù)包中除去包頭和包長的字節(jié)數(shù)，一般用約定好的幾個字節(jié)表示;類型為通信協(xié)議里規(guī)定的命令類型;數(shù)據(jù)為應發(fā)送的主要信息;校驗通常采用單字節(jié)“異或”的方法。

2 串口通信中的幀同步方法

2.1 逐次比較的幀同步方法

首先等待串口數(shù)據(jù)，將接收到的第1個字節(jié)數(shù)據(jù)與約定好的包頭信息的第1個字節(jié)進行比較。如果不正確，則等待新字節(jié)，直到接收的數(shù)據(jù)與包頭信息的第1 個字節(jié)相同。第1個字節(jié)比較正確以后，將收到的第2個字節(jié)與包頭信息的第2個字節(jié)進行比較。如果仍然正確，則說明串口接收已經同步，可以開始接收數(shù)據(jù)幀中的數(shù)據(jù)部分;否則，重新開始同步過程。其程序流程如圖1所示。

此種方法代碼量小，編程簡單，一般用于在主程序中以非中斷方式接收串口數(shù)據(jù)、實時性很差、數(shù)據(jù)幀較短的場合。但是，在串口速度過快且包頭字節(jié)數(shù)比較多的情況下，串口實現(xiàn)同步花費的時間很長或很難實現(xiàn)同步。例如，串口接收到序列Ox0O OxAA0xAA 0x55…，當遇到第一個“0xAA”時，該方法認為第1個字節(jié)正確開始比較第2個同步頭。第2個字節(jié)仍是“0xAA”而不是“0x55”，所以必須等待新的字節(jié)重新開始比較第1個同步頭。而緊隨其后的是“0x55”，因而，此時包頭的第1個字節(jié)也沒有同步上。事實上，“0x00 OxAA”是干擾字節(jié)，“0xAA 0x55”才是通信協(xié)議中的同步頭。

2.2 基于FIFO隊列的幀同步方法

根據(jù)同步包頭的長度，定義一個相同長度的全局字節(jié)數(shù)組，把該數(shù)組看成是一個如圖2所示的先入先出(FIFO)的隊列。程序流程如圖3所示。

本例中定義兩個字節(jié)HEADl和HEAD2，都初始化為0xFF。同步時，丟棄數(shù)組頭字節(jié)HEADl，數(shù)組中的所有數(shù)據(jù)向前移動一個字節(jié)，串口接收到的新字節(jié)存入數(shù)組末字節(jié)HEAD2中，將整個數(shù)組與協(xié)議中的包頭信息比較。如果正確，則置位已同步標志位，然后開始接收、存儲有用數(shù)據(jù);否則，繼續(xù)等待同步。串口數(shù)據(jù)接收完后，不僅要清除已同步標志，還要把HEADl和HEAD2兩個字節(jié)都賦值0xFF;否則，將會影響下一幀數(shù)據(jù)的同步和接收。用前面提到的序列“0x00 0xAA 0xAA 0x55…”進行測試，隨著串口接收中斷收到新的字節(jié)。幀同步隊列中的數(shù)據(jù)依次為： [0xFF，0xFF]→[0x00，0xFF]→[0xAA，0x00]→[0xAA，0xAA]→[0x55，0xAA]。此時，該算法檢測出 [HEAD2，HEAD2]==[0x55，0xAA]，從而實現(xiàn)了同步，置位已同步標志位以便下次進入串口接收中斷服務子程序時開始接收數(shù)據(jù)包的數(shù)據(jù)部分。

此種方法與逐次比較的幀同步方法相比，能夠比較快速、正確地檢測出同步包頭;但是如果包頭的字節(jié)數(shù)很多，同步過程中每次進入串口中斷服務子程序都要進行大量的字節(jié)搬移，將必然耗費很長的時間。為了使嵌入式系統(tǒng)更健壯，程序設計應把握的基本原則之一就是使中斷處理程序最短。所以基于FIFO隊列的幀同步方法也不是最優(yōu)的。

2.3 基于有限狀態(tài)機的幀同步方法

為解決以上問題，可以采用基于有限狀態(tài)機的設計方法。該方法將數(shù)據(jù)幀的接收過程分為若干個狀態(tài)：接收信息頭HEADl狀態(tài)、接收信息頭HEAD2狀態(tài)、接收包長狀態(tài)、接收數(shù)據(jù)類型狀態(tài)、接收數(shù)據(jù)狀態(tài)及接收校驗和狀態(tài)。系統(tǒng)的初始狀態(tài)為HEADl狀態(tài)，各接收狀態(tài)間的狀態(tài)轉移圖如圖4所示，仍用前面提到的序列“0x00 0xAA 0xAA 0x55…”進行測試。隨著串口接收中斷新字節(jié)的接收，系統(tǒng)的接收狀態(tài)依次為HEAD1→HEAD1→HEAD2→HEAD2→LEN?？梢姶藭r就是同步狀態(tài)。該方法也快速、有效地實現(xiàn)了同步;但是需要注意的是，在每一次接收完1幀完整的數(shù)據(jù)之后，必須把系統(tǒng)的接收狀態(tài)重新設置為HEADl，否則將會影響下一幀的數(shù)據(jù)接收。

此后，程序按照協(xié)議開始依次接收數(shù)據(jù)幀長度、命令類型、數(shù)據(jù)和校驗位。接收完后，重新設置系統(tǒng)接收狀態(tài)為HEADl，同時對該數(shù)據(jù)幀進行校驗。校驗正確后，利用消息機制通知主程序根據(jù)命令類型對數(shù)據(jù)幀進行處理或執(zhí)行相應的命令操作。

下面給出該方法在KeilC5l中的示例程序：

由于采用了狀態(tài)機和消息機制的結構，上述設計思路快速有效地實現(xiàn)了串口通信的同步，而且程序結構清晰，便于維護，也易于向其他的串口通信協(xié)議移植。另外，串口中斷服務子程序中需要處理的工作很少，每個串口接收中斷平均耗時不超過20個機器周期(在單片機AT89C5l中)，大大減輕了串口接收中斷服務程序的壓力，緩解了嵌入式系統(tǒng)有限資源與需求之問的矛盾，提高了嵌入式系統(tǒng)的穩(wěn)定性。

3 結論

從上面的分析和測試可以看出，基于有限狀態(tài)機的串口通信幀同步方法是本文中提出的3種幀方法中最優(yōu)的，結構清晰且系統(tǒng)資源利用率高。

對一個有著完整通信協(xié)議的串口中斷來說，因為要比較命令頭、完成校驗、解析數(shù)據(jù)等需要耗費大量的機器周期，所以嵌入式系統(tǒng)中的串口中斷服務程序設計顯得更為重要。在實際的串口通信程序中，可采用狀態(tài)機和消息機制相結合的方法，僅在中斷服務程序中設置一個標志，而在主程序中根據(jù)相應標志來作處理，這樣就回避了某些中斷可能需要較長處理時間的問題。在程序結構上，由于采用狀態(tài)機的結構，既提高了可讀性。同時又提高了運行速度，因而該方法不僅是一種很好的幀同步方法，還是一種很不錯的串口通信程序設計方法。