一種基于A(yíng)RM的嵌入式TCP/IP協(xié)議的簡(jiǎn)化方案

　　摘要：介紹嵌入式TCP/IP協(xié)議在低速處理器中的一種簡(jiǎn)化實(shí)現方案，并成功應用于某分布式監控系統中。

　　關(guān)鍵詞：TCP/IP協(xié)議 嵌入式

　　ARM 在網(wǎng)絡(luò )應用日益普遍的今天，越來(lái)越多的嵌入式設備實(shí)現Internet網(wǎng)絡(luò )化。TCP/IP協(xié)議是一種目前被廣泛采用的網(wǎng)絡(luò )協(xié)議。嵌入式Internet的技術(shù)核心是在嵌入式系統中部分或完整地實(shí)現TCP/IP協(xié)議。由于TCP/IP協(xié)議比較復雜，而目前嵌入式系統中大量應用低速處理器，受內存和速度限制，有必要將TCP/IP協(xié)議簡(jiǎn)化。 圖1 協(xié)議處理 1 TCP/IP協(xié)議的實(shí)現 嵌入式TCP/IP協(xié)議一般實(shí)現：ARP/RARP、IP、ICMP、TCP、UDP、HTTP、SMTP、FTP、TELNET等協(xié)議，協(xié)議處理的主要流程如圖1所示。

　　1.1 TCP協(xié)議的實(shí)現

　　工業(yè)控制領(lǐng)域傳輸層采用TCP協(xié)議、不用UDP協(xié)議，是考慮到實(shí)時(shí)監控系統中傳輸量并不大，而可靠性要求較高。TCP協(xié)議是面向連接的、端對端的可靠通信協(xié)議。它采用了許多機制來(lái)保證可靠傳輸，應用于嵌入式系統顯得過(guò)于復雜。

　　TCP協(xié)議數據傳輸可分為三個(gè)階段：建立連接、傳輸數據和斷開(kāi)連接。它的實(shí)現過(guò)程可以用狀態(tài)機來(lái)描述。建立連接有兩種方法，即主動(dòng)打開(kāi)和被動(dòng)打開(kāi)。服務(wù)器端是一種被動(dòng)打開(kāi)，它一直在偵聽(tīng)連接請求;而客戶(hù)端是一種主動(dòng)打開(kāi)，它發(fā)送連接請求以建立連接。研究發(fā)現，如果TCP層的上層實(shí)現服務(wù)器端的應用，可以將標準TCP狀態(tài)機建立連接過(guò)程中客戶(hù)端建立連接的狀態(tài)機部分簡(jiǎn)化掉。同理，如果應用是基于客戶(hù)端的，可以將服務(wù)器端建立連接的狀態(tài)機部分簡(jiǎn)化掉。斷開(kāi)連接有兩種方式：一是主動(dòng)斷開(kāi)連接;另一是被動(dòng)斷開(kāi)連接。被動(dòng)斷開(kāi)連接的處理較為簡(jiǎn)單，但標準TCP協(xié)議的主動(dòng)斷開(kāi)連接的狀態(tài)機部分過(guò)于復雜。經(jīng)過(guò)實(shí)驗發(fā)現，在需要主動(dòng)斷開(kāi)連接的時(shí)候，發(fā)送一個(gè)Fin數據報;接收到對Fin數據報的確認后，再發(fā)送一個(gè)Reset數據報，即可順利完成一次主動(dòng)斷開(kāi)連接。 標準的TCP協(xié)議使用慢啟動(dòng)的滑動(dòng)窗口機制?；瑒?dòng)窗口是一種在流量控制和網(wǎng)絡(luò )傳輸效率之間折中的方案。它允許發(fā)送方在等待一個(gè)確認之前發(fā)送多個(gè)窗口，其確認是一種批量的確認。研究滑動(dòng)窗口協(xié)議發(fā)現，滑動(dòng)窗口的一個(gè)極限情況，是只使用單個(gè)窗口，就變成了一種簡(jiǎn)單確認的處理方法。使用該方法后，所有的處理只是對單個(gè)數據報的發(fā)送和確認，節約了系統的資源，也使維護更加方便。為了協(xié)議的兼容性，需要通信的另一方也使用簡(jiǎn)單確認方法。因為如果對方使用較大的窗口，就可能造成處理器被淹沒(méi)。這個(gè)問(wèn)題可以通過(guò)設置待發(fā)送數據報的TCP頭部的Windows字段的大小解決。 在上述基礎上，簡(jiǎn)化實(shí)現TCP協(xié)議的流程圖如圖2所示。其中“不同狀態(tài)的相應處理”指根據接收到的TCP報文準備待發(fā)送數據報并將其發(fā)送到以太網(wǎng)上。這部分根據TCP所處的不同狀態(tài)，所做的處理是不一樣的。

