通用可靠的串口／以太網(wǎng)網(wǎng)關(guān)設(shè)計(jì)＊

徐良，陳向東

（西南交通大學(xué)信息科學(xué)與技術(shù)學(xué)院，成都610031）

引 言

隨著物聯(lián)網(wǎng)的蓬勃發(fā)展，越來越多的傳統(tǒng)本地設(shè)備或網(wǎng)絡(luò)有接入計(jì)算機(jī)網(wǎng)絡(luò)的需求，而這些傳統(tǒng)設(shè)備一般都是不具備網(wǎng)絡(luò)接口的非IP設(shè)備。最常用的通信接口是串口，不能直接接入計(jì)算機(jī)網(wǎng)絡(luò)，在不改變這些原有設(shè)備的基礎(chǔ)上，使用串口／以太網(wǎng)網(wǎng)關(guān)來接入計(jì)算機(jī)網(wǎng)絡(luò)的方式不失為一種比較好的解決方案。

基于此需求，設(shè)計(jì)和實(shí)現(xiàn)了串口／以太網(wǎng)網(wǎng)關(guān)，網(wǎng)絡(luò)結(jié)構(gòu)如圖1所示。實(shí)現(xiàn)了非IP設(shè)備與IP設(shè)備間的數(shù)據(jù)通信，并特別考慮了串口通信的可靠性，從軟件和硬件兩方面詳細(xì)討論了保證串口通信可靠性的方法。IP端通信的可靠性由TCP／IP協(xié)議保證，這樣就保證了串口設(shè)備與IP設(shè)備間通信的可靠性。

圖1 網(wǎng)絡(luò)結(jié)構(gòu)

1 網(wǎng)關(guān)工作原理

1.1 概 述

網(wǎng)關(guān)實(shí)現(xiàn)串口設(shè)備和以太網(wǎng)之間的協(xié)議轉(zhuǎn)換，具體表現(xiàn)為幀格式的轉(zhuǎn)換，可表示為:

Socket幀?凈荷數(shù)據(jù)?串口幀

其中Socket（套接字）幀和串口幀都是為實(shí)現(xiàn)網(wǎng)關(guān)可靠通信而自定義格式的幀，凈荷數(shù)據(jù)為真正需要傳送的應(yīng)用數(shù)據(jù)。

網(wǎng)關(guān)的數(shù)據(jù)通信可分為兩部分:網(wǎng)絡(luò)端和串口端，要保證整個(gè)網(wǎng)關(guān)通信的可靠性，那么就要分別保證網(wǎng)絡(luò)端和串口端通信的可靠性。

在網(wǎng)絡(luò)端，網(wǎng)關(guān)使用了流式套接字。流式套接字使用TCP協(xié)議，而TCP協(xié)議是面向連接的，保證了數(shù)據(jù)傳輸?shù)恼_性和順序性。所以，流式的套接字可以提供可靠的、面向連接的通信流。但是，流式數(shù)據(jù)對(duì)應(yīng)用來說不易使用，所以Socket數(shù)據(jù)傳送都是基于幀格式的。

在串口端，串口數(shù)據(jù)傳送本質(zhì)上也是字節(jié)流式的，在硬件層次是不可靠的，而且不能保證數(shù)據(jù)的完整性，需要在軟件上有一些其他機(jī)制來保證可靠性。所以，網(wǎng)關(guān)串口的數(shù)據(jù)傳送同樣基于幀格式，并且使用了接收確認(rèn)、超時(shí)重發(fā)、差錯(cuò)校驗(yàn)等機(jī)制來保證可靠性。

圖2為網(wǎng)關(guān)工作時(shí)的數(shù)據(jù)流示意圖。圖中3個(gè)帶箭頭的橢圓表示3個(gè)線程，圖中未畫出建立Socket連接、串口初始化和線程啟動(dòng)等過程。

圖2 網(wǎng)關(guān)數(shù)據(jù)流示意圖

1.2 串口數(shù)據(jù)傳送

串口數(shù)據(jù)傳送的幀格式如下:

