嵌入式多节点的无线批量程序更新系统设计

，分别指链表的读出点和写入点，执行一次读出或写入操作后，tail或head指针都向前移动一次，整数的作用是统计当前链表上可用节点的数目。Deluge_buf结构体定义如下：

struct Deluge_buf {

struct data_entry queue_data[QUEUE_LENGTH]; // The data of current queue

uint8 recv_num;

uint8 queue_head;

uint8 queue_tail;

};

值得注意的是结构体data_entry中Payload项的组成在不同类型的帧中是不同的，比如数据帧中Payload包括页号p、帧号id和数据data以及数据长度data_len，而广告帧中只包含p和id，因此解析方法要根据type值来区分。

帧结构DelugeData

如图五所示，DelugeData定义了帧类型（type）等六个数据项，设计中根据不同的帧类型规定了各个数据项的含义，具体定义如表4.1所示，"-"表示该数据项在帧中没有定义。

表4.1 DelugeData中数据项含义的定义

3、缓冲区Flash_buf

因为写flash操作比网络传输慢得多，为了避免写flash拖慢整个数据分发速度，建立缓冲区Flash_buf用于缓存准备好的数据。Flash_buf也是一个环形缓冲区，原理和Deluge_buf相同。缓冲区的节点包含p、id、data三个数据项和指针域next，其中data是要写入flash的数据，p和id用于计算待写入的flash地址。

3.3.3 可靠数据分发协议的软件架构设计

可靠数据分发协议的软件构架设计包括发送端和接收端两块内容。发送端软件运行在数据基站上，分为两个阶段，第一阶段通知节点连续地发送整个文件，第二阶段运行状态机参与到节点的交流中去；接收端软件运行在待烧录节点上，第一个阶段尽可能多的接收基站发送来的数据，第二阶参与节点间讨论。因为发送端第一阶段软件比较简单，第二阶段和接收端相同，所以这里只重点介绍接收端的软件构架设计。

第一阶段：

程序完成初始化后进入准备接收状态，当数据帧到来时将数据提取出来写到flash相应的地址（地址由页号p和帧号id计算得到），并将该帧标记为"完成帧"；若接收到结束帧，则记录结束帧的页号p_max和帧号id_max并进入第二阶段；若接收到其他类型帧则直接进入第二阶段。第一阶段的软件流程图如图4.6所示。

图4.6 接收端软件第一阶段流程图

第二阶段：

完成第一轮接收后，程序运行ADV-REQ-DATA状态机，和其他节点交流，完善或帮助其他节点完善数据文件。状态机分为MAINTAIN（维护）、RX（请求）和TX（发送）三个状态，程序首先进入MAINTAIN状态。MAINTAIN状态下，程序监听广告帧和请求帧并在适当时机发送广告，根据协议规定，程序可能跳转到RX状态或TX状态进行数据帧请求和发送操作，操作完成后返回MAINTAIN状态。程序中定义一个最长时间t_max，如果MAINTAIN状态持续时间超过t_max，则认为整个数据分发过程结束，程序检查自己接收到的数据是否完备后退出。第二阶段的软件流程图如图4.7所示。

图4.7 接收端软件第二阶段流程图

四 系统测试

本测试将用三个程序作为用例，以测试系统的可用性。三个程序分别为：

Led.bin实现简单的跑马灯；

GoAhead.bin 三辆小车将一直向前方走，即使碰到障碍物也不停止；

RandomWalk.bin 三辆小车将进行随机行走，并且碰到障碍物后会进行壁障，转弯。

首先我们将批量更新跑马灯的程序，然后我们来看GoAhead.bin，如图5.1所示。完整的程序镜像大小为3340Bytes

图5.1 GoAhead.bin的大小

当前在节点上已经运行了Led.bin,我们将使用Led.bin和GoAhead.bin进行比较，生成patc