VxWorks下的多重定时器设计

VxWorks是一种嵌入式实时操作系统(RTOS)，具有内核小、可裁剪、实时性强等特点。VxWorks内核(Wind)提供了共享内存、信号量、消息队列、套接字通信和定时器等多种机制。为了实现基于UDP网络的可靠通信，本文利用VxWorks的多种任务间通信机制和看门狗定时器机制，设计了一种多重定时器模型，该模型可以确保数据包的可靠传递。

1 VxWOrks的时钟及定时器机制

1.1 VxWorks延时函数

VxWorks既提供了延时功能，也提供了时限约束功能。VxWorks系统有2种延时方式：一种是Wind内核提供的taskDelay()函数;另一种是POSIX函数nanosleep()。

taskDelay()函数以tick作为延时单位，默认情况下1个tick为16.67 ms(1/60 s)，可以通过调用sysClkRateSet()函数对tick进行重新设定。taskDelay()函数使调用该函数的任务在指定时间内主动放弃 CPU，用于任务调度或等待某一外部事件。nanosleep()函数指定一个以s和ns为单位的睡眠或延时时间。其实，两个延时函数的精度是相同的，都是以tick为时间基准。不同之处在于，taskDelay(0)有自身意义，用于相同优先级任务间的任务调度，而nanosleep(0)是没有意义的。

1.2 VxWorks定时器机制

VxWorks提供一种看门狗定时器机制(watchdogtimer)，可以用来处理任务的时限约束。看门狗定时器作为系统时钟中断服务程序的一部分来维护，因此，看门狗定时器的回调函数以系统时钟中断级作为中断服务程序执行。看门狗定时器回调函数受到中断服务程序的限制，不能调用可能引起阻塞的函数，比如试图获取信号量，调用malloc()和free()等创建和释放内存函数或执行I/O操作。

POSIX定时器也可以处理任务时限。此外，VxWorks中一些函数具有时限控制的功能，semTake()、msgQSend()、 msgQReceive()函数中都有设定时限控制的参数。超时参数NO_WAIT意味着立即返回，而WAIT_FOREVER意味着程序永不超时。

2 多重定时器实现要求

在VxWorks系统下，利用网络套接字建立基于UDP协议的客户端/服务器通信模式。由于UDP是无连接的协议，发送方并不清楚发出的数据包是否已经正确到达接收方，于是提出一种支持重传和定时等待确认的协议。

这个协议要求发送方发送的数据包与接收方回复的确认包具有对应的序列号，发送方和接收方都可以通过序列号来判断是不是想要得到的数据包。序列号是循环的，考虑到如果序列号太小会出现折返情况产生混淆，所以序列号至少大于2。如果用1个字节来表示序列号，则可以设定序列号为256。

发送方送出一个数据包后启动一个定时器。这时可能会有4种情况发生：

①发送方接收到正确序号的确认包，则发送下一序列号的数据包。

②发送方接收到已经接收过的重复确认包，则丢弃该确认包继续等待。如果在超时前收到了正确确认包，则发送下一序列号的数据包。

③定时器超时，没有收到想要的确认包，则重新发送数据包，启动下一定时器。

④设定的多重定时器超时后，没有收到想要确认包，则通知网络管理设备。

接收方在收到所需序列号的数据包后，回复一个确认包给发送方。如果接收方回复的确认包后没有正确到达发送方，则会引起发送方超时，重新发送原序列号数据包。接收方收到数据包后，需要检查数据包序列号。如果是重复序列号数据包，则丢弃，但是依旧回复确认包给发送方，以免已发送确认包在发送过程中丢失。这里基于支持重传和定时等待确认协议。具体要求是，在客户端通过UDP协议发送数据包后启动一个定时器，等待接收服务器端回复的 ACK(acknowl-edgement)确认包。如果成功接收，则继续发送下一序列号的数据包;如果超时后还没有收到需要的确认包，则重新传输原序列号的数据包。图1所示为数据包均按时、正确地接收的情况。

一般情况下，假定启动定时器30 ms内可以完成从发送数据包到接收ACK确认包的全过程，但是由于某些原因使得30 ms内无法收到确认包，则会重传原数据包，并启动一个稍长的40 ms定时器。如果40 ms还无法收到确认，则再次重传原数据包，并启动一个考虑到最差情况的60 ms定时器。如果依旧无法收到确认则不再发送，通知网络管理设备。