字節(jié)數(shù)1 1 1 1可變1 1字段SFD Seq.Type LEN Data FCS EFD

其中各個(gè)字段的意義如下:

◆SFD:幀首定界符；

◆EFD:幀尾定界符，SFD和EFD為確定的特定值；

◆Seq.:幀序號(hào)；

◆Type:幀類型，其值見表1；

◆LEN:Data字段的字節(jié)數(shù)；

◆Data:實(shí)際要傳送的數(shù)據(jù)；

◆FCS:幀校驗(yàn)，是一個(gè)簡(jiǎn)單校驗(yàn)，為Seq.至Data字段中所有字節(jié)按位異或運(yùn)算的結(jié)果。

表1 串口幀類型

1.2.1 串口發(fā)送

串口發(fā)送隊(duì)列示意圖如圖3所示。網(wǎng)關(guān)使用FIFO（先入先出）隊(duì)列緩沖發(fā)送幀，包括待發(fā)送隊(duì)列和待確認(rèn)隊(duì)列兩個(gè)隊(duì)列，每個(gè)隊(duì)列為一個(gè)雙向循環(huán)鏈表，節(jié)點(diǎn)從尾部插入，頭部讀出。

圖3 串口發(fā)送隊(duì)列示意圖

當(dāng)有數(shù)據(jù)需要從串口發(fā)送時(shí)，首先將要發(fā)送的數(shù)據(jù)按幀格式加上一些附加的字段組成一個(gè)完整的幀，然后插入待發(fā)送隊(duì)列尾。插入待發(fā)送隊(duì)列的幀并不一定會(huì)被立即發(fā)送，但只要待發(fā)送隊(duì)列中緩沖有需要發(fā)送的幀，串口就會(huì)從隊(duì)列頭逐個(gè)的讀取待發(fā)送幀以中斷的方式發(fā)送，直到待發(fā)送隊(duì)列為空。

每一幀發(fā)送完畢后，如果是確認(rèn)幀，便會(huì)被立即從待發(fā)送隊(duì)列中刪除并釋放掉內(nèi)存，該幀的發(fā)送過程結(jié)束；如果是非確認(rèn)幀，即數(shù)據(jù)幀或命令幀，那么該幀不會(huì)被立即釋放，而是從待發(fā)送隊(duì)列刪除而插入待確認(rèn)隊(duì)列尾，等待串口另一端的設(shè)備發(fā)送對(duì)應(yīng)的確認(rèn)幀。

若在超時(shí)時(shí)間內(nèi)收到對(duì)應(yīng)的確認(rèn)幀，則將該幀從待確認(rèn)隊(duì)列刪除釋放，該幀的發(fā)送過程結(jié)束；若等待超時(shí)，則將該幀從待確認(rèn)刪除并重新插入待發(fā)送隊(duì)列尾，以重發(fā)此幀。當(dāng)然有重發(fā)次數(shù)限制，若達(dá)到了最大重發(fā)次數(shù)仍然未收到對(duì)應(yīng)的確認(rèn)幀，則丟棄該幀，該幀的發(fā)送過程結(jié)束。

1.2.2 串口接收

串口接收使用中斷方式，從串口接收到的字節(jié)數(shù)據(jù)并不直接處理，而是先存入一個(gè)環(huán)形緩沖，環(huán)形緩沖示意圖如圖4所示。從頭偏移處寫入，從尾偏移處讀出，每寫入或讀出一字節(jié)頭或尾都將模遞增，且頭偏移處為空，尾偏移處為滿。

只要串口接收到數(shù)據(jù)，就將其從頭偏移處寫入串口的環(huán)形緩沖。如果緩沖滿了，則用新數(shù)據(jù)覆蓋未處理的舊數(shù)據(jù)。

