摘 要:為了保證單片機系統遠程數據傳輸的可靠性和穩定性,在開發實際應用的基礎上,提出一種分層設計的數據傳輸協議。協議分三層,接入層很好地解決了不同通信方式下的工作,網絡層能夠解決不同網絡結構中傳輸多種結構數據的情況,數據對象的組成方式可以較大地提高數據的傳輸效率。在用于移動通信直放站設備的監控系統中的結果表明,協議工作穩定且具有較高的傳輸效率。
關鍵詞:單片機系統;數據傳輸協議;分層結構;協議實現
中圖分類號:TP302文獻標識碼:A
文章編號:1004-373X(2010)06-047-04
Design and Implementation of Single Chip Microcomputer Remote Data Transmission Protocol
DAI Zhichao,XIANG Ying
(Guangdong Polytechnic Normal University,Guangzhou,510665,China)
Abstract: To ensure reliability and stability of the system′s remote data transmission,a remote data transmission protocol is proposed based on a hierarchical design.The protocol is divided into three layers,access layer is a good solution for the different model of communication.Network layer can solve variety of data structures transmission and different network transmission.Composition of the data objects can greatly enhance the efficiency ofdata transmission.In the monitoring system of mobile communication repeater equipments,results show that the protocol works stable and has a high transmission efficiency.
Keywords:single chip system;data transmission protocol;hierarchical structure;protocol implementation
文件傳送協議(File Transfer Protocol,FTP)和簡單文件傳輸協議(Trivial File Transfer Protocol,TFTP)是因特網上使用最廣泛的文件傳輸協議[1],但其代碼所占的內存空間和運行的速度要求均較高,不適合單片機系統。由于單片機系統的存儲空間和運行速度都有限,需要設計一種適合單片機系統的數據遠程傳輸協議,以保證其遠程文件傳輸的可靠性和穩定性。
遠程通信一般采用串行通信。在單片機系統中常用的串行通信有RS 232,RS 485等[2]。單片機可以通過連接GSM Modem,經GSM網絡實現遠程通信,也可以通過嵌入TCP/IP協議棧或連接到具有TCP/IP協議棧的無線Modem接入Internet實現遠程通信[3]。本文討論的協議可以工作在上述提到的所有連接方式。
1 通信協議的結構設計
根據可靠通信所需要解決的問題性質,分層設計通信協議,把不同類型的問題劃分在不同層解決,各層之間相對獨立。分層設計,結構性好,方便實現軟件的模塊化,具有較好的通用性和可移植性[1]。該協議從下往上分別為:接入層、網絡層和應用層。
1.1 接入層
在遠程通信中單片機系統可以通過GSM網絡采用短信、數傳方式[4],也可以通過增加TCP/IP協議棧采用Ethernet通信方式[5],所以需引入“接入層”來解決其通信方式的差異。
一個完整的接入層協議幀由起始標志、協議類型、承載協議類型、數據單元、校驗單元[6]、結束標志等六部分組成,如表1所示。
表1 接入層數據幀結構
起始標志協議類型承載協議類型數據單元校驗單元結束標志
1 B1 B1 Bn B2 B1 B
起始標志[1] 表示一個數據幀的起始標志,可以選擇Ox7E。
協議類型 標識接入層協議的類型,該單元由采用的通信方式決定。采用不同的通信方式,相應可以采用不同的處理方式。
承載協議類型 標識所承載的網絡層類型。根據單片機的網絡情況,在網絡層采取相應的處理方式。
數據單元 接入層協議的有效載荷。
校驗單元 校驗一個數據幀是否出錯。可以采用CRC校驗,生成多項式可選擇ITU推薦的0x11021。
結束標志 表示一個數據幀的結束標志。與起始標志一樣選擇Ox7E。
1.2 網絡層
考慮到實際應用中有多個單片機連接成一網絡情況,其中一個作為主機,負責與上位機通信。主機接收到數據后,根據分機地址把數據分發到各分機。再通過“網絡層”屏蔽單片機網絡結構的差異。
一個完整的網絡層協議幀由地址單元[7]、數據幀編號、網絡層交互標志、數據單元四部分組成,如表2所示。
表2 網絡層數據幀結構
地址單元數據幀編號網絡層交互標志數據單元
2 B1 B1 Bn B
地址單元 由主節點編號和分節點兩部分組成。這樣上位機所連接的單片機可以看成是一個獨立的主機或是有多個分機的網絡。
數據幀編號 由發起通信的一端生成序號,標識不同的數據幀。
網絡層交互標志 網絡層的處理標志用于兩個實體在網絡層間信息的互通,是網絡層的處理命令或應答。
數據單元 網絡層協議的有效載荷。
1.3 應用層
上位機與單片機的通信包括傳輸各種命令和數據,應用層的功能是標識傳輸的命令或數據類型。
一個完整的應用層協議幀由命令標識、應答標志和數據單元組成。如表3所示。
表3 應用層數據幀結構
命令標識應答標志數據單元
1 B1 Bn B
命令標識 各種控制指令的唯一標識。
應答標志 數據接收方對接收的指令執行情況的標識。
數據單元 應用層協議的有效載荷。
1.4 數據對象
上位機與單片機之間大多數傳輸的是簡短數據(比如設備的參數),如果一個數據幀只傳輸一個參數會使通信效率很低。為了提高通信效率可以采用一個數據幀傳輸多個簡短數據方式。
事先把所有需要傳送的數據分類,不同的數據分配不同的對象編號,每個數據對象包括對象長度、對象編號、對象內容。數據對象的組成如表4所示。
表4 數據對象組成
對象長度對象編號對象內容
1 B1 Bn B
對象長度 表示該數據對象從“對象長度”到“對象內容”的字節數。
對象編號 表示該數據的類型/名稱。對每個不同類型數據分配唯一的編號。
對象內容 表示該數據的內容。
1.5 協議的數據幀完整結構
完整的數據幀結構如圖1所示。
圖1 協議數據幀結構
2 協議實現
2.1 協議所適合的系統結構
該協議適合在單片機之間、上位機與單片機之間、單片機主機與分機之間進行通信[8]。該協議可以工作在圖2所示的系統結構,也可以是該結構的部分。
圖2 協議適合的系統結構
2.2 透明傳輸
透明傳輸是指不管所傳數據是什么樣的比特組合,都應當能夠在鏈路上傳送。在該設計中只要避免數據幀中出現與起始標志或結束標志相同的字節,即可實現透明傳輸。處理方法主要有特殊字符填充法或ASCII拆分處理法[9]。
特殊字符填充法是將數據幀中(除了起始和結束標志外)出現的0x7E字節轉變成兩個字節系列(0x7D,0x5E),若數據幀中出現0x7D字節,則將其轉變成兩個字節系列(0x7D,0x5D)。該方法可以避免數據幀中出現與起始或結束標志相同的字節0x7E,并且需要填充的字節不會很多,有較高的傳輸效率。
ASCII拆分處理是將數據幀中(除了起始和結束標志外)所有字節拆分成兩部分(高4 b與低4 b),分別用ASCII碼表示這兩部分。例如,0x5A拆分為0x35與0x3A兩個字節。該方法會使傳輸的數據幀字節數加倍,降低數據的傳輸效率,只有在特殊情況下使用。
2.3 數據幀校驗算法
CRC計算得到的校驗碼有很高的數據查錯能力,采用16 b的序列能檢測出任何位置上三個以內的錯誤,所有的奇數個錯誤,16個比特之內的連續錯誤以及大部分的大量突發錯誤[9]。
CRC計算有比特法、字節查表法和半字節查表法。考慮到單片機運算速度和內存空間的限制,半字節查表法是最佳的選擇。以下是用C語言實現的半字節查表法計算幀校驗碼(多項式選用ITU推薦的0x11021):
unsigned cal_crc(unsigned char * ByteStream,unsigned char len) {
unsigned int CRC_code;
unsigned char byte_up;
unsigned int crc_table ={
0x0000,0x1021,0x2042,0x3063,0x4084,0x50a5,0x60c6,0x70e7,
0x8108,0x9129,0xa14a,0xb16b,0xc18c,0xd1ad,0xe1ce,0xf1ef,
}//半字節的CRC碼表
crc=0;
while(len--!=0) {
byte_up=(uchar) (CRC_code/256 /16);// 求CRC的高4 b
byte_tmp=byte_up ^ (*ByteStream / 16);// CRC的高4 b與當前輸入字節的前4 b求異或
CRC_tmp=crc_table;//通過查表求得該字節的CRC碼
CRC_code=(CRC_code<<4) ^ CRC_tmp;//求得4 b的CRC碼
byte_up=(uchar) (CRC_code/256/16);// 再求CRC的4 b
byte_tmp=byte_up ^ (*ByteStream 0x0f);// CRC的4 b與當前輸入字節的后4 b求異或
CRC_tmp=crc_table;//通過查表求得該字節的CRC碼
CRC_code=(CRC_code<<4) ^ CRC_tmp;//求得一個字節的CRC碼
ByteStream ++;//字節流指針加1,指向下個字節,準備求下個字節的CRC碼
}
return(CRC_code);
}
2.4 數據的可靠傳輸
為了使數據的傳輸可靠,數據幀的傳輸采用確認和重傳機制[10]。通信發起方發送數據幀時啟動定時器,接收方收到數據幀時利用數據幀的“校驗單元”校驗該幀數據是否出錯,并利用“數據幀序號”檢查該數據幀的順序是否正確,如果是正確幀,則收下并回復確認信息,如果是錯誤幀,則丟棄該幀并回復否認信息;如果在定時器超時之前沒有收到應答,則理解為該幀丟失,發送方重傳該幀。
2.5 數據幀發送與接收流程
為了提高數據的傳輸效率,采用連續ARQ(Automatic Repeat reQuest)協議,根據滑動窗口概念[1],在該設計中,將接收窗口定為1,發送窗口大小則根據內存空間和通信鏈路選取。 圖3是數據幀發送主流程圖;圖4是數據幀接收主流程圖。
圖3 數據幀發送主流程圖
圖4 數據幀接收主流程圖
2.6 串行通信的數據接收
根據單片機的內存空間大小劃出一塊存貯空間專門存儲接收的數據,設定讀寫指針,首尾地址相連形成一個環形緩存。單片機采用中斷接收數據,到達的數據立刻寫入環形緩存中。數據幀讀取模塊再從環形緩存中逐幀讀取出數據進行相應處理。圖5是接收中斷程序的流程圖,圖6是從環形緩存(接收緩存)中讀取數據幀的流程圖。根據以上協議,數據幀的最小長度為13 B。當環形緩存中寫入的字節數大于或等于13 B時,可以從緩存中讀取數據幀,當讀指針與寫指針重疊時,表示環形緩存空(無空間可寫),當寫指針在讀指針后一字節時,表示環形緩存滿(無空間可寫)。
2.7 報文處理流程
數據幀在發送方按協議要求封裝后,從一個主節點(或上位機)發給另一個主節點(如果目的地址是分節點的,則再由該主節點轉發給分節點)。
接收方從環形緩存中讀取出一幀數據后,做相應分析處理(自己處理或轉發給分節點),圖7是接收方數據幀處理流程。
數據發送方在收到接收方的應答后也會根據應答內容做相應處理,圖8是數據發送方對應答數據幀的處理流程。
圖5 接收中斷程序流程圖
圖6 從環形緩沖讀取數據幀流程圖
圖7 接收方數據幀處理流程
2.8 一個簡單的主程序設計
圖9是一個簡單的主程序流程圖,包含了前面描述的“數據幀封裝”、“數據幀發送”、“從環形緩存中讀取數據幀”、“數據幀解析處理”等模塊。
圖8 數據發送方對應答數據幀的處理流程
圖9 主程序流程圖
3 結 語
協議采用分層設計,接入層涵蓋了不同類型的通信方式;網絡層可以使協議工作在包含主機和分機的單片機所組成的網絡中;應用層的設計可以使協議適合傳送較大的文件數據;數據對象的組成方式能夠讓協議在傳送簡短數據時,使一個數據幀包含多個短數據,提高了數據的傳輸效率。
該協議具有適用面廣,易于實現等優點。在對移動通信直放站設備的監控和系統文件傳輸中適合采用該設計,設備可工作在包括樓頂、野外、隧道等環境較差地方,且可全天候工作,采用連接方式包括GSM網絡的數傳、短信、GPRS接入Internet等。在數百臺設備中,監控數據和系統文件的傳送均有較高的傳輸效率,且工作穩定可靠。
參考文獻
[1]謝希仁.計算機網絡[M].北京:電子工業出版社,2005.
[2]潘超群.單片機控制技術在通信中的應用[M].北京:電子工業出版社,2008.
[3]吉順平,陸宇平.基于UDP/IP 的工業以太網絡通信協議的設計[J].信息與控制,2008,37(5):560-564.
[4]馮建勤,馮巧玲,魏云冰,等.基于短信技術的電機轉子溫度在線監測(Ⅱ)[J].電力自動化設備,2008,28(11):105-108.
[5]何小衛,王愛華,馬躍.基于GPRS的GPS車載終端通信技術研究[J].計算機應用,2008,28(11):2 952-2 954.
[6]Javvin Technologies Co.Ltd..Network Protocols Handbook[M].北京:清華大學出版社,2005.
[7]李朝青,劉艷玲.單片機與PC機網絡通信技術[M].北京:北京航空航天大學出版社,2007.
[8]吉順平,陸宇平.一類工業以太網絡通信協議的設計與性能分析[J].小型微型計算機系統,2008,29(12):2 224-2 228.
[9]陳顯治.現代通信技術[M].北京:電子工業出版社,2001.
[10]王晶,樊曉椏,曹清.一種基于Petri網通信協議的分析和驗證[J].計算機應用,2005,25(1):165-167.