淺談arm-linux環(huán)境下udp協(xié)議的通信應用研究

1、<p>　　淺談ARM-Linux環(huán)境下UDP協(xié)議的通信應用研究</p><p>　　摘要：進行UDP協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確保不丟失報文，上位機采取了按固定次數(shù)重發(fā)相同內(nèi)容報文的機制。這種機制雖然可以有效確保報文不丟失，但大量冗余數(shù)據(jù)報被發(fā)送，網(wǎng)絡資源利用率不高。顯然重發(fā)次數(shù)越多，冗余數(shù)據(jù)報越多，效率越低。要想有效保證數(shù)據(jù)報準

2、確發(fā)送的同時又不產(chǎn)生過多冗余數(shù)據(jù)報，那么重復發(fā)送的次數(shù)的確定就成為問題的關鍵。以下給出一種確定上位機重發(fā)次數(shù)的方法。</p><p>　　關鍵詞：ARM；Linux；交叉編譯環(huán)境；UDP協(xié)議；重發(fā)機制；重發(fā)次數(shù) </p><p>　　UDP協(xié)議以其高效性和應用的簡單，被廣泛運用于嵌入式網(wǎng)絡開發(fā)中。由于UDP協(xié)議的應用簡單，在嵌入式設備開發(fā)過程中，網(wǎng)絡資源的利用率并不高。以下將介紹一個UDP

3、具體項目實驗過程，描述ARM-Linux環(huán)境的軟硬件環(huán)境構(gòu)建過程，并對UDP協(xié)議下一種重發(fā)模式中上位機的重發(fā)次數(shù)的確定提出一種可行的方法。</p><p><b>　　1 研究背景</b></p><p>　　隨著嵌入式技術的快速發(fā)展，嵌入式設備已經(jīng)在許多領域取代了傳統(tǒng)的微型機設備。本文的選題主要來自于實習期間承接的一項改造項目：某院校特長生評分系統(tǒng)的改造。項目改造目

4、的有：1) 保留原上位機。2) 改用手持式客戶端進行顯示及評分操作。3)保留原有網(wǎng)絡設備。針對要求，我們使用S3C2440作為硬件平臺，移植Linux操作系統(tǒng)，并在ARM-Linux環(huán)境下研究了UDP協(xié)議的通信過程，進行了上位機與嵌入式系統(tǒng)的UDP協(xié)議通信實驗及分析，并給出一種重發(fā)機制中的發(fā)送次數(shù)求法。</p><p><b>　　2 硬件平臺介紹</b></p><p&

5、gt;　　S3C2440處理速度達到了400MHZ，具有較高的性價比。為了提高開發(fā)效率，我們采用公司自行研制開發(fā)的ET-S3C2440開發(fā)板。</p><p>　　2.1 ET-S3C2440開發(fā)板簡介</p><p>　　ET-S3C2440是公司自行開發(fā)的一款ARM9架構(gòu)的實驗開發(fā)板，其結(jié)構(gòu)框圖如圖1。</p><p>　　核心板的主要器件有：32MB×

6、;2片SDRAM，64MB NORFLASH，512MB NANDFLASH。設計了啟動方式可選，通過開關選擇從Nandflash或Norflash啟動。</p><p>　　2.2 實驗相關電路說明</p><p>　　底板電路主要功能是輸入輸出以及網(wǎng)絡通訊功能。按鍵輸入部分采用掃描方式獲得輸入，用一個單向地址鎖存器和一個雙向地址鎖存器與地址總線相連，可以通過掃描地址來獲得按鍵輸入。LC

7、D采用三星的3.5寸TFT屏作為顯示輸出設備。網(wǎng)卡芯片選用的是與原設備匹配的10M 的CS8900A，關于CS8900A與S3C2440的硬件連接，有眾多資源可供參考，本文不再贅述。</p><p>　　3 系統(tǒng)軟件平臺的構(gòu)建</p><p>　　硬件平臺搭建完畢后要將操作系統(tǒng)和應用程序在硬件平臺上運行起來。以下是對嵌入式Linux操作系統(tǒng)移植的過程。</p><p&g

8、t;　　3.1 交叉編譯環(huán)境的構(gòu)建</p><p>　　Linux 2.6.29.1版本的內(nèi)核可以登錄到下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈()</p><p>　　在宿主機上進入Linux系統(tǒng)，切換當前目錄到工具鏈所在目錄，新建一個arm目錄保存解壓后的文件(mkdir /user/local/arm)并將arm-linux-gcc-4.3.2解壓到這個目錄中(

9、tar jxvf arm-linux-gcc-4.3.2 –C /user/local/arm)。然后將環(huán)境變量$PATH修改一下，讓$PATH中包含有arm-linux-gcc所在的目錄(編輯/etc/profile 添加語句”export PATH=/user/local/arm/4.3.2/bin:$PATH”)，然后reboot一下，這樣交叉編譯環(huán)境就構(gòu)建好了。</p><p>　　3.2 BOOTLOA

