在TMS320VC5402上實現(xiàn)的嵌入式TCP/IP協(xié)議棧

    摘要：實現(xiàn)一個運行在16位數(shù)字信號處理器TMS320VC5402上的小型嵌入式TCP/IP協(xié)議棧。對TCP/IP協(xié)議中的IP協(xié)議、ARP協(xié)議、UDP協(xié)議進行分析，完成基于TCP/IP協(xié)議的嵌入式網(wǎng)絡(luò)系統(tǒng)。

    關(guān)鍵詞：DSP TMS320VC5402 TCP/IP協(xié)議棧 嵌入式系統(tǒng)

引言

隨著嵌入式系統(tǒng)應(yīng)用范圍的不斷擴展及網(wǎng)絡(luò)應(yīng)用的日益普及，使得越來越多的嵌入式系統(tǒng)需要支持網(wǎng)絡(luò)功能。TCP/IP是目前一種被廣泛采用的網(wǎng)絡(luò)協(xié)議。TCP/IP是一套把因特網(wǎng)上的各種系統(tǒng)互連起來的協(xié)議組，已成為事實上最常用的網(wǎng)絡(luò)標準之一。本文對TCP/IP協(xié)議中的IP協(xié)議、ARP協(xié)議和UDP協(xié)議進行了分析，利用DSP的專用匯編語言實現(xiàn)了自己的通信協(xié)議。由此可使DSP直接對Ethernet發(fā)來的數(shù)據(jù)包解分析，并能按照TCP/IP協(xié)議正確打包和發(fā)送，最終實現(xiàn)DSP與PC機的數(shù)據(jù)通信，成功地完成了語音數(shù)據(jù)的采集和發(fā)送，實現(xiàn)了DSP與PC機的語音數(shù)據(jù)傳輸。

1 TCP/IP協(xié)議分析

一般在嵌入式系統(tǒng)中實現(xiàn)的TCP/IP協(xié)議都是面向數(shù)據(jù)采集和傳輸?shù)?，所以大部分實現(xiàn)都是IP協(xié)議、ARP協(xié)議、UDP協(xié)議或者是TCP協(xié)議。本文完成的是IP協(xié)議、ARP協(xié)議和UDP協(xié)議。一般認為TCP/IP為四層協(xié)議，實現(xiàn)的協(xié)議棧結(jié)構(gòu)如圖1所示。

DSP程序自下而上實現(xiàn)以下協(xié)議：

①媒介訪問控制MAC（Media Access Control），向以太網(wǎng)收發(fā)數(shù)據(jù)。傳送的數(shù)據(jù)格式為Ethernet數(shù)據(jù)幀格式。Ethernet幀的長度是可變的，但都大于64字節(jié)，小于1518字節(jié)。它包括頭部、數(shù)據(jù)和尾部三部分。8字節(jié)的前導(dǎo)用于幀同步，CRC域用于幀校驗。目的地址和源端地址是指網(wǎng)卡的物理地址（MAC地址），具有唯一性。

②地址解析協(xié)議ARP（Address Resolution Protocol），使得物理地址和IP地址可以對應(yīng)起來。在Ethernet上，使用地址解析協(xié)議ARP協(xié)議來實現(xiàn)IP地址到MAC地址的動態(tài)轉(zhuǎn)換。ARP Request(ARP請求)和ARP Response(ARP響應(yīng))類型都是0X0806。ARP報文格式包括硬件類型、協(xié)議類型、硬件地址長度、協(xié)議地址長度、操作字段、源端物理地址、源端IP地址、目的物理地址和目的IP地址。

