摘要：進行UDP協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確保不丟失報文，上位機采取了按固定次數(shù)重發(fā)相同內(nèi)容報文的機制。這種機制雖然可以有效確保報文不丟失，但大量冗余數(shù)據(jù)報被發(fā)送，網(wǎng)絡資源利用率不高。顯然重發(fā)次數(shù)越多，冗余數(shù)據(jù)報越多，效率越低。要想有效保證數(shù)據(jù)報準確發(fā)送的同時又不產(chǎn)生過多冗余數(shù)據(jù)報，那么重復發(fā)送的次數(shù)的確定就成為問題的關(guān)鍵。以下給出一種確定上位機重發(fā)次數(shù)的方法。 關(guān)鍵詞：ARM；Linux；交叉編譯環(huán)境；UDP協(xié)議；重發(fā)機制；重發(fā)次數(shù)

UDP協(xié)議以其高效性和應用的簡單，被廣泛運用于嵌入式網(wǎng)絡開發(fā)中。由于UDP協(xié)議的應用簡單，在嵌入式設備開發(fā)過程中，網(wǎng)絡資源的利用率并不高。以下將介紹一個UDP具體項目實驗過程，描述ARM-Linux環(huán)境的軟硬件環(huán)境構(gòu)建過程，并對UDP協(xié)議下一種重發(fā)模式中上位機的重發(fā)次數(shù)的確定提出一種可行的方法。 1 研究背景 隨著嵌入式技術(shù)的快速發(fā)展，嵌入式設備已經(jīng)在許多領(lǐng)域取代了傳統(tǒng)的微型機設備。本文的選題主要來自于實習期間承接的一項改造項目：某院校特長生評分系統(tǒng)的改造。項目改造目的有：1) 保留原上位機。2) 改用手持式客戶端進行顯示及評分操作。3)保留原有網(wǎng)絡設備。針對要求，我們使用S3C2440作為硬件平臺，移植Linux操作系統(tǒng)，并在ARM-Linux環(huán)境下研究了UDP協(xié)議的通信過程，進行了上位機與嵌入式系統(tǒng)的UDP協(xié)議通信實驗及分析，并給出一種重發(fā)機制中的發(fā)送次數(shù)求法。 2 硬件平臺介紹 S3C2440處理速度達到了400MHZ，具有較高的性價比。為了提高開發(fā)效率，我們采用公司自行研制開發(fā)的ET-S3C2440開發(fā)板。 2.1 ET-S3C2440開發(fā)板簡介 ET-S3C2440是公司自行開發(fā)的一款ARM9架構(gòu)的實驗開發(fā)板，其結(jié)構(gòu)框圖如圖1。 核心板的主要器件有：32MB×2片SDRAM，64MB NORFLASH，512MB NANDFLASH。設計了啟動方式可選，通過開關(guān)選擇從Nandflash或Norflash啟動。 2.2 實驗相關(guān)電路說明 底板電路主要功能是輸入輸出以及網(wǎng)絡通訊功能。按鍵輸入部分采用掃描方式獲得輸入，用一個單向地址鎖存器和一個雙向地址鎖存器與地址總線相連，可以通過掃描地址來獲得按鍵輸入。LCD采用三星的3.5寸TFT屏作為顯示輸出設備。網(wǎng)卡芯片選用的是與原設備匹配的10M 的CS8900A，關(guān)于CS8900A與S3C2440的硬件連接，有眾多資源可供參考，本文不再贅述。 3 系統(tǒng)軟件平臺的構(gòu)建 硬件平臺搭建完畢后要將操作系統(tǒng)和應用程序在硬件平臺上運行起來。以下是對嵌入式Linux操作系統(tǒng)移植的過程。 3.1 交叉編譯環(huán)境的構(gòu)建 Linux 2.6.29.1版本的內(nèi)核可以登錄到下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈() 在宿主機上進入Linux系統(tǒng)，切換當前目錄到工具鏈所在目錄，新建一個arm目錄保存解壓后的文件(mkdir /user/local/arm)并將arm-linux-gcc-4.3.2解壓到這個目錄中(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)建好了。 3.2 BOOTLOADER的移植 vivi是一款相當成熟和相對簡單的常用bootloader，我們以vivi為移植原型，將S3C2440所有IO端口寄存器定義添加到頭文件2440add.inc，刪除部分硬件平臺使用不到的代碼，最后將修改過的vivi制作成鏡像燒錄到flash中。[1] 3.3 Linux內(nèi)核移植 獲取Linux-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_clocks(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_default_nand_part[]中保存的是nandflah的分區(qū)信息，將其修改為當前使用的分區(qū)信息)，然后修改nandflash的匹配時間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。