　　1.2 IP協(xié)議

　　IP協(xié)議是TCP/IP的基礎，為不同網(wǎng)絡(luò )的主機之間發(fā)送數據報的操作序列提供無(wú)連接服務(wù)。通過(guò)在數據報前添加IP協(xié)議頭，使每個(gè)數據報具有尋址能力。嵌入式系統只把IP作為傳輸工具，進(jìn)行簡(jiǎn)化以完成主要的操作。得到IP包后，檢驗IP頭部的版本、目的地址、校驗和正確否，解析出協(xié)議類(lèi)型字段，由此交給相應的高層協(xié)議處理。發(fā)送IP包時(shí)，將緩沖區內的源地址與目的地址互換，設置校驗和，然后交給下層協(xié)議處理。不符合要求，則將此包丟棄。IP包最大可以為65KB，可以分段傳輸，而在嵌入式系統里根本無(wú)法容納如此大的數據包，因此一般不支持分段傳輸。所以限制MCU發(fā)送和接收數據包的方式以避免分段傳輸，從而減少程序復雜度。

　　1.3 其它協(xié)議

　　ARP協(xié)議為32位IP地址到對應的48位以太網(wǎng)地址之間提供動(dòng)態(tài)映射。嵌入式系統中僅響應ARP請求，發(fā)送ARP回答包。請求者廣播出包含ARP請求的以太幀、目的以太網(wǎng)地址為全1的廣播地址。本機收到后，由目的IP地址發(fā)現自己是目的主機，發(fā)送一個(gè)ARP回答。ICMP通過(guò)IP協(xié)議傳輸其報文。IP協(xié)議是無(wú)連接的，它無(wú)法將報文和錯誤信息傳到最初的主機，ICMP將狀態(tài)信息和錯誤信息發(fā)送到發(fā)報文的主機。

　　2 前端設備的系統設計