在將一個(gè)字節(jié)數(shù)據(jù)寫入緩沖的同時(shí)，判斷其是否等于幀結(jié)束定界符EFD，如果等于，則表示緩沖中可能存在一個(gè)完整的幀（只是可能，并不能完全確定，因?yàn)橐粋€(gè)普通的字節(jié)數(shù)據(jù)完全有可能正好等于EFD），此時(shí)便可從環(huán)形緩沖中按幀格式解析數(shù)據(jù)。若解析到完整的幀，則做相應(yīng)的處理:首先，根據(jù)幀中FCS字段做差錯(cuò)校驗(yàn)，如果校驗(yàn)正確，則從串口回送一個(gè)同序號(hào)的確認(rèn)幀；然后從幀中取出凈荷數(shù)據(jù)從Socket發(fā)送。

圖4 環(huán)形緩沖示意圖

從緩沖中解析數(shù)據(jù)的過程簡(jiǎn)述如下:從環(huán)形緩沖的尾偏移處開始讀字節(jié)數(shù)據(jù)，查驗(yàn)是否等于幀開始定界符SFD，若不等于則丟棄并繼續(xù)讀下一字節(jié)，若等于則向后偏移讀取長(zhǎng)度域LEN，根據(jù)長(zhǎng)度值，便能確定幀結(jié)束定界符EFD的位置。查驗(yàn)此位置的字節(jié)數(shù)據(jù)，若不等于EFD，則認(rèn)為之前等于SFD的字節(jié)只是個(gè)普通數(shù)據(jù)，并不是幀開始定界符，將其丟棄并繼續(xù)讀取查驗(yàn)下一字節(jié)；若等于EFD，則認(rèn)為SFD到EFD之間為一個(gè)完整的幀。

1.3 Socket數(shù)據(jù)傳送

Socket數(shù)據(jù)傳送的幀格式如下:

字節(jié)數(shù)1 1可變1 SFD LEN Data EFD字段

相比串口幀格式，少了Seq.、Type和FCS字段。這三個(gè)字段在串口數(shù)據(jù)傳送中是用來保證可靠性的，而網(wǎng)關(guān)使用TCP Socket，下層的TCP協(xié)議會(huì)保證通信的可靠性，應(yīng)用層只需要保證數(shù)據(jù)的完整性，所以不需要這些字段。其他字段相同，意義也分別相同。

1.3.1 Socket發(fā)送

Socket接收過程同串口接收類似，接收的數(shù)據(jù)并不直接處理，而是先存入環(huán)形緩沖。然后，按Socket幀格式，解析環(huán)形緩沖中的數(shù)據(jù)。解析到的數(shù)據(jù)幀插入串口發(fā)送隊(duì)列，從串口轉(zhuǎn)發(fā)。

1.3.2 Socket接收

Socket發(fā)送相比串口發(fā)送操作更簡(jiǎn)單，因?yàn)橄聦拥腡CP協(xié)議會(huì)保證通信的可靠性，所以不需要再另外實(shí)現(xiàn)確認(rèn)、重發(fā)等機(jī)制，發(fā)送隊(duì)列中只需要一個(gè)待發(fā)送隊(duì)列即可，不需要待確認(rèn)隊(duì)列。而且在具體實(shí)現(xiàn)中，并沒有真的構(gòu)造一個(gè)Socket發(fā)送隊(duì)列，而是利用了操作系統(tǒng)提供的線程間通信機(jī)制中的郵箱通信方式，需要從Socket發(fā)送數(shù)據(jù)時(shí)，只需將數(shù)據(jù)的首地址以郵件的方式發(fā)送到Socket發(fā)送線程指定的郵箱中。

2 網(wǎng)關(guān)實(shí)現(xiàn)

2.1 軟硬件平臺(tái)

網(wǎng)關(guān)軟硬件平臺(tái)包括操作系統(tǒng)RT－Thread和ARM9開發(fā)板Mini2440。

2.1.1 RT－Thread實(shí)時(shí)操作系統(tǒng)［1－3］