10、DER的移植</p><p>　　vivi是一款相當成熟和相對簡單的常用bootloader，我們以vivi為移植原型，將S3C2440所有IO端口寄存器定義添加到頭文件2440add.inc，刪除部分硬件平臺使用不到的代碼，最后將修改過的vivi制作成鏡像燒錄到flash中。[1]</p><p>　　3.3 Linux內(nèi)核移植</p><p>　　獲取Linux

11、-2.6.29.1源代碼并解壓后，首先修改內(nèi)核源代碼所在目錄中的Makefile，將系統(tǒng)架構(gòu)修改為Arm(ARCH ?=arm ),交叉編譯工具修改為arm-linux-gcc (CROSS_COMPILE ?=arm-linux-)，修改輸入時鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中的函數(shù)static void __init smdk2440_map_io中，修改s3c24xx_init_clo

12、cks(12000000)此處所用晶振為12M)。修改machine名稱(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函數(shù)MACHINE_START( ),修改為MACHINE_START(S3C2440, “自定義機器名”)，修改NANDflash分區(qū)信息(arch/arm/plat-s3c24xx/common-smdk.c結(jié)構(gòu)體static struct mtd_partition smdk

13、_default_nand_part[]中保存的是nandflah的分區(qū)信息，將其修改為當前使用的分區(qū)信息</p><p>　　上述內(nèi)核源代碼修改完成后，還需要對一些設備的驅(qū)動進行修改。本文使用的NEC 3.5寸 320×240液晶屏，硬件平臺使用GPG4腳進行背光控制，需要修改LCD背光(/arch/arm/mach-s3c2440/mach-smdk2440.c中static void __init

14、 smdk2440_machine_init(void)，將函數(shù)中的GPIO口配置為GPG4)。關于CS8900A網(wǎng)卡的驅(qū)動移植，相關資源很豐富，本文也不再贅述。</p><p>　　本實驗中nandflash采用的是yaffs2文件系統(tǒng)，所以打yaffs2文件系統(tǒng)補丁，壓縮包為cvs-root.tar.gz。</p><p>　　至此，Linux的內(nèi)核源代碼修改工作完成了，下面還需要利用

15、Makefile,進行內(nèi)核配置。</p><p>　　在Linux 2.6.29.1內(nèi)核目錄下首先make s3c2410_defconfig使用2410的配置模板來配置2440；然后make menuconfig,這時我們可以在圖形化界面中，空格鍵可改變各個配置選項的被選中狀態(tài)，根據(jù)需要進行配置即可。配置完成后保存好配置，最后進行內(nèi)核的編譯(make dep 建立文件間依賴 make clean 清除編譯殘留文

16、件make zImage 生成內(nèi)核壓縮鏡像文件)。</p><p>　　編譯過程完成后會在內(nèi)核目錄arch/arm/boot/下生成zImage內(nèi)核映像文件，將這個鏡像文件燒錄到flash中，調(diào)試檢驗，經(jīng)上述修改后的內(nèi)核工作運行正常。</p><p>　　3.4 根文件系統(tǒng)的制作</p><p>　　根文件系統(tǒng)是使用busybox-1.13.3來制作完成。下載bus

17、ybox并解壓完成后，修改Makefile中的架構(gòu)為ARM架構(gòu)，編譯工具為arm-linux-gcc( ARCH ?=arm； CROSS_COMPILE ?=arm-linux-),然后Make menuconfig,通過圖形界面對busybox進行配置，然后對busybox進行編譯(make CONFIG_PREFIX=/opt/studyarm/rootfs install)，在目標目錄下會生成目錄bin、sbin、usr和文件l

18、inuxrc的內(nèi)容。</p><p>　　基本目錄結(jié)構(gòu)生成后，應該在目標目錄下建立一些未生成的必要的系統(tǒng)目錄如dev、etc、lib等，并通過chmod命令改變目錄權限為可寫。再將一些必要的動態(tài)鏈接庫和靜態(tài)庫拷貝到lib下，然后在dev目錄下創(chuàng)建設備節(jié)點，最后創(chuàng)建該嵌入式Linux系統(tǒng)的初始化配置文件(包括設備列表文件、口令、網(wǎng)絡分組組名、HOSTNAME主機名、etc/inittab初始化表單、etc/prof

19、ile環(huán)境變量配置文件、用于系統(tǒng)初始化的.bash腳本文件等)。由于本實驗需對網(wǎng)絡編程，要求自動初始化CS8900A網(wǎng)卡芯片的IP地址、網(wǎng)關、子網(wǎng)掩碼等，所以在開機自啟動腳本中加入ifconfig語句，使得開機時自動配置網(wǎng)卡參數(shù)。</p><p>　　根文件系統(tǒng)構(gòu)建完成后，使用yaffs2文件系統(tǒng)制作工具mkyaffs2image.tgz，通過命令mkyaffs2image rootfs rootfs.img生成

20、根文件系統(tǒng)鏡像，然后將鏡像燒寫入flash中。</p><p>　　4 ARM-Linux環(huán)境下的UDP協(xié)議通信實驗</p><p>　　經(jīng)過上述硬件設計和操作系統(tǒng)移植過程，本文所使用到的實驗環(huán)境已經(jīng)構(gòu)建完畢，經(jīng)反復調(diào)試修改，嵌入式Linux操作系統(tǒng)在平臺下運行正常，于是進行UDP協(xié)議通信實驗。</p><p>　　4.1 UDP協(xié)議套接字編程基礎</p>

21、;<p>　　UDP是一個面向數(shù)據(jù)報和無連接的簡單傳輸層協(xié)議，它不像TCP那樣通過握手過程建立服務器與客戶端的連接才可以工作。在網(wǎng)絡通信質(zhì)量較好的情況下，UDP體現(xiàn)出高效率，這適合于傳送少量報文的應用。 linux系統(tǒng)是通過套接字結(jié)構(gòu)來進行網(wǎng)絡編程的，應用程序通過對套接字的幾個函數(shù)調(diào)用，會返回一個用于通信的套接字描述符,而Linux應用程序在進行任何形式的I/O操作時，程序?qū)嶋H上是在讀寫一個文件描述符。因此Linux下的套

22、接字編程，可以看成是對普通文件描述符的操作，這些操作與被使用的硬件平臺無關，這是linux設備無關性的優(yōu)點。UDP協(xié)議的通信模型如圖3所示。</p><p>　　在上述流程中，客戶端所收到的報文被存儲在緩沖區(qū)中，recvfrom()函數(shù)返回了報文存儲緩沖區(qū)的首地址，我們可以很方便地對這個首地址進行數(shù)組操作，從而實現(xiàn)對報文的解碼。</p><p>　　4.2 上位機報文結(jié)構(gòu)及重發(fā)機制分析&l

23、t;/p><p>　　根據(jù)項目要求，上位機軟件依然保留，我們使用協(xié)議嗅探工具對上位機發(fā)送的報文進行了嗅探，得到了上位機報文的結(jié)構(gòu)如表1所示。</p><p>　　表1 上位機報文結(jié)構(gòu)</p><p>　　上位機發(fā)出的每條報文由32個字節(jié)組成，第0位為版本信息。第1……12位為比賽信息和運動員教練信息，是報文的關鍵信息部分，13……22位為服務器端和客戶端的IP地址及端口

24、號信息，23位是上位機對客戶端的操作指令代碼，24位是相關重發(fā)機制的代碼，30和31兩位是CheckSum，用來保證數(shù)據(jù)傳輸?shù)恼_。上位機采用的重發(fā)機制是一種上位機按照固定重發(fā)次數(shù)多次發(fā)送同一關鍵內(nèi)容報文的機制，其第24位重發(fā)機制位被分為高4位和低4位兩部分，高四位的內(nèi)容是當前發(fā)送的報文的索引號，每次發(fā)送一條新內(nèi)容的報文時索引號自增1，索引號的取值范圍在0x00—0xFF范圍內(nèi)循環(huán)自增。低四位是重發(fā)編號，表示同一索引號的報文正在被第幾次

