現在大部分的儀器設備都要求能過通過上位機軟件來操作，這樣方便調試，利于操作。其中就涉及到通信的過程。在實際制作的幾個設備中，筆者總結出了通信程序的通用寫法，包括上位機端和下位機端等。

　　1．自定義數據通信協議

　　這里所說的數據協議是建立在物理層之上的通信數據包格式。所謂通信的物理層就是指我們通常所用到的RS232、RS485、紅外、光纖、無線等等通信方式。在這個層面上，底層軟件提供兩個基本的操作函數：發送一個字節數據、接收一個字節數據。所有的數據協議全部建立在這兩個操作方法之上。

　　通信中的數據往往以數據包的形式進行傳送的，我們把這樣的一個數據包稱作為一幀數據。類似于網絡通信中的TCPIP協議一般，比較可靠的通信協議往往包含有以下幾個組成部分：幀頭、地址信息、數據類型、數據長度、數據塊、校驗碼、幀尾。

　　幀頭和幀尾用于數據包完整性的判別，通常選擇一定長度的固定字節組成，要求是在整個數據鏈中判別數據包的誤碼率越低越好。減小固定字節數據的匹配機會，也就是說使幀頭和幀尾的特征字節在整個數據鏈中能夠匹配的機會最小。通常有兩種做法，一、減小特征字節的匹配幾率。二、增加特征字節的長度。通常選取第一種方法的情況是整個數據鏈路中的數據不具有隨即性，數據可預測，可以通過人為選擇幀頭和幀尾的特征字來避開，從而減小特征字節的匹配幾率。使用第二種方法的情況更加通用，適合于數據隨即的場合。通過增加特征字節的長度減小匹配幾率，雖然不能夠完全的避免匹配的情況，但可以使匹配幾率大大減小，如果碰到匹配的情況也可以由校驗碼來進行檢測，因此這種情況在絕大多說情況下比較可靠。

　　地址信息主要用于多機通信中，通過地址信息的不同來識別不同的通信終端。在一對多的通信系統中，可以只包含目的地址信息。同時包含源地址和目的地址則適用于多對多的通信系統。

　　數據類型、數據長度和數據塊是主要的數據部分。數據類型可以標識后面緊接著的是命令還是數據。數據長度用于指示有效數據的個數。

　　校驗碼則用來檢驗數據的完整性和正確性。通常對數據類型、數據長度和數據塊三個部分進行相關的運算得到。最簡單的做法可是對數據段作累加和，復雜的也可以對數據進行CRC運算等等，可以根據運算速度、容錯度等要求來選取。

　　2．上位機和下位機中的數據發送

　　物理通信層中提供了兩個基本的操作函數，發送一個字節數據則為數據發送的基礎。數據包的發送即把數據包中的左右字節按照順序一個一個的發送數據而已。當然發送的方法也有不同。

　　在單片機系統中，比較常用的方法是直接調用串口發送單個字節數據的函數。這種方法的缺點是需要處理器在發送過程中全程參與，優點是所要發送的數據能夠立即的出現在通信線路上，能夠立即被接收端接收到。另外一種方法是采用中斷發送的方式，所有需要發送的數據被送入一個緩沖區，利用發送中斷將緩沖區中的數據發送出去。這種方法的優點是占用處理器資源小，但是可能出現需要發送的數據不能立即被發送的情況，不過這種時延相當的小。對于51系列單片機，比較傾向于采用直接發送的方式，采用中斷發送的方式比較占用RAM資源，而且對比直接發送來說也沒有太多的優點。以下是51系列單片機中發送單個字節的函數。

　　void SendByte（unsigned char ch）

　　{

　　SBUF = ch;

　　while（TI == 0）;

　　TI = 0;

　　}

　　上位機中關于串口通信的方式也有多種，這種方式不是指數據有沒有緩沖的問題，而是操作串口的方式不同，因為PC上數據發送基本上都會被緩沖后再發送。對于編程來說操作串口有三種方式，一、使用windows系統中自帶的串口通信控件，這種方式使用起來比較簡單，需要注意的是接收時的阻塞處理和線程機制。二、使用系統的API直接進行串口數據的讀取，在windows和linux系統中，設備被虛擬為文件，只需要利用系統提供的API函數即可進行串口數據的發送和讀取。三、使用串口類進行串口操作。在此只介紹windows環境下利用串口類編程的方式。

　　CSerialPort是比較好用的串口類。它提供如下的串口操作方法： void WriteToPort（char* string， int len）;

　　串口初始化成功后，調用此函數即可向串口發送數據。為了避免串口緩沖所帶來的延時，可以開啟串口的沖刷機制。3．下位機中的數據接收和協議解析

　　下位機接收數據也有兩種方式，一、等待接收，處理器一直查詢串口狀態，來判斷是否接收到數據。二、中斷接收。兩種方法的優缺點在此前的一篇關于串口通信的文章中詳細討論過。得出的結論是采用中斷接收的方法比較好。

　　串口初始化成功后，調用此函數即可向串口發送數據。為了避免串口緩沖所帶來的延時，可以開啟串口的沖刷機制。

　　3．下位機中的數據接收和協議解析

