基于OMAP的嵌入式TCP/IP開發

隨著人們對智能化產品需求的增加，未來的嵌入式產品，包括各種家電、通信、pda、儀器儀表等設備正逐漸走向網絡化，以共享互聯網中龐大的信息資源，因此使嵌入式設備的網絡化開發有廣闊市場前景，由于嵌入式硬件資源有限，而傳統的tcp/ip等網絡通信協議對計算機存儲器、運算速度的要求較高，所以不能直接應用，為此，必須開發一套適合嵌入式系統的、高度優化的、最為精簡的tcp/ip協議棧。

開放式多媒體應用平臺omap（open multimedia application platform）是美國德州儀器公司推出的高度集成的軟硬件平臺。omap具有獨特的雙芯結構，結合了dsp與risc內核，可為無線多媒體設備提供獨一無二的性能和功耗優勢，omap可連接十分豐富的外圍設備，包括usb、攝像頭、聲音設備、視頻設備、網絡設備等，omap擁有開放式體系結構，其應用環境完全可編程。

軟件協議的設計與實現在很大深度上決定了通信終端的質量，基于omap的3g移動終端軟件協議結構由信令協議棧和應用業務協議棧組成，如圖1所示，tcp/ip協議棧位于應用業務協議棧的底層，為上層的h.323協議棧提供基礎與服務，其性能質量將直接決定整個通信終端軟件系統的運行質量。因此，針對嵌入式系統聯網的發展方向，為omap系統其設計一套高效、簡潔的tcp/ip協議，對其應用具有十分重要的意義。

1 開發方案

pc上有功能強大的vc平臺和網絡分析工具（如sniffer）便于調試，其設計不針對任何一個嵌入式芯片，具有較好的通用性和可移植性，在pc機上實現的tcp/ip協議，除了以太網層要結合omap平臺的網卡硬件重寫外，基本上可以直接移植到omap平臺上，不需要再做大的改動，作為一個通信程序，必須需要兩端程序同時調試，在pc機上編好的程序能度omap平臺上程序的調試提供可靠的幫助，因此，協議開發采用先模擬再移植、先整體再部分的設計思路，而協議各層實現的順序為自下而上。具體步驟是：

（1）在pc機上的windows操作系統及vc6.0開發平臺上，實現嵌入式系統tcp/ip協議族的模擬器，該模擬器應該能實現tcp/ip協議的基本功能，包括以太網驅動程序、arp、ip、udp、tcp等，并且實現的arp、ip、udp、tcp層的程序應該通用于各嵌入式系統并可移植。

（2）將該模擬器移植到omap開發平臺，用其以太網卡的驅動程序替換原模擬器的鏈路層程序，在ti提供的ccs平臺上最終實現基于omap的tcp/ip協議。

2 開發平臺

omap的多媒體開發平臺innovator主要由4個模塊組成：pm（處理器模塊）、im（接口模塊）、m（擴展模塊）、bob（主連接板）。omap處理器在pm上，以太網卡在bob上，可以通過innovator上的omap1510芯片的arm微處理器對單片以太網控制器lan91c96的工作進行控制，實現以太網幀的收發，并通過ccs對程序調試，圖2為omap平臺調試環境。

3 在pc上實現協議的基本模塊

3.1 主要模塊介紹

（1）主流程：首先對tcp/ip協議族的各層初始化，成功則進入主循環，主循環采用"中斷＋循環）"結構，簡單且分層清晰，中斷作為應用層發出命令，調用下層的入口。對于接收到的以太網幀，則由下到上分別進入各層進行處理。協議實現主流程如圖3所示。

（2）pc上的以太網層：在內存中開辟接收和發送兩個相同的循環緩沖區，用于存放接收和發送的以太網幀。winpcap軟件是基于windows平臺的一個網絡包工具，它提供一個系統內核級的動態鏈接庫packet.dll作為標準的api，具有獨立于操作系統的編程接口。利用其提供的api可直接聯系網卡驅動與已定義的循環緩沖區，將緩沖區中的數據發出，并將網卡接收的數據存入緩沖區。