為實(shí)現(xiàn)網(wǎng)關(guān)，選用了實(shí)時(shí)操作系統(tǒng)RT－Thread。RTThread是一款國內(nèi)的開源實(shí)時(shí)操作系統(tǒng)，并且商業(yè)許可證非常寬松，由國內(nèi)一些專業(yè)開發(fā)人員開發(fā)、維護(hù)。RTThread不僅是一款高效、穩(wěn)定的實(shí)時(shí)核心，也是一套面向嵌入式系統(tǒng)的軟件平臺(tái)，覆蓋了全搶占的實(shí)時(shí)操作系統(tǒng)內(nèi)核小巧的文件系統(tǒng)、輕型的TCP／IP協(xié)議棧以及輕型的圖形用戶界面。

圖5是RT－Thread及外圍組件的基本框架圖。RTThread的使用范圍極為靈活，可以從資源極度緊張的小型系統(tǒng)到帶內(nèi)存管理單元、網(wǎng)絡(luò)功能的基本計(jì)算單元。RT－Thread有著高度可配置、易裁減、可擴(kuò)展性好和可靠性高等特點(diǎn)，適用于嵌入式實(shí)時(shí)系統(tǒng)。

圖5 RT－Thread基本框架圖

2.1.2 Mini2440開發(fā)板

硬件平臺(tái)使用了Mini2440開發(fā)板，Mini2440是一款A(yù)RM9開發(fā)板，微處理器采用三星公司的S3C2440芯片，具有64MB SDRAM、128MB／256MB／1GB大小可選的NAND Flash和2MB NOR Flash，外設(shè)包括1個(gè)100M以太網(wǎng)RJ－45口（采用DM9000網(wǎng)卡）和3個(gè)串口等。

2.2 網(wǎng)關(guān)實(shí)現(xiàn)

2.2.1 軟件相關(guān)

如圖2所示，系統(tǒng)使用了3個(gè)線程:串口接收線程、Socket發(fā)送線程和Socket接收線程，下面對(duì)這3個(gè)線程作具體介紹:

①串口接收線程。以阻塞的方式接收“UART＿RX＿IRQ＿EVENT”事件，接收到此事件后，從串口環(huán)形接收緩沖中解析串口幀，當(dāng)有數(shù)據(jù)幀需要向以太網(wǎng)發(fā)送時(shí)，便將該數(shù)據(jù)幀的首地址以郵件的方式給Socket發(fā)送線程。而在RT－Thread中，郵件的存儲(chǔ)方式本質(zhì)是雙向循環(huán)隊(duì)列。

②Socket發(fā)送線程。以阻塞的方式接收來自串口接收線程的指針郵件，接收到此類郵件后，Socket發(fā)送線程將指針指向的數(shù)據(jù)封裝成Socket幀發(fā)送。

③Socket接收線程。用于從以太網(wǎng)接收數(shù)據(jù)，并緩存解析數(shù)據(jù)幀，調(diào)用串口發(fā)送接口函數(shù)，將收到的數(shù)據(jù)幀封裝成串口幀并插入串口發(fā)送隊(duì)列。

串口收／發(fā)工作于中斷方式，可以連續(xù)發(fā)送串口發(fā)送隊(duì)列中緩存的待發(fā)送幀和從串口接收字節(jié)數(shù)據(jù)并寫入串口的環(huán)形接收緩存。在接收到等于EFD的字節(jié)時(shí)，向串口接收線程發(fā)送一個(gè)“UART＿RX＿IRQ＿EVENT”事件，通知串口接收線程環(huán)形緩存中可能存在一個(gè)完整的幀。

串口幀發(fā)送完畢后等待確認(rèn)幀的時(shí)間計(jì)時(shí)使用了RT－Thread提供的定時(shí)器，并且在定時(shí)器的超時(shí)函數(shù)中處理幀重發(fā)問題。

在軟件實(shí)現(xiàn)過程中遇到了一個(gè)問題:在RT－Thread操作系統(tǒng)的中斷程序中不能申請(qǐng)和釋放動(dòng)態(tài)內(nèi)存，而串口中斷發(fā)送程序在發(fā)送完一個(gè)幀后，如果該幀是確認(rèn)幀或非確認(rèn)幀但達(dá)到了最大發(fā)送次數(shù)，那么需要從待發(fā)送隊(duì)列刪除該幀并釋放對(duì)應(yīng)的動(dòng)態(tài)內(nèi)存。這就存在矛盾，系統(tǒng)不能提供中斷程序釋放內(nèi)存的功能，但實(shí)際應(yīng)用又需要此功能。

