1.閑話閑聊

最重要的寫在前面：用戶層通信協議就是數據包格式！！！ 沒有進行串口通訊實踐的朋友可能會想：為什么要編制用戶通信協議呢？通信過程中為什么要進行數據處理呢？在設計中編過串口通信程序的讀者應該張口就可以回答：為了按規定格式從串口發送數據，也為了從接收到的數據中將需要的信息提取出來。 串口通信協議一般可以從兩個角度來思考：底層通信協議和用戶層協議。底層協議一般有計算機硬件提供商和設備廠家提供，在一般性的通信編程中很少會涉及（我估計1000個搞通信的，能編底層的也就那么1,2個），而用戶層協議則是面向使用者的，也就是我們在編程中通常談到的通信協議。這種用戶層的通信協議，簡單來說，就是數據以何種格式發送出去，或者說如何從接收到的某種格式的數據中提取需要的數據，以及在發送和接收過程中如何保證這些數據的正確性，即數據校驗。 這片帖子先扯扯為什么要編？原理是什么？現存的協議有什么？這些基本問題，為后面逐步深入奠定基礎。

2.為什么要編制用戶通信協議？

大多數MFC等界面開發數據都已經準備好了，只需做一個可視化工作就可以了。可是實際很多工作可不是這樣，我們需要實時采集并處理顯示數據。舉例子說，我們剛入門做通信編程時，大多時候只是從串口接收數據，并顯示在GUI窗口上。然而我們卻忽略了一個非常關鍵的細節：如何從接收到的數據中提取有用的信息？如何處理我們發送出去的數據？這些問題才是我們進行通信編程的目標所在，也就是說，通信協議才是對接軟件與硬件交流的關鍵！ 在大多數編程實踐中，接收與發送數據并不需要直接顯示在程序界面中，而只是需要將對我們有價值的幾個數據顯示，或者根本就沒有必要進行顯示，而是直接在程序內部進行處理。這是，數據發送方與數據接收方就必須事先約好數據發送的格式。當然，我說的這個數據發送格式的約定實際上就是數據通信協議！

3.有感而發——談談GPS模塊的數據接收過程

GPS：Global Positioning System 近年來，GPS系統已經在大地繪制、海上漁用、車輛定位監控、建筑、農業等各個領域得到廣泛應用。目前，市場上的大部分GPS接收模塊都是通過RS-232串口與PC/MCU進行數據傳輸。這些數據包括了經度、緯度、時間、衛星使用情況等基本信息。我們需要從GPS接收模塊發送出來的數據中提取出我們要用的信息，比如最簡單的定位信息（只用到了經緯信息）。因此，我們就必須了解從GPS模塊獲得的信息，并進行數據挑選。 例如，從GPS接收模塊得到的定位信息如下： $GPGGA,hhmmss,dddmm,mmmm,a,dddmm,mmmm,a,x,xx,x.x,x.x,M,,M,x.x,xxxx,*hh<CR><LF> 這實際上是NMEA-0183無線通信輸出格式(National Marine Electronics Association, NMEA, 美國海洋電子協會)。每次都會發出像上面格式的一個數據串，更多的時候我們都把這個字符串稱為一個數據包。

• $是包頭，GPGGA是包名；
• hhmmss,dddmm,mmmm,a,dddmm,mmmm,a,x,xx,x.x,x.x,M,,M,x.x,xxxx是數據內容；
  
• *是指包尾；
  
• hh為校驗位；
  
• <CR>是回車符，ASCII碼值為13；
  
• <LF>是換行符，ASCII碼值為10。

這里加上回車符和換行符，只是為了方便調試。 下面對這個包進行實例化： $GPGGA,033744,2446.5241,N，12100.1536,E,1,10,0.8,133.4,M, , , ,*1F 在我們實際定位的系統中，并不能夠顯示這些數據就足夠了，我們還需要實時將有關的數據提取出來，或者在程序中使用，或者提供給第三方。為了提取出“有用的”信息，我們必須要知道該數據包的格式定義。具體解釋如下：

知道了GPS的數據通信協議格式，我們便可以得到相應的位置信息：北緯24度46.5241分、東經121度00.1536分、格林威治時間03點37分44秒、定位衛星編號10。 其實，這種GPS必須遵循的數據描述格式就稱為通信用戶協議，這種協議一般一方單獨建立就好，另一方只需要依據這樣的協議來進行數據接收與發送就好！ 這其實也能深刻地解釋為什么我們要編制用戶協議。

4.串口通信中用戶層協議編制原理

在串口用戶層的通信協議中，一般是圍繞發送方如何建立數據包和接收方如何處理數據包，并從數據包中提取出我們關心的信息。通信協議也為這個事兒進行服務。實際上，用戶層的通信協議沒有那么嚴謹，隨意一點就好......但是，還是有那么幾個原則需要我們嚴格遵守：

4.1 數據包必須有包頭

包頭是供接收方判斷一個數據包開始傳輸的重要標志，接收方從收到的數據中判斷接收到了包頭，就認為接收的數據已經開始，真正的數據信息馬上就會到達。但是，我們必須要切記一點，包頭字符必須有別于數據信息，也就是說，這種特征是數據包中其他數據沒有的，否則會造成混亂。

4.2 非定長數據必須有包尾

這個很少用，用也很好理解

4.3 定長數據應該指明長度

對于長度不變的數據包，數據長度應該事先約定。這樣接收方在知道接受長度之后，就能夠判斷接收的數據包是否結束。

4.4 建議對數據進行校驗

串口通信底層協議(機器硬件實現)已經設置了奇偶檢驗方式。其實，如果在用戶層添加新的校驗，可以對數據進行進一步的排錯，這樣可以更好地保證數據的正確性。

4.5 換行符的使用

如果是要顯示數據，前列推薦在數據包的結尾添加換行符，方便閱讀接收到的數據。然而，如果僅把接收到的數據作為基礎數據，那就沒有必要了......

4.6 如果更新快的數據，建議盡量簡短

如果要求數據更新快，就要讓每次傳輸的數據盡量短。

5.在串口通信中幾種常用的用戶層協議

在常見的用戶層協議中，按照輸出數據的可讀性可以分為完整性協議和簡單型協議，NMEA-0183無線通信輸出協議，包含了包頭、數據，包尾、校驗、換行，而且數據之間還有逗號分隔，觀察數據非常方便。但是數據包長度增加，發送時間也會增加，這在很多更新快的場合是不合適的；簡單型協議則去掉了在程序中不需要利用的換行與分隔符，有時甚至連校驗也省略了。

5.1 NMEA-0183無線通信協議

5.2 自定義的通信協議

自定義通信協議可以設置的非常簡單，也可以為了查看方便，設置得比較復雜。簡單的協議一般需要傳送的信息比較簡單，而且沒必要直接進行觀察。 以四字節組成的通信協議為例，進行深入研究：



這個簡單的例子，可以說明，僅僅是4個字節的通信協議就可以傳送大量的信息，而且還加入了校驗，在實際的應用中，我們還是應該進行協議的擴充！

6.總結

在實際應用中，我們能看到各種協議，但是它們的實質都是一樣的。首先，對數據進行“打包”發送；然后接收方，對數據進行“拆包”。進而對數據包中的數據進行處理，或是提取有用的數據，或是進行編碼翻譯，這也是下一部分，將要討論的話題。

總結

以上是生活随笔為你收集整理的我也聊聊串口通信协议：用户层通信协议的编制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。