（3）arp層，在內存中開辟一塊循環存儲區域用于存放已知的ip-mac對應表，該表可以由上層添加，在接收到arp應答時會自動添加，也可以上層清空。處理arp層函數的過程中：根據以太網首部協議字段過濾出arp包，針對arp請求與arp應答進行不同的處理，應答對方的請求，記錄對方的應答。

（4）ip層：根據以太網首部的幀類型標注判斷接收到的是不是ip包來處理ip層函數，如果是：則調用ip包的接收函數，對給收到的ip包用各種條件進行過濾，對于滿足條件的包獲取其長度與指針信息供上層使用。本層另一個主要函數是ip包發送函數，由上層調用進行ip封裝。

ip的檢驗和僅包括ip首部，長度一般為20字節（如果沒有選項）。在接收端，丟棄檢驗和不為oxffff的包，在發送端，將計算所得值的反碼填入檢驗和字節，由于主機和網絡對數據中高低字節默認的順序不同，在讀寫包中的16、32數據時，應該先進行高低字節的交換。

（5）udp層，處理udp層函數應根據ip首部的協議字段判斷是否udp包。如果是：則調用udp包接收函數，用各種條件對其進行過濾，提出udp數據及各種有用信息，根據端口號提交給應用進程處理，本層的另一個主要函數是udp發送函數，實現封裝udp包（包括載入udp數據，計算并填入udp首部信息），最后調用ip發送函數，較由ip層處理。

（6）tcp層：與udp不同，tcp主機要進行數據通信之前，必須與對方建立連。與幾個主機通信，就要建立幾個連接。然而，若要知道接收到的tcp包屬于哪個連接且使得幾個不同的連接之間獨立工作、互不干擾，則需要定義tcp的控制模塊，這里用一個結構體數組實現，存放所有關于連接的信息。

處理tcp層函數，判斷接收包的類型，如果是tcp包，則調用tcp接收函數，tcp接收函數用指定條件進行過濾，找到該包所屬的連接或完成一個新連接的被動打開，根據tcp的狀態轉換則完成11種狀態的轉移，并且實現了多路數據同時、雙向的傳輸。

tcp的發送函數包括主動打開、主動關閉（由上層調用完成新連接的主動打開，或主動關閉一個已建立的連接）和發送控制包（用于tcp連接的建立與終止，會在tcp接收函數中調用，從而實現tcp的轉換）三個函數。

tcp層還實現了兩個定時器，tcp重傳定時器函數可提供服務可靠性的有效保障；tcp保活定時器能夠避免資源的浪費。

3.2 程序特點分析

（1）簡單性：4.4bsd－lite版的完整tcp/ip內核實現大約有15 000行，而本程序源代碼約有1 400行，更適合嵌入式系統的應用。

（2）可重用性：本程序分層清晰。對于不同的嵌入式系統，可能使用的cpu和以太網卡不同，這就需要針對其特點的以太網層設計，而arp、ip、udp、tcp則不需要改動。

（3）可拓展性：tcp/ip協議是底層網絡協議，本程序留有很好的接口，可在其上構件更高層的網絡協議，包括h.323協議、ftp、telnet。

4 在omap平臺上的移植

4.1 單片以太網控制器lan91c96

lan91c96是smsc公司生產的專門用于嵌入式產品的10mbps以太網控制器，具有性能優良，功耗低及尺寸小的特點，如圖4所示。

6kb的ram：用來存放數據包。

mmu：對ram進行有效管理，為接收和發送包在ram中分配存儲空間。
arbite：使mmu和ram與cpu、csma很好地連接。

csma/cd模塊：集成了ieee 802.3 mac層協議，負責監聽網絡情況和地址過濾。若目的地址是lan91c96的地址、廣播地址或多播地址，則接收此數據包，否則拋棄。

