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

UDP協議以其高效性和應用的簡單，被廣泛運用于嵌入式網絡開發中。由于UDP協議的應用簡單，在嵌入式設備開發過程中，網絡資源的利用率并不高。以下將介紹一個UDP具體項目實驗過程，描述ARM-Linux環境的軟硬件環境構建過程，并對UDP協議下一種重發模式中上位機的重發次數的確定提出一種可行的方法。 1 研究背景 隨著嵌入式技術的快速發展，嵌入式設備已經在許多領域取代了傳統的微型機設備。本文的選題主要來自于實習期間承接的一項改造項目：某院校特長生評分系統的改造。項目改造目的有：1) 保留原上位機。2) 改用手持式客戶端進行顯示及評分操作。3)保留原有網絡設備。針對要求，我們使用S3C2440作為硬件平臺，移植Linux操作系統，并在ARM-Linux環境下研究了UDP協議的通信過程，進行了上位機與嵌入式系統的UDP協議通信實驗及分析，并給出一種重發機制中的發送次數求法。 2 硬件平臺介紹 S3C2440處理速度達到了400MHZ，具有較高的性價比。為了提高開發效率，我們采用公司自行研制開發的ET-S3C2440開發板。 2.1 ET-S3C2440開發板簡介 ET-S3C2440是公司自行開發的一款ARM9架構的實驗開發板，其結構框圖如圖1。 核心板的主要器件有：32MB×2片SDRAM，64MB NORFLASH，512MB NANDFLASH。設計了啟動方式可選，通過開關選擇從Nandflash或Norflash啟動。 2.2 實驗相關電路說明 底板電路主要功能是輸入輸出以及網絡通訊功能。按鍵輸入部分采用掃描方式獲得輸入，用一個單向地址鎖存器和一個雙向地址鎖存器與地址總線相連，可以通過掃描地址來獲得按鍵輸入。LCD采用三星的3.5寸TFT屏作為顯示輸出設備。網卡芯片選用的是與原設備匹配的10M 的CS8900A，關于CS8900A與S3C2440的硬件連接，有眾多資源可供參考，本文不再贅述。 3 系統軟件平臺的構建 硬件平臺搭建完畢后要將操作系統和應用程序在硬件平臺上運行起來。以下是對嵌入式Linux操作系統移植的過程。 3.1 交叉編譯環境的構建 Linux 2.6.29.1版本的內核可以登錄到下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈() 在宿主機上進入Linux系統，切換當前目錄到工具鏈所在目錄，新建一個arm目錄保存解壓后的文件(mkdir /user/local/arm)并將arm-linux-gcc-4.3.2解壓到這個目錄中(tar jxvf arm-linux-gcc-4.3.2 –C /user/local/arm)。然后將環境變量$PATH修改一下，讓$PATH中包含有arm-linux-gcc所在的目錄(編輯/etc/profile 添加語句”export PATH=/user/local/arm/4.3.2/bin:$PATH”)，然后reboot一下，這樣交叉編譯環境就構建好了。 3.2 BOOTLOADER的移植 vivi是一款相當成熟和相對簡單的常用bootloader，我們以vivi為移植原型，將S3C2440所有IO端口寄存器定義添加到頭文件2440add.inc，刪除部分硬件平臺使用不到的代碼，最后將修改過的vivi制作成鏡像燒錄到flash中。[1] 3.3 Linux內核移植 獲取Linux-2.6.29.1源代碼并解壓后，首先修改內核源代碼所在目錄中的Makefile，將系統架構修改為Arm(ARCH ?=arm )，交叉編譯工具修改為arm-linux-gcc (CROSS_COMPILE ?=arm-linux-)，修改輸入時鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中的函數static void __init smdk2440_map_io中，修改s3c24xx_init_clocks(12000000)此處所用晶振為12M)。修改machine名稱(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函數MACHINE_START( )，修改為MACHINE_START(S3C2440， “自定義機器名”)，修改NANDflash分區信息(arch/arm/plat-s3c24xx/common-smdk.c結構體static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分區信息，將其修改為當前使用的分區信息)，然后修改nandflash的匹配時間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。

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

當報文重發次數為3，依然在每條報文的重發機制位注明索引號和重發號，發送報文的次序應為1.1 ，1.2 ，1.3 ，2.1 ，2.2 ，2.3 ，3.1 ，3.2……。只有出現連續3次丟失數據報的情況報文關鍵信息才可能丟失，列出連續3次丟失報文的情況有3種，當x.1 ， x.2 ， x.3丟失，此時索引號為x的報文信息全部丟失。當x.2 ， x.3 ，(x+1).1或x.3 ，(x+1).1 ，(x+1).2丟失時不影響報文的準確傳遞。因此此時報文關鍵內容丟失的概率q=p3/3。 推廣至一般情況易得當報文重發次數為k時，報文關鍵內容丟失的概率q=pk/k，移項有kq=pk。于是我們得到求重發次數k的方法 1) 根據網絡狀況獲得報文丟失概率p； 2) 根據客戶需求取得報文關鍵內容的允許丟失率范圍q； 3) 分別作出y=px和y=qx的圖像； 4) 求得兩圖像的交點的x坐標，并將x坐標值取整加一即為所求重發次數k。 本文實驗中，需求方允許報文關鍵信息丟失概率q=0.0001，我們分別對上位機發送端和下位機接收端收發的報文進行了統計，在某一固定時間段內，上位機共發送報文19665條，接收端接收報文18636條，傳輸過程中丟失的報文19665-18636=1029條，當前網絡環境下的報文丟失率為，即p=0.0523。據此數值分別作出y=0.0001x的曲線和y=0.0523 x的曲線，取得兩曲線交點x坐標為x≈2.78，最后將x=2.78取整加1得到k=3，即上位機對同一數據報的重發次數應該定為3次就可保證系統丟失報文的概率低于0.0001。 5 結論與展望 本文從硬件平臺搭建、Linux移植以及UDP協議編程幾個方面介紹了arm-Linux環境下UDP協議通信的具體實現，并分析了一種在實際嵌入式項目中常用的上位機數據報重發機制，最后對這種機制中的重發次數的確定方法給出了求解過程，為后續的具體項目實施提供了實踐依據，也希望為其他應用這種重發機制的嵌入式產品開發者們提供了借鑒。