- 相關(guān)推薦
基于ARM的嵌入式TCP/IP協(xié)議的實現(xiàn)
摘要:介紹嵌入式TCP/IP協(xié)議在低速處理器中的一種簡化實現(xiàn)方案,并成功應(yīng)用于某分布式監(jiān)控系統(tǒng)中。關(guān)鍵詞:TCP/IP協(xié)議嵌入式ARM
在網(wǎng)絡(luò)應(yīng)用日益普遍的今天,越來越多的嵌入式設(shè)備實現(xiàn)Internet網(wǎng)絡(luò)化。TCP/IP協(xié)議是一種目前被廣泛采用的網(wǎng)絡(luò)協(xié)議。嵌入式Internet的技術(shù)核心是在嵌入式系統(tǒng)中部分或完整地實現(xiàn)TCP/IP協(xié)議。由于TCP/IP協(xié)議比較復(fù)雜,而目前嵌入式系統(tǒng)中大量應(yīng)用低速處理器,受內(nèi)存和速度限制,有必要將TCP/IP協(xié)議簡化。
圖1協(xié)議處理
。保裕茫校桑袇f(xié)議的實現(xiàn)
嵌入式TCP/IP協(xié)議一般實現(xiàn):ARP/RARP、IP、ICMP、TCP、UDP、HTTP、SMTP、FTP、TELNET等協(xié)議,協(xié)議處理的主要流程如圖1所示。
1.1TCP協(xié)議的實現(xiàn)
工業(yè)控制領(lǐng)域傳輸層采用TCP協(xié)議、不用UDP協(xié)議,是考慮到實時監(jiān)控系統(tǒng)中傳輸量并不大,而可靠性要求較高。TCP協(xié)議是面向連接的、端對端的可靠通信協(xié)議。它采用了許多機制來保證可靠傳輸,應(yīng)用于嵌入式系統(tǒng)顯得過于復(fù)雜。
。裕茫袇f(xié)議數(shù)據(jù)傳輸可分為三個階段:建立連接、傳輸數(shù)據(jù)和斷開連接。它的實現(xiàn)過程可以用狀態(tài)機來描述。建立連接有兩種方法,即主動打開和被動打開。服務(wù)器端是一種被動打開,它一直在偵聽連接請求;而客戶端是一種主動打開,它發(fā)送連接請求以建立連接。研究發(fā)現(xiàn),如果TCP層的上層實現(xiàn)服務(wù)器端的應(yīng)用,可以將標(biāo)準(zhǔn)TCP狀態(tài)機建立連接過程中客戶端建立連接的狀態(tài)機部分簡化掉。同理,如果應(yīng)用是基于客戶端的,可以將服務(wù)器端建立連接的狀態(tài)機部分簡化掉。斷開連接有兩種方式:一是主動斷開連接;另一是被動斷開連接。被動斷開連接的處理較為簡單,但標(biāo)準(zhǔn)TCP協(xié)議的主動斷開連接的狀態(tài)機部分過于復(fù)雜。經(jīng)過實驗發(fā)現(xiàn),在需要主動斷開連接的時候,發(fā)送一個Fin數(shù)據(jù)報;接收到對Fin數(shù)據(jù)報的確認(rèn)后,再發(fā)送一個Reset數(shù)據(jù)報,即可順利完成一次主動斷開連接。
標(biāo)準(zhǔn)的TCP協(xié)議使用慢啟動的滑動窗口機制;瑒哟翱谑且环N在流量控制和網(wǎng)絡(luò)傳輸效率之間折中的方案。它允許發(fā)送方在等待一個確認(rèn)之前發(fā)送多個窗口,其確認(rèn)是一種批量的確認(rèn)。研究滑動窗口協(xié)議發(fā)現(xiàn),滑動窗口的一個極限情況,是只使用單個窗口,就變成了一種簡單確認(rèn)的處理方法。使用該方法后,所有的處理只是對單個數(shù)據(jù)報的發(fā)送和確認(rèn),節(jié)約了系統(tǒng)的資源,也使維護(hù)更加方便。為了協(xié)議的兼容性,需要通信的另一方也使用簡單確認(rèn)方法。因為如果對方使用較大的窗口,就可能造成處理器被淹沒。這個問題可以通過設(shè)置待發(fā)送數(shù)據(jù)報的TCP頭部的Windows字段的大小解決。
在上述基礎(chǔ)上,簡化實現(xiàn)TCP協(xié)議的流程圖如圖2所示。其中“不同狀態(tài)的相應(yīng)處理”指根據(jù)接收到的TCP報文準(zhǔn)備待發(fā)送數(shù)據(jù)報并將其發(fā)送到以太網(wǎng)上。這部分根據(jù)TCP所處的不同狀態(tài),所做的處理是不一樣的。
1.2IP協(xié)議
。桑袇f(xié)議是TCP/IP的基礎(chǔ),為不同網(wǎng)絡(luò)的主機之間發(fā)送數(shù)據(jù)報的操作序列提供無連接服務(wù)。通過在數(shù)據(jù)報前添加IP協(xié)議頭,使每個數(shù)據(jù)報具有尋址能力。嵌入式系統(tǒng)只把IP作為傳輸工具,進(jìn)行簡化以完成主要的操作。得到IP包后,檢驗IP頭部的版本、目的地址、校驗和正確否,解析出協(xié)議類型字段,由此交給相應(yīng)的高層協(xié)議處理。發(fā)送IP包時,將緩沖區(qū)內(nèi)的源地址與目的地址互換,設(shè)置校驗和,然后交給下層協(xié)議處理。不符合要求,則將此包丟棄。IP包最大可以為65KB,可以分段傳輸,而在嵌入式系統(tǒng)里根本無法容納如此大的數(shù)據(jù)包,因此一般不支持分段傳輸。所以限制MCU發(fā)送和接收數(shù)據(jù)包的方式以避免分段傳輸,從而減少程序復(fù)雜度。
。保称渌鼌f(xié)議
。粒遥袇f(xié)議為32位IP地址到對應(yīng)的48位以太網(wǎng)地址之間提供動態(tài)映射。嵌入式系統(tǒng)中僅響應(yīng)ARP請求,發(fā)送ARP回答包。請求者廣播出包含ARP請求的以太幀、目的以太網(wǎng)地址為全1的廣播地址。本機收到后,由目的IP地址發(fā)現(xiàn)自己是目的主機,發(fā)送一個ARP回答。ICMP通過IP協(xié)議傳輸其報文。IP協(xié)議是無連接的,它無法將報文和錯誤信息傳到最初的主機,ICMP將狀態(tài)信息和錯誤信息發(fā)送到發(fā)報文的主機。
。睬岸嗽O(shè)備的系統(tǒng)設(shè)計
TCP/IP協(xié)議擴(kuò)展到工業(yè)控制級,將企業(yè)內(nèi)部計算機網(wǎng)絡(luò)應(yīng)用于工業(yè)現(xiàn)場實時信息的發(fā)布和顯示,通過Internet瀏覽器對現(xiàn)場工業(yè)信息進(jìn)行動態(tài)監(jiān)視。下面是筆者在某公司一分布式監(jiān)控系統(tǒng)中的應(yīng)用實例;冢裕茫校桑袇f(xié)議的前端設(shè)備系統(tǒng)軟件結(jié)構(gòu)如圖3。前端嵌入式設(shè)備處理器是Samsung公司的S3C4510B(ARM核)。該芯片是用在基于以太網(wǎng)系統(tǒng)的高性價比、高性能的16/32位RISC微控制器。通信部分采用BNC接口方式,信
號輸出經(jīng)耦合隔離變壓器由RJ45接頭聯(lián)入集線器,此外還設(shè)計了液晶顯示和鍵盤輸入當(dāng)?shù)亟涌诠δ堋?br />
在TCP/IP協(xié)議中多處用到超時和重發(fā)機制。這種機制對于確保兩個或多個彼此獨立的通信結(jié)點從通信錯誤或故障狀態(tài)自動恢復(fù)到正常狀態(tài)是非常有效的,但也增加了軟件結(jié)構(gòu)的復(fù)雜性。因為對超時的處理通常獨立于正常程序流程,也就是與正常的程序流程異步。要實現(xiàn)的TCP/IP協(xié)議軟件中有四處要用到定時器:第一是在ARP高速緩存的維護(hù)中,被添加到ARP高速緩存中的表項在一段時間后要置為無效;第二是在等待對發(fā)出的ARP請求返回響應(yīng)時,可能會在指定的超時時間內(nèi)還未收到返回的響應(yīng);第三是在IP組裝收到分片時,由于部分分片在一定時間內(nèi)沒有收到而丟棄整個IP包;第四是在TCP等待接收方對數(shù)據(jù)段的確認(rèn)時。如果在指定時間內(nèi)還未收到對某個數(shù)據(jù)段的確認(rèn),需重新發(fā)送。從上述可見,要實現(xiàn)的定時器具備以下特點:
·對定時的精度要求都不是很高,基本都是秒級的精度。這樣,完全可以稍滯后一些來處理定時器超時,不把超時處理放在時鐘中斷處理程序中。
·對同一類超時處理可以由同一處理程序來完成,只是傳入到相應(yīng)的處理程序中的參數(shù)不同而已。例如一個ARP高速緩存中的表項超時時,需要將其置為無效,可以統(tǒng)一用一個處理程序,參數(shù)中放入相應(yīng)的表項地址即可。
首先,定義一定時器的數(shù)據(jù)結(jié)構(gòu),如圖4所示。每一類超時都是由一個超時控制塊和其所屬的一個由超時事件項組成的鏈表管理。整個鏈表按超時事件將要發(fā)生的時間順序排列,先發(fā)生的超時事件排列在前。超時控制塊中的head_ptr用以指向一個超時事件項鏈表的首項;timeout_process是超時事件發(fā)生時處理程序的入口地址。在每個超時事件項中,next_ptr指向鏈表中的下一項;relative_time是本表項的超時事件相對于上一表項的超時事件發(fā)生的相對時間。所以某個表項表示的超時事件距離當(dāng)前的時間是它以前所有表項(包括自身)中的relative_time的和。relative_time的基本單位是granularity。
定時器任務(wù)使用一個信號量作同步。信號量有兩個變量:count和waiting_task。count對事件計數(shù),當(dāng)count大于0時,表示有count個事件發(fā)生并等待處理;當(dāng)count小于0時,表示有某個任務(wù)在等待事件的發(fā)生,此時waitint_task保存相應(yīng)任務(wù)控制塊的地址。信號量有兩個操作:sem_up和sem_down。sem_up首先使count加1,然后看count是否為0,若為0表示有任務(wù)在等待,通過waiting_task中記錄的任務(wù)控制塊的地址把等待任務(wù)的狀態(tài)設(shè)為就緒,否則返回。sem_down首先使count減1然后看count是否小于0,若小于0會使當(dāng)前任務(wù)成為等待狀態(tài)并引發(fā)任務(wù)管理器對任務(wù)的調(diào)度,否則返回。
每當(dāng)時鐘中斷服務(wù)程序計數(shù)到granularity個時鐘中斷,給定時器任務(wù)使用的信號燈作sem_up操作。當(dāng)定時器任務(wù)被調(diào)度執(zhí)行時,它遍歷每一個超時控制塊,對每一個超時控制塊作如圖5所示的處理,最后對信號燈調(diào)用sem_down。
【基于ARM的嵌入式TCP/IP協(xié)議的實現(xiàn)】相關(guān)文章:
基于ARM-μCLinux嵌入式系統(tǒng)啟動引導(dǎo)的實現(xiàn)08-06
在TMS320VC5402上實現(xiàn)的嵌入式TCP/IP協(xié)議棧08-06
基于ARM平臺的MAC協(xié)議IP核設(shè)計08-06
基于混合TCP-UDP的HTTP協(xié)議實現(xiàn)方法08-06
基于ARM的IEEE802.11bMAC層協(xié)議IP核設(shè)計08-06
TCP/IP協(xié)議棧在嵌入式異構(gòu)網(wǎng)絡(luò)互聯(lián)中的應(yīng)用08-06
用GNU工具開發(fā)基于ARM的嵌入式系統(tǒng)08-06