- 相關推薦
在TMS320VC5402上實現的嵌入式TCP/IP協(xié)議棧
摘要：實現一個運行在16位數字信號處理器TMS320VC5402上的小型嵌入式TCP/IP協(xié)議棧。對TCP/IP協(xié)議中的IP協(xié)議、ARP協(xié)議、UDP協(xié)議進行分析，完成基于TCP/IP協(xié)議的嵌入式網絡系統(tǒng)。關鍵詞：DSPTMS320VC5402TCP/IP協(xié)議棧嵌入式系統(tǒng)
引言
隨著嵌入式系統(tǒng)應用范圍的不斷擴展及網絡應用的日益普及，使得越來越多的嵌入式系統(tǒng)需要支持網絡功能。TCP/IP是目前一種被廣泛采用的網絡協(xié)議。TCP/IP是一套把因特網上的各種系統(tǒng)互連起來的協(xié)議組，已成為事實上最常用的網絡標準之一。本文對TCP/IP協(xié)議中的IP協(xié)議、ARP協(xié)議和UDP協(xié)議進行了分析，利用DSP的專用匯編語言實現了自己的通信協(xié)議。由此可使DSP直接對Ethernet發(fā)來的數據包解分析，并能按照TCP/IP協(xié)議正確打包和發(fā)送，最終實現DSP與PC機的數據通信，成功地完成了語音數據的采集和發(fā)送，實現了DSP與PC機的語音數據傳輸。
1TCP/IP協(xié)議分析
一般在嵌入式系統(tǒng)中實現的TCP/IP協(xié)議都是面向數據采集和傳輸的，所以大部分實現都是IP協(xié)議、ARP協(xié)議、UDP協(xié)議或者是TCP協(xié)議。本文完成的是IP協(xié)議、ARP協(xié)議和UDP協(xié)議。一般認為TCP/IP為四層協(xié)議，實現的協(xié)議棧結構如圖1所示。
DSP程序自下而上實現以下協(xié)議：
�、倜浇樵L問控制MAC（MediaAccessControl），向以太網收發(fā)數據。傳送的數據格式為Ethernet數據幀格式。Ethernet幀的長度是可變的，但都大于64字節(jié)，小于1518字節(jié)。它包括頭部、數據和尾部三部分。8字節(jié)的前導用于幀同步，CRC域用于幀校驗。目的地址和源端地址是指網卡的物理地址（MAC地址），具有唯一性。
②地址解析協(xié)議ARP（AddressResolutionProtocol），使得物理地址和IP地址可以對應起來。在Ethernet上，使用地址解析協(xié)議ARP協(xié)議來實現IP地址到MAC地址的動態(tài)轉換。ARPRequest（ARP請求）和ARPResponse（ARP響應）類型都是0X0806.ARP報文格式包括硬件類型、協(xié)議類型、硬件地址長度、協(xié)議地址長度、操作字段、源端物理地址、源端IP地址、目的物理地址和目的IP地址。
�、跧nternet網核心協(xié)議IP（InternetProtocol），實現IP網絡上的數據傳輸的基礎。IP協(xié)議提供了一種高效、不可靠和無連接的傳輸方式。IP報文是IP協(xié)議的基本處理單元，是由報頭和數據兩部分組成的。IP報頭包括20字節(jié)的固定部分和變長的選項部分。20字節(jié)的固定部分包括IP協(xié)議的版本號、IP首部長度、服務類型、報文總長度、標識符、片偏移、報文生存時間、首部校驗和以及源端IP地址和目的端IP地址。
�、苡脩魯祿䦂髤f(xié)議UDP（UserDatagramProtocol），提供不可靠的數據傳輸功能。它不對要發(fā)送的數據進行緩沖，直接把從應用層收到的數據加上UDP首部發(fā)送出去。UDP不會把應用層多、次發(fā)送的數據合并成為一個包發(fā)送出去。這對于編寫簡單的請求/響應模式的應用是很方便的，而且利用UDP協(xié)議對傳輸速率也沒有太大的影響。UDP協(xié)議的數據報格式包括源端口口、目的端口號、數據報長度、UDP校驗和以及UDP數據。
�、萆蠈討脜f(xié)議，對語音數據打包傳輸，實現DSP與PC機的語音數據傳輸。
2硬件接口電路
硬件接口電路如圖2所示。
微處理器采用的是TI公司生產的TMS320VC5402數字信號處理器。它采用了改進的哈佛結構，操作速率達到了100MIPS.以太網控制芯片采用RTL8019AS,是臺灣Realtek公司生產的一種高度集成的以太網控制器。它實現了以太網媒介訪問層（MAC）和物理層（PHY）的全部功能。譯碼、電平變換及向功能由XC95144xl完成。它是Xilinx公司生產的低功耗CPLD器件。HR61001G是中山漢仁電子有限公司生產的10BASE-T接口器件，起低通濾波和隔離變壓等作用。
3軟件設計
3.1DSP上嵌入式TCP/IP協(xié)議的匯編程序設計
由于DSP的資源有限，所以網絡協(xié)議根據嵌入式應用進行了裁減。本設計中完成了ARP、IP、UDP等部分協(xié)議，既能夠保證DSP接入以太網，又使DSP資源能夠滿足嵌入式系統(tǒng)應用的要求。
首先介紹一下所設計的DSP接收和發(fā)送以太網數據包所使用的數據結構。作者選擇了聯合體結構作為DSP接收和發(fā)送以太網數據包的緩沖區(qū)。聯合體允許大小和類型不同的定義臨時存儲在同一存儲器空間。這樣的好處是各層協(xié)議之間數據的傳遞，實質上是數據指針在傳遞，而不是數據拷貝傳遞。而且各層協(xié)議可以直接使用該緩沖區(qū)，因為緩沖區(qū)內的結構體完全
是按照各個協(xié)議的幀格式設計的。在聯合體databuf中有四個結構體成員—ethernetpkt、ippkt、udppkt、arppkt,分別對應著以太網數據幀、IP協(xié)議、UDP協(xié)議、ARP協(xié)議的幀格式。這4個結構體成員是按照它們各自協(xié)議的幀格式進行定義的。值得注意的是，因為databuf中存儲的是RTL8019AS發(fā)送的以太網數據幀，聯合體的成員共用databuf緩沖區(qū)，所以在各個結構體中要預留低層協(xié)議報頭存儲空間。例如，IP協(xié)議的結構體ippkt就要在結構體定義中留下ethernetpkt報頭的存儲空間，即ippkt定義中前9個整型空間不能使用，從第10個整型空間開始才是IP數據報的內容。
下面分4層介紹所完成的嵌入式TCP/IP協(xié)議。
�、傥锢韺樱褐饕瓿梢蕴W控制器RTL8019AS的復位，寄存器的初始化，并設置RTL8019AS的工作方式、中斷響應、DMA通道接收緩沖區(qū)的地址設置等。
初始化程序如下：
WRITE0x21,CR/*設置命令寄存器，選中第0頁*/
WRITE0x4c,PSTART/*頁起始地址寄存器初始化，設定接收緩沖區(qū)起始頁地址*/
WRITE0x80,PSTOP/*頁停止地址寄存器初始化，設定接收緩沖區(qū)終止頁地址*/
WRITE0x4c,BNRY
/*頁邊界地址寄存器初始化，設定從接收緩沖區(qū)讀取數據的位置，讀指針*/
WRITE0x40,TPSR/*發(fā)送頁地址寄存器初始化，設定發(fā)送緩沖區(qū)的起始頁地址*/
WRITE0xcc,RCR
/*接收配置寄存器初始化，使用接收緩沖區(qū)，僅接收自己地址的數據包、廣播地址數據包和多點播地址包，小于64字節(jié)的包丟棄，校驗錯的數據包不接收*/
WRITE0xe0,TCR
/*傳輸配置寄存器初始化，啟用CRC自動生成和自動校驗，工作在正常模式*/
WRITE0xc9,DCR
/*數據配置寄存器初始化，使用FIFO緩存，工作在正常模式，DMA傳輸數據16位寬*/
WRITE0x01,IMR/*中斷屏蔽寄存器初始化，使能數據包正確接收中斷*/
WRITE0xff,ISR/*復位中斷狀態(tài)寄存器*/
WRITE0x61,CR/*設置命令寄存器，選中第1頁*/
WRITE0x4d,CURR
/*當前頁地址寄存器初始化，指向當前正在寫的頁的下一頁，寫指針*/
其中WRITE為宏指令，其定義如下：
WRITE.macrodata,reg
STdata,*（net_reg）
PORTW*（net_reg），reg
RPT#（20-1）
NOP
.endm
�、诰W絡層：主要實現IP協(xié)議和ARP協(xié)議。當DSP接收到正確的以太網數據包以后，調用check_packet函數處理。如果是ARP請求，則發(fā)送一個ARP應答；如果是ARP應答，則把對方的IP地址和以太網地址放到ARP緩存中；如果是IP包，則調用IP處理模塊處理，接收數據。
check_packe函數如下：
arp:CMPM*（databuf.ethernetpkt.protocol），#0x0608
;判斷協(xié)議類型是否為ARP協(xié)議
BCip,NTC
CALLarp_process;調用ARP協(xié)議處理模塊
ST#taskfree,*（task）；設置空閑任務指針
Btaskfree;跳轉到空閑任務
Ip:CMPM*（databuf.ethernet.protocol），#0x0008;判斷協(xié)議類型是否為IP協(xié)議
CC
ip_process,TC;若為IP協(xié)議，調用IP協(xié)議處理模塊
ST#taskfree,*（task）；設置空閑任務指針
Btaskfree;跳轉到空閑任務
arp_process:接收ARP請求后，封裝好ARP數據報，調用send_packet函數完成發(fā)送。在本設計中，DSP工作復位時，ARP協(xié)議發(fā)送一個ARP請求，發(fā)送自己的IP地址和物理地址給PC機。
ip_process:接收IP數據報后，判斷協(xié)議，協(xié)議如果為17,即是UDP協(xié)議，則調用函數udp_process,處理UDP數據報，否則丟棄該數據報。在本設計中，正確接收一幀數據報后，會給PC機一個應答信息，通知PC機已經正確接收了數據報，可以繼續(xù)發(fā)送數據。應答信息的封裝首先調用create_udp_packet完成對應答信息的UDP協(xié)議的封裝，然后調用create_ip_packet函數，這個函數完成了把封裝好的UDP數據報再封裝成IP數據報。最后調用send_packet函數完成發(fā)送。
③傳輸層：如果IP數據報中的協(xié)議類型為17,則為UDP數據報，需要調用udp_process函數處理數據報。正確接收了數據后，給發(fā)送一個應答信息，上面已經提到了具體過程，這里不再復述了。這里介紹一下UDP協(xié)議的一個難點—UDP數據的和校驗。UDP和校驗要求加上UDP偽首部以后再進行校驗，偽首部格式包括32位源IP地址、32位目的IP地址、8位數據0、8位協(xié)議和16位UDP數據長度。作者根據接收緩沖區(qū)的內存管理特點，即接收緩沖區(qū)的成員結構共用同一塊數據存儲區(qū)，所以將IP協(xié)議的幀頭從生存時間開始到幀頭結束封裝成UDP偽首部。其實這樣做，只需將8位生存時間改為全0,16位首部和改為UDP數據長度即可，8位的協(xié)議、32位源IP地址和32位的目的IP地址不用改動。作UDP和校驗的時候，從IP協(xié)議幀頭的報文生存時間開始到IP數據報的數據部分結束作帶進位的相加，最后比較對和校驗就可以了。
④應用層：由于傳輸的是語音數據，將采集的數據經過A律壓縮放到DSP數據緩沖區(qū)databuf中，應用TCP/IIP協(xié)議將其發(fā)送給PC機。將PC機發(fā)送來的語音數據A律壓縮通過DSP的多通道緩沖串行口發(fā)送給聲卡。對于語音數據的處理，交給PC機完成，這里只實現數據的傳輸。
注：TCP/IP協(xié)議源碼見網站。
3.2PC機上的應用程序設計
使用的VB編程，利用Winsock控件完成語音數據的接收。這方面有很多例子可以借鑒，所以就不作太多的介紹。
結語
目前，基于DSP的嵌入式以太網的多媒體應用越來越受到廣泛的關注和應用，而且基于TCP/IP協(xié)議的嵌入式網絡系統(tǒng)已經成功地應用到了語音傳輸、遠程圖像控制和數據傳輸中。其便于操作、傳輸速度快等優(yōu)點，受到了有關專家的一致好評。本文利用數字信號處理器DSP和RTL8019AS完成了嵌入式智能設備接入以大網，成功實現了應用嵌入式網絡系統(tǒng)完成語音數據傳輸的功能。
【在TMS320VC5402上實現的嵌入式TCP/IP協(xié)議�！肯嚓P文章：
基于ARM的嵌入式TCP/IP協(xié)議的實現08-06
TCP/IP協(xié)議棧在嵌入式異構網絡互聯中的應用08-06
Linux對TCP/IP的支持淺析08-06
基于精簡TCP/IP協(xié)議棧的信息家電網絡服務器08-06
嵌入式TCP/IP協(xié)議單片機技術在網絡通信中的應用08-06
嵌入式 TCP/IP 協(xié)議單片機技術在網絡通信中的應用08-06
TCP/IP在網絡中的高效配置08-06