③Internet網(wǎng)核心協(xié)議IP（Internet Protocol），實現(xiàn)IP網(wǎng)絡(luò)上的數(shù)據(jù)傳輸?shù)幕A(chǔ)。IP協(xié)議提供了一種高效、不可靠和無連接的傳輸方式。IP報文是IP協(xié)議的基本處理單元，是由報頭和數(shù)據(jù)兩部分組成的。IP報頭包括20字節(jié)的固定部分和變長的選項部分。20字節(jié)的固定部分包括IP協(xié)議的版本號、IP首部長度、服務(wù)類型、報文總長度、標識符、片偏移、報文生存時間、首部校驗和以及源端IP地址和目的端IP地址。

    ④用戶數(shù)據(jù)報協(xié)議UDP（User Datagram Protocol），提供不可靠的數(shù)據(jù)傳輸功能。它不對要發(fā)送的數(shù)據(jù)進行緩沖，直接把從應(yīng)用層收到的數(shù)據(jù)加上UDP首部發(fā)送出去。UDP不會把應(yīng)用層多、次發(fā)送的數(shù)據(jù)合并成為一個包發(fā)送出去。這對于編寫簡單的請求/響應(yīng)模式的應(yīng)用是很方便的，而且利用UDP協(xié)議對傳輸速率也沒有太大的影響。UDP協(xié)議的數(shù)據(jù)報格式包括源端口口、目的端口號、數(shù)據(jù)報長度、UDP校驗和以及UDP數(shù)據(jù)。

⑤上層應(yīng)用協(xié)議，對語音數(shù)據(jù)打包傳輸，實現(xiàn)DSP與PC機的語音數(shù)據(jù)傳輸。

2 硬件接口電路

硬件接口電路如圖2所示。

微處理器采用的是TI公司生產(chǎn)的TMS320VC5402數(shù)字信號處理器。它采用了改進的哈佛結(jié)構(gòu)，操作速率達到了100MIPS。以太網(wǎng)控制芯片采用RTL8019AS，是臺灣Realtek公司生產(chǎn)的一種高度集成的以太網(wǎng)控制器。它實現(xiàn)了以太網(wǎng)媒介訪問層（MAC）和物理層（PHY）的全部功能。譯碼、電平變換及向功能由XC95144xl完成。它是Xilinx公司生產(chǎn)的低功耗CPLD器件。HR61001G是中山漢仁電子有限公司生產(chǎn)的10BASE-T接口器件，起低通濾波和隔離變壓等作用。

3 軟件設(shè)計

3．1 DSP上嵌入式TCP/IP協(xié)議的匯編程序設(shè)計

由于DSP的資源有限，所以網(wǎng)絡(luò)協(xié)議根據(jù)嵌入式應(yīng)用進行了裁減。本設(shè)計中完成了ARP、IP、UDP等部分協(xié)議，既能夠保證DSP接入以太網(wǎng)，又使DSP資源能夠滿足嵌入式系統(tǒng)應(yīng)用的要求。

首先介紹一下所設(shè)計的DSP接收和發(fā)送以太網(wǎng)數(shù)據(jù)包所使用的數(shù)據(jù)結(jié)構(gòu)。作者選擇了聯(lián)合體結(jié)構(gòu)作為DSP接收和發(fā)送以太網(wǎng)數(shù)據(jù)包的緩沖區(qū)。聯(lián)合體允許大小和類型不同的定義臨時存儲在同一存儲器空間。這樣的好處是各層協(xié)議之間數(shù)據(jù)的傳遞，實質(zhì)上是數(shù)據(jù)指針在傳遞，而不是數(shù)據(jù)拷貝傳遞。而且各層協(xié)議可以直接使用該緩沖區(qū)，因為緩沖區(qū)內(nèi)的結(jié)構(gòu)體完全是按照各個協(xié)議的幀格式設(shè)計的。在聯(lián)合體databuf中有四個結(jié)構(gòu)體成員—ethernetpkt、ippkt、udppkt、arppkt，分別對應(yīng)著以太網(wǎng)數(shù)據(jù)幀、IP協(xié)議、UDP協(xié)議、ARP協(xié)議的幀格式。這4個結(jié)構(gòu)體成員是按照它們各自協(xié)議的幀格式進行定義的。值得注意的是，因為databuf中存儲的是RTL8019AS發(fā)送的以太網(wǎng)數(shù)據(jù)幀，聯(lián)合體的成員共用databuf緩沖區(qū)，所以在各個結(jié)構(gòu)體中要預(yù)留低層協(xié)議報頭存儲空間。例如，IP協(xié)議的結(jié)構(gòu)體ippkt就要在結(jié)構(gòu)體定義中留下ethernetpkt報頭的存儲空間，即ippkt定義中前9個整型空間不能使用，從第10個整型空間開始才是IP數(shù)據(jù)報的內(nèi)容。