25、重發(fā)，固定的重發(fā)次數(shù)由上位機初始化時設定。</p><p>　　4.3 嵌入式客戶端的實驗程序設計</p><p>　　針對報文結(jié)構(gòu)，我們對接收端編寫實驗程序代碼，代碼的主要功能是從上位機接收報文，將計算出的CheckSum校驗和與收到的校驗和對比判斷報文是否正確，然后從正確報文中取出主要信息并按照報文中的上位機指令碼進行輸出。其結(jié)構(gòu)流程圖如圖3所示。</p><p&g

26、t;　　實驗程序經(jīng)編碼、調(diào)試后在交叉編譯環(huán)境中交叉編譯，生成arm-Linux環(huán)境下可執(zhí)行文件，在目標板上執(zhí)行。經(jīng)測試試驗程序能夠正確接收上位機發(fā)來的報文，對報文解碼，并能根據(jù)上位機命令對關鍵信息做輸出處理。</p><p>　　4.4 對上位機重發(fā)次數(shù)的研究</p><p>　　進行UDP協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確

27、保不丟失報文，上位機采取了按固定次數(shù)重發(fā)相同內(nèi)容報文的機制。然而這種機制雖然可以有效確保報文不丟失，但是大量冗余數(shù)據(jù)報被發(fā)送，網(wǎng)絡資源利用率不高。重發(fā)次數(shù)越多，冗余數(shù)據(jù)報越多，效率越低。要想有效保證數(shù)據(jù)報準確發(fā)送的同時又不產(chǎn)生過多冗余數(shù)據(jù)報，那么重復發(fā)送的次數(shù)的確定就成為問題的關鍵。以下給出一種確定上位機重發(fā)次數(shù)的方法。</p><p>　　假設當前網(wǎng)絡狀況下，每次報文發(fā)送被丟失的概率為p，系統(tǒng)允許接收端報文關鍵