為此，程序中專門設(shè)置了一個(gè)刪除隊(duì)列，當(dāng)中斷程序需要釋放發(fā)送幀時(shí)，將對(duì)應(yīng)幀插入刪除隊(duì)列，并向串口接收線程發(fā)送一個(gè)刪除事件“UART＿TX＿DEL＿EVENT”，在串口接收線程中接收到此事件后再來釋放隊(duì)列中的幀，這就避免了在串口發(fā)送中斷程序中直接釋放動(dòng)態(tài)內(nèi)存。

2.2.2 硬件相關(guān)

在硬件方面，為提高串口通信的可靠性，也做了相應(yīng)處理。

S3C2440微處理器的串口具有兩種工作模式［4］:非FIFO模式和FIFO模式。在FIFO模式中，串口發(fā)送和接收分別具有64字節(jié)的硬件FIFO緩沖，使用硬件緩沖，能顯著地減少串口發(fā)送和接收中斷產(chǎn)生的次數(shù)，進(jìn)而減小正常程序被中斷的頻率，提高系統(tǒng)性能。并且使用接收FIFO后，在處理器不能及時(shí)跳轉(zhuǎn)到串口接收中斷程序的情況下，由于硬件FIFO的存在，使得串口數(shù)據(jù)丟失的可能性減小。所以，網(wǎng)關(guān)中S3C2440微處理器的串口使用了FIFO模式。

另外，S3C2440微處理器的串口還具有硬件自動(dòng)流控制功能［3］，當(dāng)與網(wǎng)關(guān)相連的串口設(shè)備也具有硬件自動(dòng)流控制功能時(shí)，開啟此功能。在開啟此功能的情況下，當(dāng)通信的某一端不能及時(shí)讀取接收緩沖中的數(shù)據(jù)時(shí)，硬件自動(dòng)流控制能自動(dòng)暫停另一端串口的數(shù)據(jù)發(fā)送，以防止數(shù)據(jù)的丟失。

在網(wǎng)關(guān)的軟件實(shí)現(xiàn)中，確認(rèn)機(jī)制的開關(guān)、確認(rèn)超時(shí)時(shí)間、重發(fā)次數(shù)、隊(duì)列容量、緩沖的大小、串口的FIFO設(shè)置和硬件流控制的開關(guān)等都是可配置的，針對(duì)不同的應(yīng)用可以非常容易地做出合適的裁剪和設(shè)置。

結(jié) 語

目前該網(wǎng)關(guān)被用于一個(gè)無線體溫監(jiān)測(cè)項(xiàng)目，以連接本地?zé)o線傳感網(wǎng)絡(luò)和遠(yuǎn)程數(shù)據(jù)庫服務(wù)器，實(shí)現(xiàn)本地設(shè)備對(duì)遠(yuǎn)程數(shù)據(jù)庫服務(wù)器的訪問，通過實(shí)際運(yùn)行實(shí)驗(yàn)，網(wǎng)關(guān)能很好地實(shí)現(xiàn)本文講述的功能。當(dāng)然，網(wǎng)關(guān)仍然有不盡完善之處，比如對(duì)有些公共資源的訪問沒有提供競(jìng)爭(zhēng)保護(hù)機(jī)制，可能會(huì)影響網(wǎng)關(guān)運(yùn)行的穩(wěn)定性和可靠性，有待今后進(jìn)一步完善。

［1］RT－Thread工作室.RT－Thread實(shí)時(shí)操作系統(tǒng)編程指南，2010.

［2］邱祎.嵌入式實(shí)時(shí)操作系統(tǒng)RT－Thread的設(shè)計(jì)與實(shí)現(xiàn)［D］.成都:電子科技大學(xué)，2007.

［3］Samsung Electronics.S3C2440A32－BIT CMOS MICROCONTROLLER USER'S MANUAL，2004.