endec：負責與10mbps為以太網物理媒體的連接。

lan91c96采用地址映射方式，通過訪問innovator為的指定地址對其存儲器訪問。lan91c96的寄存器在innovator內存中的地址分配為：0x08000300－0x0800030f。寄存器共有4組（bank0－bank3），使用相同的地址，通過bank_select寄存器選擇。

4.2 移植過程

先實現該網卡芯片的驅動程序，再用它替換pc模擬器的以太網層，程序驅動主要包括以下三個部分：

（1）初始化：主要為lan91c96的各寄存器填入正確的初始值使其正常工作。

（2）接收：如圖5所示，由csma（載波偵聽模塊）接收到符合地址要求的后，mmu（存儲器管理單元）為其請求在ram中分配存儲空間并分配一個編號，dma將其存入ram。接著在接收數據的前面封裝status的化count字節信息，如果crc檢測正確，則將其編號放入接收fifo，如果接收fifo不為空，則rcv_int（接收中斷標識）被設置。檢查接收中斷寄存器狀態，如果就接收中斷，對應其編號，上層協議便可以取出數據了，取出后，將該數據編號從fifo中清除。

狀態字可以從rcr寄存器中讀取，它反應了接收過程出現的各種措施，如crc錯誤、接收幀過長等，數據包的編號從fifo_ports寄存器中獲得，而數據指針可從pointer寄存器中獲得，數據信息從data寄存器中得到，根據這些信息將接收數據包復制到cpu內存，供上層使用，接收函數的主要流程如圖6。

（3）發送：圖7描述了發送數據包fifo中的排隊過程，首先mmu在ram中分配一定字節的存儲空間，然后，將分配結果寄存器中的編號放入pnr寄存器，寫數據指針寄存器pointer并將上層數據封裝后拷入data寄存器，根據其編號放入發送fifo，排隊的包將自動發出，發出包的編號接著進入發送完成fifo。如果發送成功，則存儲空間自動釋放；否則釋放存儲空間并將其重新排隊。

5 實驗結果

5.1 內存資源占用量

運行該tcp/ip協議棧需要3mb內存，而innovator體32mb sdram 和32mb flash，內存占用率為：3m/64m＝4.7％，完全適用于嵌入式系統。

5.2 數據傳輸可靠性

tcp利用以下機制糾錯。數據的傳輸過程中的誤碼：檢驗和機制與重傳機制，數據的重復，在接收端會自動舍棄已經接收過的數據包，并且不發ack，故不會發生一個數據包接收多次的情況，數據包的丟失，接收端在接收完一段數據后，會計算下一個預期數據的序號，如果不符合就不發ack，從而導致發端重發，避免了數據包的丟失，經測試，在未發生擁塞情況下，傳輸的誤碼率幾乎為0。

5.3文件最大平均傳輸速率

下面就本程序所實現的利用tcp進行文件傳輸功能，給出不同情況下的最大傳輸速率，實驗環境為10mbps以太網。

理想狀態下的理論最大吞吐量：假定發送方傳輸兩個背對背、滿長度的tcp數據，接收方為其發出兩個ack，每包中用戶數據量為1460位，總數據量為1538位，故最大的用戶數據吞吐量為：

本實驗測得文件的平均傳輸速率隨著tcp連接數的增多有如圖8所示的曲線變化，前半段隨著連接數的增加成線性增長，后半段由于出現了網絡擁塞，整體的平均速率反而有所下降。

實驗結果與理論最大吞吐量有所差距，原因在于：

（1）理論上只是一種理想的狀態，現實中難以達到。

（2）受cpu處理速度及文件傳輸過程的讀、寫文件操作的限制。

（3）本程序采用的數據傳輸機制是當收到上一個包的ack之后再發送下一個數據包，這樣避免了對接收數據的排序，提高了可靠性，但數據的傳輸速度會受到制約。