在網(wǎng)絡應用日益普遍的今天，越來越多的嵌入式設(shè)備實現(xiàn)Ｉｎｔｅｒｎｅｔ網(wǎng)絡化。ＴＣＰ／ＩＰ協(xié)議是一種目前被廣泛采用的網(wǎng)絡協(xié)議。嵌入式Ｉｎｔｅｒｎｅｔ的技術(shù)核心是在嵌入式系統(tǒng)中部分或完整地實現(xiàn)ＴＣＰ／ＩＰ協(xié)議。由于ＴＣＰ／ＩＰ協(xié)議比較復雜，而目前嵌入式系統(tǒng)中大量應用低速處理器，受內(nèi)存和速度限制，有必要將ＴＣＰ／ＩＰ協(xié)議簡化。

圖1 協(xié)議處理

１ ＴＣＰ／ＩＰ協(xié)議的實現(xiàn)

嵌入式ＴＣＰ／ＩＰ協(xié)議一般實現(xiàn)：ＡＲＰ／ＲＡＲＰ、ＩＰ、ＩＣＭＰ、ＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ、ＦＴＰ、ＴＥＬＮＥＴ等協(xié)議，協(xié)議處理的主要流程如圖１所示。

１．１ ＴＣＰ協(xié)議的實現(xiàn)

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

ＴＣＰ協(xié)議數(shù)據(jù)傳輸可分為三個階段：建立連接、傳輸數(shù)據(jù)和斷開連接。它的實現(xiàn)過程可以用狀態(tài)機來描述。建立連接有兩種方法，即主動打開和被動打開。服務器端是一種被動打開，它一直在偵聽連接請求；而客戶端是一種主動打開，它發(fā)送連接請求以建立連接。研究發(fā)現(xiàn)，如果ＴＣＰ層的上層實現(xiàn)服務器端的應用，可以將標準ＴＣＰ狀態(tài)機建立連接過程中客戶端建立連接的狀態(tài)機部分簡化掉。同理，如果應用是基于客戶端的，可以將服務器端建立連接的狀態(tài)機部分簡化掉。斷開連接有兩種方式：一是主動斷開連接；另一是被動斷開連接。被動斷開連接的處理較為簡單，但標準ＴＣＰ協(xié)議的主動斷開連接的狀態(tài)機部分過于復雜。經(jīng)過實驗發(fā)現(xiàn)，在需要主動斷開連接的時候，發(fā)送一個Ｆｉｎ數(shù)據(jù)報；接收到對Ｆｉｎ數(shù)據(jù)報的確認后，再發(fā)送一個Ｒｅｓｅｔ數(shù)據(jù)報，即可順利完成一次主動斷開連接。

標準的ＴＣＰ協(xié)議使用慢啟動的滑動窗口機制?；瑒哟翱谑且环N在流量控制和網(wǎng)絡傳輸效率之間折中的方案。它允許發(fā)送方在等待一個確認之前發(fā)送多個窗口，其確認是一種批量的確認。研究滑動窗口協(xié)議發(fā)現(xiàn)，滑動窗口的一個極限情況，是只使用單個窗口，就變成了一種簡單確認的處理方法。使用該方法后，所有的處理只是對單個數(shù)據(jù)報的發(fā)送和確認，節(jié)約了系統(tǒng)的資源，也使維護更加方便。為了協(xié)議的兼容性，需要通信的另一方也使用簡單確認方法。因為如果對方使用較大的窗口，就可能造成處理器被淹沒。這個問題可以通過設(shè)置待發(fā)送數(shù)據(jù)報的ＴＣＰ頭部的Ｗｉｎｄｏｗｓ字段的大小解決。

在上述基礎(chǔ)上，簡化實現(xiàn)ＴＣＰ協(xié)議的流程圖如圖２所示。其中“不同狀態(tài)的相應處理”指根據(jù)接收到的ＴＣＰ報文準備待發(fā)送數(shù)據(jù)報并將其發(fā)送到以太網(wǎng)上。這部分根據(jù)ＴＣＰ所處的不同狀態(tài)，所做的處理是不一樣的。

１．２ ＩＰ協(xié)議

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

    １．３ 其它協(xié)議

ＡＲＰ協(xié)議為３２位ＩＰ地址到對應的４８位以太網(wǎng)地址之間提供動態(tài)映射。嵌入式系統(tǒng)中僅響應ＡＲＰ請求，發(fā)送ＡＲＰ回答包。請求者廣播出包含ＡＲＰ請求的以太幀、目的以太網(wǎng)地址為全１的廣播地址。本機收到后，由目的ＩＰ地址發(fā)現(xiàn)自己是目的主機，發(fā)送一個ＡＲＰ回答。ＩＣＭＰ通過ＩＰ協(xié)議傳輸其報文。ＩＰ協(xié)議是無連接的，它無法將報文和錯誤信息傳到最初的主機，ＩＣＭＰ將狀態(tài)信息和錯誤信息發(fā)送到發(fā)報文的主機。

２ 前端設(shè)備的系統(tǒng)設(shè)計