下面分4層介紹所完成的嵌入式TCP/IP協(xié)議。

①物理層：主要完成以太網(wǎng)控制器RTL8019AS的復(fù)位，寄存器的初始化，并設(shè)置RTL8019AS的工作方式、中斷響應(yīng)、DMA通道接收緩沖區(qū)的地址設(shè)置等。

初始化程序如下：

WRITE 0x21,CR /*設(shè)置命令寄存器，選中第0頁*/

WRITE 0x4c,PSTART/*頁起始地址寄存器初始化，設(shè)定接收緩沖區(qū)起始頁地址*/

WRITE 0x80,PSTOP /*頁停止地址寄存器初始化，設(shè)定接收緩沖區(qū)終止頁地址*/

WRITE 0x4c,BNRY

/*頁邊界地址寄存器初始化，設(shè)定從接收緩沖區(qū)讀取數(shù)據(jù)的位置，讀指針*/

WRITE 0x40,TPSR /*發(fā)送頁地址寄存器初始化，設(shè)定發(fā)送緩沖區(qū)的起始頁地址*/

WRITE 0xcc,RCR

/*接收配置寄存器初始化，使用接收緩沖區(qū)，僅接收自己地址的數(shù)據(jù)包、廣播地址數(shù)據(jù)包和多點播地址包，小于64字節(jié)的包丟棄，校驗錯的數(shù)據(jù)包不接收*/

WRITE 0xe0,TCR

/*傳輸配置寄存器初始化，啟用CRC自動生成和自動校驗，工作在正常模式*/

WRITE 0xc9,DCR

/*數(shù)據(jù)配置寄存器初始化，使用FIFO緩存，工作在正常模式，DMA傳輸數(shù)據(jù)16位寬*/

WRITE 0x01,IMR /*中斷屏蔽寄存器初始化，使能數(shù)據(jù)包正確接收中斷*/

WRITE 0xff,ISR /*復(fù)位中斷狀態(tài)寄存器*/

WRITE 0x61,CR /*設(shè)置命令寄存器，選中第1頁*/

WRITE 0x4d,CURR

/*當(dāng)前頁地址寄存器初始化，指向當(dāng)前正在寫的頁的下一頁，寫指針*/

其中WRITE為宏指令，其定義如下：

WRITE .macrodata,reg

ST data,*(net_reg)

PORTW *(net_reg),reg

RPT #(20-1)

NOP

.endm

②網(wǎng)絡(luò)層：主要實現(xiàn)IP協(xié)議和ARP協(xié)議。當(dāng)DSP接收到正確的以太網(wǎng)數(shù)據(jù)包以后，調(diào)用check_packet函數(shù)處理。如果是ARP請求，則發(fā)送一個ARP應(yīng)答；如果是ARP應(yīng)答，則把對方的IP地址和以太網(wǎng)地址放到ARP緩存中；如果是IP包，則調(diào)用IP處理模塊處理，接收數(shù)據(jù)。

    check_packe函數(shù)如下：

arp: CMPM *(databuf.ethernetpkt.protocol),#0x0608

;判斷協(xié)議類型是否為ARP協(xié)議

BC ip,NTC

CALL arp_process ;調(diào)用ARP協(xié)議處理模塊

ST #taskfree,*(task);設(shè)置空閑任務(wù)指針

B taskfree ;跳轉(zhuǎn)到空閑任務(wù)

Ip: CMPM *(databuf.ethernet.protocol),#0x0008；判斷協(xié)議類型是否為IP協(xié)議

CC ip_process,TC ;若為IP協(xié)議，調(diào)用IP協(xié)議處理模塊

ST #taskfree,*(task) ;設(shè)置空閑任務(wù)指針

B taskfree ；跳轉(zhuǎn)到空閑任務(wù)

arp_process:接收ARP請求后，封裝好ARP數(shù)據(jù)報，調(diào)用send_packet函數(shù)完成發(fā)送。在本設(shè)計中，DSP工作復(fù)位時，ARP協(xié)議發(fā)送一個ARP請求，發(fā)送自己的IP地址和物理地址給PC機。