28、內(nèi)容丟失概率為q,那么如何確定以上重發(fā)機制中的重發(fā)次數(shù)k呢？</p><p>　　特殊情況下若報文重發(fā)次數(shù)為2，分別在每條報文重發(fā)機制位注明一個索引號和一個重發(fā)編號，發(fā)送端發(fā)送報文的次序應形如 1.1 ,1.2 ,2.1 ,2.2 ,3.1 ,3.2……其中索引號相同的報文關鍵內(nèi)容相同，重發(fā)編號不同代表同一關鍵內(nèi)容報文的不同次發(fā)送。因此只有出現(xiàn)連續(xù)兩次丟失數(shù)據(jù)報的情況下，報文關鍵內(nèi)容才可能丟失。出現(xiàn)連續(xù)兩次丟失的

29、情況有2種，當x.1 , x.2丟失，此時索引號為x的報文關鍵信息將全部丟失。當x.2,(x+1). 1丟失，丟失報文的索引號不同，此時不會發(fā)生報文關鍵信息丟失，因此報文關鍵內(nèi)容丟失的概率q=p2/2。</p><p>　　當報文重發(fā)次數(shù)為3,依然在每條報文的重發(fā)機制位注明索引號和重發(fā)號，發(fā)送報文的次序應為1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只有出現(xiàn)連續(xù)3次丟失數(shù)據(jù)報

30、的情況報文關鍵信息才可能丟失，列出連續(xù)3次丟失報文的情況有3種，當x.1 , x.2 , x.3丟失，此時索引號為x的報文信息全部丟失。當x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丟失時不影響報文的準確傳遞。因此此時報文關鍵內(nèi)容丟失的概率q=p3/3。</p><p>　　推廣至一般情況易得當報文重發(fā)次數(shù)為k時，報文關鍵內(nèi)容丟失的概率q=pk/k，移項有kq=pk。于是我們得

31、到求重發(fā)次數(shù)k的方法</p><p>　　1) 根據(jù)網(wǎng)絡狀況獲得報文丟失概率p； </p><p>　　2) 根據(jù)客戶需求取得報文關鍵內(nèi)容的允許丟失率范圍q；</p><p>　　3) 分別作出y=px和y=qx的圖像；</p><p>　　4) 求得兩圖像的交點的x坐標，并將x坐標值取整加一即為所求重發(fā)次數(shù)k。</p><

32、;p>　　本文實驗中，需求方允許報文關鍵信息丟失概率q=0.0001,我們分別對上位機發(fā)送端和下位機接收端收發(fā)的報文進行了統(tǒng)計，在某一固定時間段內(nèi)，上位機共發(fā)送報文19665條，接收端接收報文18636條，傳輸過程中丟失的報文19665-18636=1029條，當前網(wǎng)絡環(huán)境下的報文丟失率為，即p=0.0523。據(jù)此數(shù)值分別作出y=0.0001x的曲線和y=0.0523 x的曲線，取得兩曲線交點x坐標為x≈2.78，最后將x=2.7

33、8取整加1得到k=3，即上位機對同一數(shù)據(jù)報的重發(fā)次數(shù)應該定為3次就可保證系統(tǒng)丟失報文的概率低于0.0001。</p><p><b>　　5 結(jié)論與展望</b></p><p>　　本文從硬件平臺搭建、Linux移植以及UDP協(xié)議編程幾個方面介紹了arm-Linux環(huán)境下UDP協(xié)議通信的具體實現(xiàn)，并分析了一種在實際嵌入式項目中常用的上位機數(shù)據(jù)報重發(fā)機制，最后對這種機制

34、中的重發(fā)次數(shù)的確定方法給出了求解過程，為后續(xù)的具體項目實施提供了實踐依據(jù)，也希望為其他應用這種重發(fā)機制的嵌入式產(chǎn)品開發(fā)者們提供了借鑒。</p><p><b>　　參考文獻： </b></p><p>　　[1] 李偉.基于ARM9的嵌入式Linux手持平臺的設計與實現(xiàn)[D].武漢:武漢理工大學碩士學位論文,2009.</p><p>　　范艷