首先看看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自行进入休眠状态)。