实验程序经编码、调试后在交叉编译环境中交叉编译，生成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协议通信的具体实现，并分析了一种在实际嵌入式项目中常用的上位机数据报重发机制，最后对这种机制中的重发次数的确定方法给出了求解过程，为后续的具体项目实施提供了实践依据，也希望为其他应用这种重发机制的嵌入式产品开发者们提供了借鉴。
　　

参考文献

　　[1] 李伟.基于ARM9的嵌入式Linux手持平台的设计与实现[D].武汉:武汉理工大学硕士学位论文，2009.
　　 范艳开.基于ARM的嵌入式Linux操作系统移植[D].西安:西北工业大学，2005.
　　 刘畅，彭楚武.Linux下的UDP协议编程[J].仪表技术，2006(1).
　　 NEil Matthew Richard Stones.Beginning Linux Programming[M].2nd ed.Wrox Press，2002