TI通信開發套件NDK

2.1 NDK開發套件的高效率設計

為了加速其高檔DSP的網絡化進程，TI公司結合其C6000系列芯片推出了TCP/IP NDK (Network Developer’s Kit)開發套件。

NDK主要的組件包括：（1）支持TCP/TP協議棧程序庫。其中主要包含的庫有：支持TCP/IP網絡工具的庫，支持TCP/IP協議棧與DSP/BIOS平臺的庫，網絡控制以及線程調度的庫（包括協議棧的初始化以及網絡相關任務的調度）（2）示范程序。其中主要包括DHCP/Telnet客戶端，HTTP/數據服務器示范等。（3）支持文檔 包括用戶手冊、程序員手冊和平臺適應手冊。

NDK采用緊湊的設計方法，實現了用較少的資源耗費來支持TCP/IP。從實用效果看，NDK僅用200~250K程序空間和95K數據空間即可支持常規的TCP/IP服務，包括應用層的telnet、DHCP、HTTP等。為了最大限度地減少資源消耗，TI為其NDK采用了許多特殊的技巧，重要的有：（1）UDP socket和RAW socket不使用發送或接收緩沖區；（2）TCP socket使用發送緩沖區，接收緩沖區依配置文件而定；（3）低層驅動程序與協議棧之間通過指針傳遞數據，不對包進行復制拷貝；4、設置專門的線程清除存儲器中的碎片和檢查存儲器泄露。因此，NDK很適合目前嵌入式系統的硬件環境，是實現DSP聯網通信的重要支撐工具。

NDK的軟件開發環境是TI的開發工具CCS（code composer studio）。它包含有實時操作系統DSP/BIOS和主機與目標板之間的實時數據交換軟件RTDX。

2.2  NDK的配置和使用

在CCS下使用NDK需要在以下幾點上做特別處理：

（1）設置DSP/BIOS

PRD設置主時鐘。硬件抽象層的時鐘驅動需要一個100ms啟動一次的PRD函數作為主時鐘，函數名是llTimerTick()。

HOOK為TCP/IP協議棧設置保存的空間。OS庫的任務調度模塊需要調用hook來保存和調用TCP/IP協議棧的環境變量指針，這兩個hook函數是NDK_hookInit() 和 NDK_hookCreate()。

（2）包含文件和庫文件

請注意編譯時需要包含庫文件和文件路徑，一般默認為c:\ti\c6000\ndk\inc

（3）CCS工程編譯時的鏈接順序

CCS一般按照特定的順序來鏈接目標函數和庫文件，NDK是對這個鏈接順序很敏感的，錯誤的順序可以導致重復定義符號甚至不正確執行等錯誤。為避免這個情況，可以在CCS里選擇Link Order"-> "build options對話框，將文件按照一定順序添加并且將庫文件添置到連接順序的最后，推薦的順序為：NETCTRL.LIB，HAL_xxx.LIB，NETTOOL.LIB，STACK.LIB和OS.LIB。

在初始化啟動協議棧之前，要為其分配一塊工作內存（SDRAM），命令是_mmBulkAllocSeg( EXTERN1 )。還要調用fdOpenSession()來初始化文件指針向量表，否則創建socket的時候將出現錯誤。

我們將發送/接收設置定義為一個任務，在創建任務句柄以前，我們應該用NC_SystemOpen()打開網絡功能并進行設置，在系統關閉前也要進行相應的處理。

使用NDK提供的socket API函數需要注意下面一些問題：（1）NDK中對socket API 通過一個文件指針接口與操作系統相連接，因此要調用文件指針向量表初始化和關閉函數對文件系統進行相應操作。（2）NDK中并沒有提供windows API中強大的select函數，但是可以用fdselect實現一些相應的工程。可以相互對應得API函數還有NDK中的fdclose 和標準的close, NDK中的fderror和標準的errno.(3) NDK提供了很多網絡工具的支持的函數，比如和DNS相關的一些函數，可以代替標準API中的getpeername, gethostname等。另外還有關于IGMP的一些函數可以用來支持組播，但是只支持作為組播用戶，不能支持作為組播服務器。

3．NDK傳輸UDP數據包效率測試及性能分析

3.1測試平臺結構

我們研究了在NDK下CPU對UDP數據包發送接收的效率，這個測試分成兩部分：一部分是測試從DM642向PC機發送UDP數據包時，在不同的傳輸速率和不同的L2 cache大小時的CPU占用率，另一部分是測試DM642接收從PC機發送來數據包時，在不同的傳輸速率和不同的L2 cache大小時的CPU占用率。我們所使用的工具是在CCS下的NDK提供的socket API函數和在visual studio下提供的winsocket API。圖4是測試環境的示意圖。

圖4：NDK測試環境示意圖

3.2 測試平臺的配置和實現

由于接收和發送程序十分相似，我們僅以發送程序舉例。創建發送數據的程序為一個任務，在DSP/BIOS中，任務對象就是被TSK模塊管理的線程。TSK模塊根據任務的優先級和當前的執行狀態動態的調度。DSP/BIOS總共有15個任務優先級可以使用，并且提供了一組函數來操縱任務對象，包括建立、刪除、設置任務對象。任何任務對象都處于下面幾種狀態之一：運行態，就緒態，阻塞態，終止態。