出现定时器超时情况有3种可能：发送方发送数据包过程中丢包;接收方发送确认包过程中丢包;从发送数据包到确认包到达发送方过程中，延时时间超过定时时间。造成超时有两方面原因：一是，双方终端在接收数据包时由于缓冲问题不能及时处理，使得终端出现延时接收数据包或丢包;二是，通信链路发生断链情况，导致双方无法进行通信。从图2中可以看到，如果链路没有断开，则包含3种情况的三重定时器超时情况。

3 多重定时器设计

3.1 设计方案

选用看门狗定时器机制来设计。看门狗定时器操作较为简单，只有4个函数，即wdCreate()、wdDelete()、wdStart()、wdCancel()。看门狗定时器与调用任务异步执行，并不阻塞调用任务，所以看门狗定时器很适合多任务的非阻塞计时。

当看门狗定时器启动后，如果在规定的30 ms内收到了正确的确认包，就会将定时器取消掉，继续发送下面的数据包。如果30 ms规定时间内没有收到确认数据包ACK，则需要重新发送数据包，并启动第2个40 ms的定时器。VxWorks中单CPU的任务间常用通信机制是消息队列。当定时器到时后利用消息队列向发送任务发送消息，通知发送任务重新发送数据包，启动下一定时器。看门狗定时器的回调函数可以执行msgQSend()这种向消息队列发送消息的函数，我们通过msgQSend()函数向主任务发送时限已达消息。但是，将msgQSend()的延时参数设为wAIT_FOREVER时，消息队列中一旦没有了可用缓冲，则进入等待状态。由于中断服务程序优先级高，而从消息队列中接收消息的优先级低，当有任务准备从消息队列中取消息时，要等待中断服务程序执行完毕，则消息队列始终处于已满状态，造成系统死锁。如果将msgQSend()函数中的延时参数改为NO_WAIT，则可避免一直等待向消息队列发消息的情况，一旦消息队列已满就将该消息丢弃。但这样一来，向接收端发送数据包任务接收不到定时器超时消息，不会重发原序列号数据包和启动下一定时器，所以使用参数NO_WAIT也不可行。[!--empirenews.page--]

这里提出一种避免上述情况造成系统死锁的方法，即使用信号量机制来使msgQSend()不在中断服务程序中执行。通过使用信号量的任务间同步机制来实现这个功能。释放信号量函数semGive()不像msgQSend()那样需要在消息队列中等待，一旦执行就可以马上释放信号量，从而避免了冲突。

由于任务中事件发生有一定间隔，不必选用计数器信号量，所以选用最常用的二进制信号量。首先建立3个先进先出的二进制信号量，设定可调用信号量为空。然后在看门狗定时器的回调函数中使用semGive()函数来释放信号量，重建一个任务在任务起始使用semTake()函数来获取信号量。当获得信号量后，通过msgQSend(，，，WAIT_FOREVER，)函数向消息队列中发送超时消息，而且保证只要消息队列有可用缓冲，就一定可以将消息送出。本文给出一个多重定时器的任务框架，如图3所示。

3.2 主要实现代码

一个三重定时器的主要实现代码如下：

以上程序中通过sysClkRateSet(100)将最小延时单位tick修改成10 ms，它是几个定时时间(30 ms、40 ms、60ms)的最大公约数。通过抓包软件Ethereal抓包，查看发送时间。以30 ms为例，抓包100次的平均定时时间在25 ms左右。出现这种情况的原因是，延时N个tick实际是延时(N-1)tick~N·tick。由于是等可能概率，则它的数学期望是(N+1/2)。对于tick为10 ms，30 ms即N=3，数学期望为25 ms。示意图如图4所示。

延时精度为1/N秒，N越大越精确。于是调用函数synClkRateSet(500)，可以使定时的最大误差不超过2 ms。但是如果时钟频率太高，会造成系统在时钟中断处理方面开销太大，影响系统的任务调度，最好通过实验选用较为合适的时钟频率。这里选用 sysClkRate-Set(200)。

结 语

本文针对VxWorks下UDP网络通信中的可靠传输问题，提出了一个支持重传和定时等待确认的协议，并利用VxWorks系统提供的信号量同步、消息队列和看门狗定时器等多种机制，综合设计了一种可扩展的三重定时器。针对遇到的具体问题，笔者还进行了一定的优化处理。这种多重定时器模型已在笔者所研究的项目中得到利用，验证了其可行性和相对稳定性。这种多重定时器模型并不完全适合所有环境，需要根据具体情况改进和优化。