ip_process:接收IP數(shù)據(jù)報后，判斷協(xié)議 ，協(xié)議如果為17，即是UDP協(xié)議，則調(diào)用函數(shù)udp_process，處理UDP數(shù)據(jù)報，否則丟棄該數(shù)據(jù)報。在本設(shè)計中，正確接收一幀數(shù)據(jù)報后，會給PC機一個應(yīng)答信息，通知PC機已經(jīng)正確接收了數(shù)據(jù)報，可以繼續(xù)發(fā)送數(shù)據(jù)。應(yīng)答信息的封裝首先調(diào)用create_udp_packet完成對應(yīng)答信息的UDP協(xié)議的封裝，然后調(diào)用create_ip_packet函數(shù)，這個函數(shù)完成了把封裝好的UDP數(shù)據(jù)報再封裝成IP數(shù)據(jù)報。最后調(diào)用send_packet函數(shù)完成發(fā)送。

③傳輸層：如果IP數(shù)據(jù)報中的協(xié)議類型為17，則為UDP數(shù)據(jù)報，需要調(diào)用udp_process函數(shù)處理數(shù)據(jù)報。正確接收了數(shù)據(jù)后，給發(fā)送一個應(yīng)答信息，上面已經(jīng)提到了具體過程，這里不再復(fù)述了。這里介紹一下UDP協(xié)議的一個難點—UDP數(shù)據(jù)的和校驗。UDP和校驗要求加上UDP偽首部以后再進行校驗，偽首部格式包括32位源IP地址、32位目的IP地址、8位數(shù)據(jù)0、8位協(xié)議和16位UDP數(shù)據(jù)長度。作者根據(jù)接收緩沖區(qū)的內(nèi)存管理特點，即接收緩沖區(qū)的成員結(jié)構(gòu)共用同一塊數(shù)據(jù)存儲區(qū)，所以將IP協(xié)議的幀頭從生存時間開始到幀頭結(jié)束封裝成UDP偽首部。其實這樣做，只需將8位生存時間改為全0，16位首部和改為UDP數(shù)據(jù)長度即可，8位的協(xié)議、32位源IP地址和32位的目的IP地址不用改動。作UDP和校驗的時候，從IP協(xié)議幀頭的報文生存時間開始到IP數(shù)據(jù)報的數(shù)據(jù)部分結(jié)束作帶進位的相加，最后比較對和校驗就可以了。

④應(yīng)用層：由于傳輸?shù)氖钦Z音數(shù)據(jù)，將采集的數(shù)據(jù)經(jīng)過A律壓縮放到DSP數(shù)據(jù)緩沖區(qū)databuf中，應(yīng)用TCP/IIP協(xié)議將其發(fā)送給PC機。將PC機發(fā)送來的語音數(shù)據(jù)A律壓縮通過DSP的多通道緩沖串行口發(fā)送給聲卡。對于語音數(shù)據(jù)的處理，交給PC機完成，這里只實現(xiàn)數(shù)據(jù)的傳輸。

注：TCP/IP協(xié)議源碼見網(wǎng)站 www.dpj.com.cn 。

3．2 PC機上的應(yīng)用程序設(shè)計

使用的VB編程，利用Winsock控件完成語音數(shù)據(jù)的接收。這方面有很多例子可以借鑒，所以就不作太多的介紹。

結(jié)語

目前，基于DSP的嵌入式以太網(wǎng)的多媒體應(yīng)用越來越受到廣泛的關(guān)注和應(yīng)用，而且基于TCP/IP協(xié)議的嵌入式網(wǎng)絡(luò)系統(tǒng)已經(jīng)成功地應(yīng)用到了語音傳輸、遠程圖像控制和數(shù)據(jù)傳輸中。其便于操作、傳輸速度快等優(yōu)點，受到了有關(guān)專家的一致好評。本文利用數(shù)字信號處理器DSP和RTL8019AS完成了嵌入式智能設(shè)備接入以大網(wǎng)，成功實現(xiàn)了應(yīng)用嵌入式網(wǎng)絡(luò)系統(tǒng)完成語音數(shù)據(jù)傳輸?shù)墓δ堋?