51單片機(jī)串口通訊編程的方式解析

前言：

串口通訊對于所有的嵌入式工程師十分常見，對于一個與外界交互的系統(tǒng)必須依賴一些手段，比如串口、USB、紅外、GPRS之類的數(shù)據(jù)通訊傳輸方式。而串口作為一種廉價的短距離可靠的通訊方式得到了廣泛應(yīng)用。

廢話少說了，就此打住，進(jìn)入正題。

本文主要從軟件結(jié)構(gòu)上講解如何在資源比較缺乏的系統(tǒng)上實現(xiàn)通訊協(xié)議的串口通訊編程，以及如何優(yōu)化程序效率，從而使系統(tǒng)更快、更穩(wěn)定運行。

正文：

我們以51單片機(jī)為例。51中一般針對串口通訊編程，通常采取中斷接受查詢發(fā)送的方式。中斷函數(shù)在接受數(shù)據(jù)到達(dá)時被重復(fù)調(diào)用，其實是個重復(fù)入棧的過程，所以不宜將函數(shù)寫的太長，函數(shù)太長一般會導(dǎo)致棧太深占用系統(tǒng)資源，二是處理時間過長，可能導(dǎo)致通訊出錯。為了防止在處理數(shù)據(jù)過程中不受干擾，通常在處理接受數(shù)據(jù)前關(guān)閉中斷，處理完后再開。

通常的的編程方式如下：

static void UartInterruptService（void） interrupt 4

{

ES = 0;

RI = 0;

uart_process（SBUF）;

ES=1;

}

下面重點介紹數(shù)據(jù)處理函數(shù) uart_process（SBUF）;

其實很多時候，對于通訊傳輸?shù)臄?shù)據(jù)處理才是關(guān)鍵，尤其對于設(shè)計通訊協(xié)議而言。筆者在剛剛做的一個系統(tǒng)上就碰到這樣的問題，當(dāng)系統(tǒng)龐大了，資源十分有限的情況下，數(shù)據(jù)處理一旦占用資源太多，效率太低將導(dǎo)致系統(tǒng)崩潰而無法運行。

到了這里，很多工程師可能會考慮開個大的緩沖區(qū)FIFO將接收到的數(shù)據(jù)保存在緩沖區(qū)，然后對其進(jìn)行解析、判斷進(jìn)行下一步程序編寫，當(dāng)然這在系統(tǒng)資源比較豐富的情況下是沒有問題的，ARM上采取的就是這樣的方式。但如何系統(tǒng)龐大呢，留給的資源缺乏則不行。這樣做的一個很大缺點必須是將數(shù)據(jù)幀接收完了才能夠判斷，降低了效率和運行速度。

其實還有另外的方式，可以采取在每接收一個字節(jié)就對其解析，解析完判斷轉(zhuǎn)到下一個狀態(tài)，并將其中的有用數(shù)據(jù)存儲在相應(yīng)的數(shù)據(jù)結(jié)構(gòu)中去，可以采取狀態(tài)機(jī)實現(xiàn)。

將狀態(tài)機(jī)設(shè)計為兩個控制狀態(tài)，一是串口狀態(tài)——uart_state ，一是命令類型狀態(tài)——cmd_state 。

（1）狀態(tài)機(jī)開始狀態(tài)：串口狀態(tài)為CMD_NO

（2）接受到STX_CMD，狀態(tài)變?yōu)镃MD_START.

（3）接下來將自動進(jìn)入接受命令幀的狀態(tài)，再開啟命令狀態(tài)的狀態(tài)機(jī)，對發(fā)送來的有用數(shù)據(jù)進(jìn)行解析，保存，校驗等。處理完畢后將uart_state設(shè)為CMD_END狀態(tài)進(jìn)行下一步的接受完畢判斷，將cmd_state設(shè)置為初始的NO_CMD狀態(tài)。

（4）最后進(jìn)行ETX_CMD判斷，判斷數(shù)據(jù)接收是否完畢。

void uart_process（U8 u8）

{

if（uart_state == CMD_NO）

{

if（u8 == STX_CMD）

{

uart_state = CMD_START;

}

}

else if（uart_state == CMD_START）

{

switch（cmd_state）

{

case NO_CMD：

cmd_state = u8;

break;

case COST_CMD：

//解析存儲有用數(shù)據(jù)到相應(yīng)數(shù)據(jù)結(jié)構(gòu)中

//進(jìn)行CRC校驗

uart_state = CMD_END;

cmd_state = NO_CMD;

CRC = 0;

break;

}

}

else if（uart_state == CMD_END）

{

uart_state = CMD_NO;

if（u8 == ETX_CMD）

{

//接受完畢

//可以考慮拋出一個消息main函數(shù)循環(huán)中進(jìn)行響應(yīng)處理。

}

}

}

接下來我們要討論解析后我們數(shù)據(jù)存儲的問題，其實在資源比較足夠的情況下或者能夠擠出data區(qū)的情況下可以考慮用結(jié)構(gòu)體，我們構(gòu)造好相應(yīng)結(jié)構(gòu)體，將接收到的數(shù)據(jù)存儲進(jìn)去，要應(yīng)用的時候就十分方便。但這也有個矛盾，一般c51定義的結(jié)構(gòu)體都被存儲在data區(qū)，一般通訊的字節(jié)量大空間必然不夠，存在一個矛盾，可以采用聯(lián)合體union進(jìn)行存儲效果會好一點。當(dāng)然也可以在保存數(shù)據(jù)時采用定義在xdata區(qū)（片外）的buffer來存儲。這樣在一定程序上優(yōu)化了程序的執(zhí)行效率，在程序處理立即拋出消息處理，提高了通訊數(shù)據(jù)的處理速度。對于通常資源比較豐富的系統(tǒng)，比如ARM上一般采取的做法是這樣的，將數(shù)據(jù)存在緩沖區(qū)，接收完一幀數(shù)據(jù)后再轉(zhuǎn)換成相應(yīng)的數(shù)據(jù)結(jié)構(gòu)，再進(jìn)行分析、校驗。

總體來說，這種采取狀態(tài)機(jī)實時解析串口通訊數(shù)據(jù)的方式在一定程序提高了程序運行效率，使軟件架構(gòu)清晰明了，程序可擴(kuò)展性大，有利于后續(xù)開發(fā)。
來源；21ic