在這個工程中，我們在網絡控制的程序中進行任務的創建，圖5是創建任務的流程圖：

圖5：傳輸任務創建流程圖

其中創建任務的語句為：TaskCreate( tsk_udp, "udp_video", 5, 0x1000, peer_addr , 12345, 12345 )。理論上，可以通過設置兩個task的方法來增加數據傳輸的速率，但是注意這兩個task應該用不同的端口進行傳送。任務調度的應用程序為：

static void tsk_udp( IPN IPAddr, int PeerPort , int LocalPort)

{        ……

// 創建 socket

s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

……

// 設置要綁定的地址端口屬性

bzero( &sin1, sizeof(struct sockaddr_in) );

sin1.sin_family      = AF_INET;

sin1.sin_len         = sizeof( sin1 );

sin1.sin_port        = htons(LocalPort);

//綁定IP地址和端口

if( bind( s, (PSA) &sin1, sizeof(sin1) ) < 0 )

{ goto exit_tsk;}

//設定目的地址端口屬性

bzero( &sin1, sizeof(struct sockaddr_in) );

sin1.sin_family    = AF_INET;

sin1.sin_len       = sizeof( sin1 );

sin1.sin_addr.s_addr = IPAddr;

sin1.sin_port      = htons(PeerPort);

……

// 分配工作緩沖區

if( !(pBuf = mmBulkAlloc( 1024 )) )

{goto exit_tsk;}

// 一下開始發送數據

for(;;)

{        // 填充發送數據的緩沖區

*(int*)pBuf=send_udp_count++

// 發送數據

if( sendto( s, pBuf, 1000, 0, &sin1, sizeof(sin1) ) < 0 )

         { goto exit_tsk;//break;}

// 清空數據區

mmZeroInit( pBuf, (uint)test );

//設置發送數據率

       TaskSleep(8);    // 1Mbit/s

}

……

}

測試里面有兩個關鍵參數需要設置，一個是發送（接收）的數據率和DM642內部第二級緩存的大小。收發的數據率可以通過改變任務掛起的時間間隔長度來改變。系統函數TaskSleep(n)表示每隔n毫秒執行一次發送，我們設定每次發送1000 Byte的數據，這樣TaskSleep(8)表示1Mbit/s的傳輸速率，TaskSleep(4)表示2Mbit/s的傳輸速率，以此類推。

而L2 cache大小的改變可以通過以下語句來設置：

CACHE_setL2Mode(CACHE_64KCACHE)表示設置了64K L2 Cache；CACHE_setL2Mode(CACHE_128KCACHE)表示設置了128K L2 Cache，以此類推。

3.3 測試結果和性能分析

我們在DM642評估版上，采用標準的recvfrom函數進行數據接收，以無連接的UDP協議與windows PC進行相互傳輸。對不同傳輸速率和不同大小的二級緩存下CPU的占用率進行了比較。

CPU占用率=空閑周期可完成的低優先級任務/ 執行傳輸任務時可完成的低優先級任務

其中接收和發送數據均設為每次1000 Byte，評測結果在下面四個圖表里面顯示出來。

表1：由DM642發送UDP數據包的CPU占用率（%）

圖6：DM642發送UDP數據包CPU占用率比較圖

表2：由DM642 UDP數據包的CPU占用率（%）

圖7：DM642接收UDP數據包CPU占用率比較圖

從上面的比較可以看出 DM642發送和接收數據包時的CPU占用率均隨著網絡傳輸速率的增加而提高，而且基本上呈線性關系。因為收發數據是對數據簡單的搬移，它的復雜度是隨著數據的增加而線性增長的，在高速緩存一定得情況下CPU的占用率線性增加。

而第二級緩存的大小對CPU的占用率也有影響，一般而言是L2 cache越大，CPU占用率越小，而且隨著收發數據率的變大而顯得更加明顯，這個得益于DM642兩級緩存的工作原理和強大的DMA功能。

L2 cache增大帶來的另一個影響是CPU片內存儲容量的減少，使得片內能放下的代碼段和數據段就比較少，這樣反而會減緩程序的運行速度，這在處理復雜的編解碼程序，數據段和代碼段比較多時尤為明顯，這就需要程序員根據實際情況統籌安排合理配置。

4．總結與展望

為了研究在嵌入式芯片上進行高速多媒體通信的可行性，本文討論了TI DM642上NDK設計的原理，并進行了與PC機實時數據通信的測試。測試表明TI公司推出的NDK套件在DM642芯片上實現了高效率的TCP/IP傳輸協議，即使高達16Mbit/s的傳輸速率，CPU的占用率也不到10%，這使得它完成多路的視頻傳輸也綽綽有余，這是DM642能夠廣泛應用于各種多媒體通信設備和終端的有力保證。再配合DM642芯片強大的多媒體處理功能，使得其在多媒體通信市場上有廣闊的前景。值得我們去研究和關注。