OSTimeDlyHMSM()-用户不能结束延时调用

由于OSTimeDlyHMSM()的具体实现方法，用户不能结束延时调用OSTimeDlyHMSM()要求延时超过65535 个节拍的任务。换句话说，如果时钟节拍的频率是100Hz，用户不能让调用OSTimeDlyHMSM(0，10，55，350)或更长延迟时间的任务结束延时

首先看看100Hz下，调用函数OSTimeDlyHMSM(0, 10, 55, 350)以后，函数OSTimeDlyHMSM中的局部变量的值是多少呢？

10 * 60 * 100 + 55 * 100 + 100 * ( 350 + 500 / 100 ) / 1000 = 65535.5。由于在计算后面那个100 * ( 350 + 500 / 100 ) / 1000的时候，参与计算的类型默认都是整型，因此，应该得到65535。

作者的意思是：如果某个任务在100Hz下需要延时比10min 55 sec 350milli更长的时间，那么您将无法使用函数OSTimeDlyResume来恢复这个任务。

看看TCB结构体中的.OSTCBDly域的类型吧（书上P81）。看到了吧，这个类型是一个unsigned short的类型，其取值范围为0 ~ 65535。

然后回到函数OSTimeDlyHMSM中来。函数为了能够延长更久的时间，这里我们举个例子，比如，要延时11分钟，那么调用函数OSTimeDlyHMSM后，其局部变量ticks = 11 * 60 * 100 = 66000。

loops = ticks / 65536L = 66000 / 65536L = 1L;
ticks = ticks % 65536L = 66000 % 65536L = 464L;

OSTimeDly(ticks);            // A
while (loops > 0)             // B
{
    OSTimeDly(32768);     // C
    OSTimeDly(32768);     // D
    loops --;
}
若任务1调用函数OSTimeDlyHMSM(0, 11, 0, 0);并进入了休眠状态，此时休眠的tick状态

位置在A位置，在此处另外一个任务2运行，任务2调用OSTimeDlyResume试图恢复任务1

的延时等待。经过了函数调用，任务1进入就绪状态并在下一个tick进入运行状态。此

时，任务1会继续执行B，并判断出来其对应的loops不为零（因为函数STimeDlyResume

没能清除对应任务的栈内的局部变量loops，这不是设计的失误，但是有可以改进的地

方），而继续休眠（C位置代码被执行并使任务1自行进入休眠状态）。