實驗程序經(jīng)編碼、調(diào)試后在交叉編譯環(huán)境中交叉編譯，生成arm-Linux環(huán)境下可執(zhí)行文件，在目標板上執(zhí)行。經(jīng)測試試驗程序能夠正確接收上位機發(fā)來的報文，對報文解碼，并能根據(jù)上位機命令對關(guān)鍵信息做輸出處理。 4.4 對上位機重發(fā)次數(shù)的研究 進行UDP協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確保不丟失報文，上位機采取了按固定次數(shù)重發(fā)相同內(nèi)容報文的機制。然而這種機制雖然可以有效確保報文不丟失，但是大量冗余數(shù)據(jù)報被發(fā)送，網(wǎng)絡資源利用率不高。重發(fā)次數(shù)越多，冗余數(shù)據(jù)報越多，效率越低。要想有效保證數(shù)據(jù)報準確發(fā)送的同時又不產(chǎn)生過多冗余數(shù)據(jù)報，那么重復發(fā)送的次數(shù)的確定就成為問題的關(guān)鍵。以下給出一種確定上位機重發(fā)次數(shù)的方法。 假設當前網(wǎng)絡狀況下，每次報文發(fā)送被丟失的概率為p，系統(tǒng)允許接收端報文關(guān)鍵內(nèi)容丟失概率為q，那么如何確定以上重發(fā)機制中的重發(fā)次數(shù)k呢？ 特殊情況下若報文重發(fā)次數(shù)為2，分別在每條報文重發(fā)機制位注明一個索引號和一個重發(fā)編號，發(fā)送端發(fā)送報文的次序應形如 1.1 ，1.2 ，2.1 ，2.2 ，3.1 ，3.2……其中索引號相同的報文關(guān)鍵內(nèi)容相同，重發(fā)編號不同代表同一關(guān)鍵內(nèi)容報文的不同次發(fā)送。因此只有出現(xiàn)連續(xù)兩次丟失數(shù)據(jù)報的情況下，報文關(guān)鍵內(nèi)容才可能丟失。出現(xiàn)連續(xù)兩次丟失的情況有2種，當x.1 ， x.2丟失，此時索引號為x的報文關(guān)鍵信息將全部丟失。當x.2，(x+1). 1丟失，丟失報文的索引號不同，此時不會發(fā)生報文關(guān)鍵信息丟失，因此報文關(guān)鍵內(nèi)容丟失的概率q=p2/2。

當報文重發(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ù)報的情況報文關(guān)鍵信息才可能丟失，列出連續(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丟失時不影響報文的準確傳遞。因此此時報文關(guān)鍵內(nèi)容丟失的概率q=p3/3。 推廣至一般情況易得當報文重發(fā)次數(shù)為k時，報文關(guān)鍵內(nèi)容丟失的概率q=pk/k，移項有kq=pk。于是我們得到求重發(fā)次數(shù)k的方法 1) 根據(jù)網(wǎng)絡狀況獲得報文丟失概率p； 2) 根據(jù)客戶需求取得報文關(guān)鍵內(nèi)容的允許丟失率范圍q； 3) 分別作出y=px和y=qx的圖像； 4) 求得兩圖像的交點的x坐標，并將x坐標值取整加一即為所求重發(fā)次數(shù)k。 本文實驗中，需求方允許報文關(guān)鍵信息丟失概率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.78取整加1得到k=3，即上位機對同一數(shù)據(jù)報的重發(fā)次數(shù)應該定為3次就可保證系統(tǒng)丟失報文的概率低于0.0001。 5 結(jié)論與展望 本文從硬件平臺搭建、Linux移植以及UDP協(xié)議編程幾個方面介紹了arm-Linux環(huán)境下UDP協(xié)議通信的具體實現(xiàn)，并分析了一種在實際嵌入式項目中常用的上位機數(shù)據(jù)報重發(fā)機制，最后對這種機制中的重發(fā)次數(shù)的確定方法給出了求解過程，為后續(xù)的具體項目實施提供了實踐依據(jù)，也希望為其他應用這種重發(fā)機制的嵌入式產(chǎn)品開發(fā)者們提供了借鑒。