　　TCP/IP協(xié)議擴展到工業(yè)控制級，將企業(yè)內部計算機網(wǎng)絡(luò )應用于工業(yè)現場(chǎng)實(shí)時(shí)信息的發(fā)布和顯示，通過(guò)Internet瀏覽器對現場(chǎng)工業(yè)信息進(jìn)行動(dòng)態(tài)監視。下面是筆者在某公司一分布式監控系統中的應用實(shí)例?；赥CP/IP協(xié)議的前端設備系統軟件結構如圖3。前端嵌入式設備處理器是Samsung公司的S3C4510B(ARM核)。該芯片是用在基于以太網(wǎng)系統的高性?xún)r(jià)比、高性能的16/32位RISC微控制器。通信部分采用BNC接口方式，信號輸出經(jīng)耦合隔離變壓器由RJ45接頭聯(lián)入集線(xiàn)器，此外還設計了液晶顯示和鍵盤(pán)輸入當地接口功能。 在TCP/IP協(xié)議中多處用到超時(shí)和重發(fā)機制。這種機制對于確保兩個(gè)或多個(gè)彼此獨立的通信結點(diǎn)從通信錯誤或故障狀態(tài)自動(dòng)恢復到正常狀態(tài)是非常有效的，但也增加了軟件結構的復雜性。因為對超時(shí)的處理通常獨立于正常程序流程，也就是與正常的程序流程異步。要實(shí)現的TCP/IP協(xié)議軟件中有四處要用到定時(shí)器：第一是在A(yíng)RP高速緩存的維護中，被添加到ARP高速緩存中的表項在一段時(shí)間后要置為無(wú)效;第二是在等待對發(fā)出的ARP請求返回響應時(shí)，可能會(huì )在指定的超時(shí)時(shí)間內還未收到返回的響應;第三是在IP組裝收到分片時(shí)，由于部分分片在一定時(shí)間內沒(méi)有收到而丟棄整個(gè)IP包;第四是在TCP等待接收方對數據段的確認時(shí)。如果在指定時(shí)間內還未收到對某個(gè)數據段的確認，需重新發(fā)送。從上述可見(jiàn)，要實(shí)現的定時(shí)器具備以下特點(diǎn)： 對定時(shí)的精度要求都不是很高，基本都是秒級的精度。這樣，完全可以稍滯后一些來(lái)處理定時(shí)器超時(shí)，不把超時(shí)處理放在時(shí)鐘中斷處理程序中。

　　對同一類(lèi)超時(shí)處理可以由同一處理程序來(lái)完成，只是傳入到相應的處理程序中的參數不同而已。例如一個(gè)ARP高速緩存中的表項超時(shí)時(shí)，需要將其置為無(wú)效，可以統一用一個(gè)處理程序，參數中放入相應的表項地址即可。 首先，定義一定時(shí)器的數據結構，如圖4所示。每一類(lèi)超時(shí)都是由一個(gè)超時(shí)控制塊和其所屬的一個(gè)由超時(shí)事件項組成的鏈表管理。整個(gè)鏈表按超時(shí)事件將要發(fā)生的時(shí)間順序排列，先發(fā)生的超時(shí)事件排列在前。超時(shí)控制塊中的head_ptr用以指向一個(gè)超時(shí)事件項鏈表的首項;timeout_process是超時(shí)事件發(fā)生時(shí)處理程序的入口地址。在每個(gè)超時(shí)事件項中，next_ptr指向鏈表中的下一項;relative_time是本表項的超時(shí)事件相對于上一表項的超時(shí)事件發(fā)生的相對時(shí)間。所以某個(gè)表項表示的超時(shí)事件距離當前的時(shí)間是它以前所有表項(包括自身)中的relative_time的和。relative_time的基本單位是granularity。

　　定時(shí)器任務(wù)使用一個(gè)信號量作同步。信號量有兩個(gè)變量：count和waiting_task。count對事件計數，當count大于0時(shí)，表示有count個(gè)事件發(fā)生并等待處理;當count小于0時(shí)，表示有某個(gè)任務(wù)在等待事件的發(fā)生，此時(shí)waitint_task保存相應任務(wù)控制塊的地址。信號量有兩個(gè)操作：sem_up和sem_down。sem_up首先使count加1，然后看count是否為0，若為0表示有任務(wù)在等待，通過(guò)waiting_task中記錄的任務(wù)控制塊的地址把等待任務(wù)的狀態(tài)設為就緒，否則返回。sem_down首先使count減1然后看count是否小于0，若小于0會(huì )使當前任務(wù)成為等待狀態(tài)并引發(fā)任務(wù)管理器對任務(wù)的調度，否則返回。 每當時(shí)鐘中斷服務(wù)程序計數到granularity個(gè)時(shí)鐘中斷，給定時(shí)器任務(wù)使用的信號燈作sem_up操作。當定時(shí)器任務(wù)被調度執行時(shí)，它遍歷每一個(gè)超時(shí)控制塊，對每一個(gè)超時(shí)控制塊作如圖5所示的處理，最后對信號燈調用sem_down。