ＴＣＰ／ＩＰ協(xié)議擴展到工業(yè)控制級，將企業(yè)內(nèi)部計算機網(wǎng)絡應用于工業(yè)現(xiàn)場實時信息的發(fā)布和顯示，通過Ｉｎｔｅｒｎｅｔ瀏覽器對現(xiàn)場工業(yè)信息進行動態(tài)監(jiān)視。下面是筆者在某公司一分布式監(jiān)控系統(tǒng)中的應用實例?；冢裕茫校桑袇f(xié)議的前端設(shè)備系統(tǒng)軟件結(jié)構(gòu)如圖３。前端嵌入式設(shè)備處理器是Ｓａｍｓｕｎｇ公司的Ｓ３Ｃ４５１０Ｂ（ＡＲＭ核）。該芯片是用在基于以太網(wǎng)系統(tǒng)的高性價比、高性能的１６／３２位ＲＩＳＣ微控制器。通信部分采用ＢＮＣ接口方式，信號輸出經(jīng)耦合隔離變壓器由ＲＪ４５接頭聯(lián)入集線器，此外還設(shè)計了液晶顯示和鍵盤輸入當?shù)亟涌诠δ堋?/P>

在ＴＣＰ／ＩＰ協(xié)議中多處用到超時和重發(fā)機制。這種機制對于確保兩個或多個彼此獨立的通信結(jié)點從通信錯誤或故障狀態(tài)自動恢復到正常狀態(tài)是非常有效的，但也增加了軟件結(jié)構(gòu)的復雜性。因為對超時的處理通常獨立于正常程序流程，也就是與正常的程序流程異步。要實現(xiàn)的ＴＣＰ／ＩＰ協(xié)議軟件中有四處要用到定時器：第一是在ＡＲＰ高速緩存的維護中，被添加到ＡＲＰ高速緩存中的表項在一段時間后要置為無效；第二是在等待對發(fā)出的ＡＲＰ請求返回響應時，可能會在指定的超時時間內(nèi)還未收到返回的響應；第三是在ＩＰ組裝收到分片時，由于部分分片在一定時間內(nèi)沒有收到而丟棄整個ＩＰ包；第四是在ＴＣＰ等待接收方對數(shù)據(jù)段的確認時。如果在指定時間內(nèi)還未收到對某個數(shù)據(jù)段的確認，需重新發(fā)送。從上述可見，要實現(xiàn)的定時器具備以下特點：

·對定時的精度要求都不是很高，基本都是秒級的精度。這樣，完全可以稍滯后一些來處理定時器超時，不把超時處理放在時鐘中斷處理程序中。

    ·對同一類超時處理可以由同一處理程序來完成，只是傳入到相應的處理程序中的參數(shù)不同而已。例如一個ＡＲＰ高速緩存中的表項超時時，需要將其置為無效，可以統(tǒng)一用一個處理程序，參數(shù)中放入相應的表項地址即可。

首先，定義一定時器的數(shù)據(jù)結(jié)構(gòu)，如圖４所示。每一類超時都是由一個超時控制塊和其所屬的一個由超時事件項組成的鏈表管理。整個鏈表按超時事件將要發(fā)生的時間順序排列，先發(fā)生的超時事件排列在前。超時控制塊中的ｈｅａｄ＿ｐｔｒ用以指向一個超時事件項鏈表的首項；ｔｉｍｅｏｕｔ＿ｐｒｏｃｅｓｓ是超時事件發(fā)生時處理程序的入口地址。在每個超時事件項中，ｎｅｘｔ＿ｐｔｒ指向鏈表中的下一項；ｒｅｌａｔｉｖｅ＿ｔｉｍｅ是本表項的超時事件相對于上一表項的超時事件發(fā)生的相對時間。所以某個表項表示的超時事件距離當前的時間是它以前所有表項（包括自身）中的ｒｅｌａｔｉｖｅ＿ｔｉｍｅ的和。ｒｅｌａｔｉｖｅ＿ｔｉｍｅ的基本單位是ｇｒａｎｕｌａｒｉｔｙ。

    定時器任務使用一個信號量作同步。信號量有兩個變量：ｃｏｕｎｔ和ｗａｉｔｉｎｇ＿ｔａｓｋ。ｃｏｕｎｔ對事件計數(shù)，當ｃｏｕｎｔ大于０時，表示有ｃｏｕｎｔ個事件發(fā)生并等待處理；當ｃｏｕｎｔ小于０時，表示有某個任務在等待事件的發(fā)生，此時ｗａｉｔｉｎｔ＿ｔａｓｋ保存相應任務控制塊的地址。信號量有兩個操作：ｓｅｍ＿ｕｐ和ｓｅｍ＿ｄｏｗｎ。ｓｅｍ＿ｕｐ首先使ｃｏｕｎｔ加１，然后看ｃｏｕｎｔ是否為０，若為０表示有任務在等待，通過ｗａｉｔｉｎｇ＿ｔａｓｋ中記錄的任務控制塊的地址把等待任務的狀態(tài)設(shè)為就緒，否則返回。ｓｅｍ＿ｄｏｗｎ首先使ｃｏｕｎｔ減１然后看ｃｏｕｎｔ是否小于０，若小于０會使當前任務成為等待狀態(tài)并引發(fā)任務管理器對任務的調(diào)度，否則返回。

每當時鐘中斷服務程序計數(shù)到ｇｒａｎｕｌａｒｉｔｙ個時鐘中斷，給定時器任務使用的信號燈作ｓｅｍ＿ｕｐ操作。當定時器任務被調(diào)度執(zhí)行時，它遍歷每一個超時控制塊，對每一個超時控制塊作如圖５所示的處理，最后對信號燈調(diào)用ｓｅｍ＿ｄｏｗｎ。