　　下位機接收數據也有兩種方式，一、等待接收，處理器一直查詢串口狀態，來判斷是否接收到數據。二、中斷接收。兩種方法的優缺點在此前的一篇關于串口通信的文章中詳細討論過。得出的結論是采用中斷接收的方法比較好。

　　數據包的解析過程可以設置到不同的位置。如果協議比較簡單，整個系統只是處理一些簡單的命令，那么可以直接把數據包的解析過程放入到中斷處理函數中，當收到正確的數據包的時候，置位相應的標志，在主程序中再對命令進行處理。如果協議稍微復雜，比較好的方式是將接收的數據存放于緩沖區中，主程序讀取數據后進行解析。也有兩種方式交叉使用的，比如一對多的系統中，首先在接收中斷中解析“連接”命令，連接命令接收到后主程序進入設置狀態，采用查詢的方式來解析其余的協議。

　　以下給出具體的實例。在這個系統中，串口的命令非常簡單。所有的協議全部在串口中斷中進行。數據包的格式如下：

　　0x55， 0xAA， 0x7E， 0x12， 0xF0， 0x02， 0x23， 0x45， SUM， XOR， 0x0D

　　其中0x55， 0xAA， 0x7E為數據幀的幀頭，0x0D為幀尾，0x12為設備的目的地址，0xF0為源地址，0x02為數據長度，后面接著兩個數據0x23，

　　0x45，從目的地址開始結算累加、異或校驗和，到數據的最后一位結束。

　　協議解析的目的，首先判斷數據包的完整性，正確性，然后提取數據類型，數據等數據，存放起來用于主程序處理。代碼如下：if（state_machine == 0） // 協議解析狀態機{

　　if（rcvdat == 0x55） // 接收到幀頭第一個數據 state_machine = 1; else

　　state_machine = 0; // 狀態機復位}

　　else if（state_machine == 1）{

　　if（rcvdat == 0xAA） // 接收到幀頭第二個數據 state_machine = 2; else

　　state_machine = 0; // 狀態機復位}

　　else if（state_machine == 2）{

　　if（rcvdat == 0x7E） // 接收到幀頭第三個數據 state_machine = 3; else

　　state_machine = 0; // 狀態機復位

　　過程中，使用了一個變量state_machine作為協議狀態機的轉換狀態，用于確定當前字節處于一幀數據中的那個部位，同時在接收過程中自動對接收數據進行校驗和處理，在數據包接收完的同時也進行了校驗的比較。因此當幀尾結束符接收到的時候，則表示一幀數據已經接收完畢，并且通過了校驗，關鍵數據也保存到了緩沖去中。主程序即可通過retval的標志位來進行協議的解析處理。

　　接收過程中，只要哪一步收到的數據不是預期值，則直接將狀態機復位，用于下一幀數據的判斷，因此系統出現狀態死鎖的情況非常少，系統比較穩定，如果出現丟失數據包的情況也可由上位機進行命令的補發，不過這種情況筆者還沒有碰到。

　　對于主程序中進行協議處理的過程與此類似，主程序循環中不斷的讀取串口緩沖區的數據，此數據即參與到主循環中的協議處理過程中，代碼與上面所述完全一樣。

　　4．上位機中的數據接收和命令處理

　　上位機中數據接收的過程與下位機可以做到完全一致，不過針對不同的串口操作方法有所不同。對于阻賽式的串口讀函數，例如直接進行API操作或者調用windows的串口通信控件，最好能夠開啟一個線程專門用于監視串口的數據接收，每接收到一個數據可以向系統發送一個消息。筆者常用的CSerialPort類中就是這樣的處理過程。CSerialPort打開串口后開啟線程監視串口的數據接收，將接收的數據保存到緩沖區，并向父進程發送接收數據的消息，數據將隨消息一起發送到父進程。父進程中開啟此消息的處理函數，從中獲取串口數據后就可以把以上的代碼拷貝過來使用。

　　CSerialPort向父類發送的消息號如下：

　　#define WM_COMM_RXCHAR WM_USER+7 // A character was received and placed in the input buffer.

　　因此需要手動添加此消息的響應函數：

　　afx_msg LONG OnCommunication（WPARAM ch， LPARAM port）; ON_MESSAGE（WM_COMM_RXCHAR， OnCommunication） 響應函數的具體代碼如下：

　　LONG CWellInfoView：：OnCommunication（WPARAM ch， LPARAM port）{

　　int retval = 0;

　　rcvdat = （BYTE）ch;

　　if（state_machine == 0） // 協議解析狀態機 {

　　if（rcvdat == 0x55） // 接收到幀頭第一個數據 state_machine = 1; else

　　state_machine = 0; // 狀態機復位 }

　　else if（state_machine == 1） {

　　if（rcvdat == 0xAA） // 接收到幀頭第二個數據 state_machine = 2; else

　　state_machine = 0; // 狀態機復位 。。。。。.5．總結

　　以上給出的是通信系統運作的基本雛形，雖然簡單，但是可行。實際的通信系統中協議比這個要復雜，而且涉及到數據包響應、命令錯誤、延時等等一系列的問題，在這樣的一個基礎上可以克服這些困難并且實現出較為穩定可靠的系統。