FreeRTOS系列第27篇---FreeRTOS系统延时分析

关注、星标公众号，直达精彩内容

ID：技术让梦想更伟大

作者:李肖遥

FreeRTOS提供了两个系统延时函数：相对延时函数vTaskDelay()和绝对延时函数vTaskDelayUntil()。

相对延时是指每次延时都是从任务执行函数vTaskDelay()开始，延时指定的时间结束；

绝对延时是指每隔指定的时间，执行一次调用vTaskDelayUntil()函数的任务，换句话说：任务以固定的频率执行。

在《FreeRTOS系列第11篇---FreeRTOS任务控制》一文中，已经介绍了这两个API函数的原型和用法，本文将分析这两个函数的实现原理。

1. 相对延时函数vTaskDelay()

考虑下面的任务，任务A在执行任务主体代码后，调用相对延时函数vTaskDelay()进入阻塞状态。

系统中除了任务A外，还有其它任务，但是任务A的优先级最高。

void vTaskA( void * pvParameters )  
 {  
     /* 阻塞500ms. 注:宏pdMS_TO_TICKS用于将毫秒转成节拍数,FreeRTOS V8.1.0及
        以上版本才有这个宏,如果使用低版本,可以使用 500 / portTICK_RATE_MS */  
     const portTickType xDelay = pdMS_TO_TICKS(500);  
   
     for( ;; )  
     {  
         //  ...
         //  这里为任务主体代码
         //  ...
        
         /* 调用系统延时函数,阻塞500ms */
         vTaskDelay( xDelay );  
     }  
}  
对于这样一个任务，执行过程如图1-1所示。

当任务A获取CPU使用权后，先执行任务A的主体代码，之后调用系统延时函数vTaskDelay()进入阻塞状态。

任务A进入阻塞后，其它任务得以执行。

FreeRTOS内核会周期性的检查任务A的阻塞是否达到，如果阻塞时间达到，则将任务A设置为就绪状态。

由于任务A的优先级最高，会抢占CPU，再次执行任务主体代码，不断循环。

从图1-1可以看出，任务A每次延时都是从调用延时函数vTaskDelay()开始算起的，延时是相对于这一时刻开始的，所以叫做相对延时函数。

从图1-1还可以看出，如果执行任务A的过程中发生中断，那么任务A执行的周期就会变长，所以使用相对延时函数vTaskDelay()，不能周期性的执行任务A。


**我们来看一下源码。**
void vTaskDelay( const TickType_t xTicksToDelay )
{
BaseType_t xAlreadyYielded = pdFALSE;
 
 
    /* 如果延时时间为0,则不会将当前任务加入延时列表 */
    if( xTicksToDelay > ( TickType_t ) 0U )
    {
        vTaskSuspendAll();
        {
            /* 将当前任务从就绪列表中移除,并根据当前系统节拍计数器值计算唤醒时间,然后将任务加入延时列表 */
            prvAddCurrentTaskToDelayedList( xTicksToDelay, pdFALSE );
        }
        xAlreadyYielded = xTaskResumeAll();
    }
 
 
    /* 强制执行一次上下文切换*/
    if( xAlreadyYielded == pdFALSE )
    {
        portYIELD_WITHIN_API();
    }
}
如果延时大于0，则会将当前任务从就绪列表删除，然后加入到延时列表。

是调用函数prvAddCurrentTaskToDelayedList()完成这一过程的。

我们在前面一系列博文中多次提到，tasks.c中定义了很多局部静态变量，其中有一个变量xTickCount定义如下所示：

static volatile TickType_t xTickCount = ( TickType_t ) 0U;
这个变量用来计数，记录系统节拍中断的次数，它在启动调度器时被清零，在每次系统节拍时钟发生中断后加1。

相对延时函数会使用到这个变量，xTickCount表示了当前的系统节拍中断次数，这个值加上参数规定的延时时间（以系统节拍数表示）xTicksToDelay，就是下次唤醒任务的时间，xTickCount xTicksToDelay会被记录到任务TCB中，随着任务一起被挂接到延时列表。

我们知道变量xTickCount是TickType_t类型的，它也会溢出。

在32位架构中，当xTicksToDelay达到4294967295后再增加，就会溢出变成0。

为了解决xTickCount溢出问题，FreeRTOS使用了两个延时列表：xDelayedTaskList1和xDelayedTaskList2，并使用两个列表指针类型变量pxDelayedTaskList和pxOverflowDelayedTaskList分别指向上面的延时列表1和延时列表2（在创建任务时将延时列表指针指向延时列表）。

「顺便说一下」，上面的两个延时列表指针变量和两个延时列表变量都是在tasks.c中定义的静态局部变量。

如果内核判断出xTickCount xTicksToDelay溢出，就将当前任务挂接到列表指针pxOverflowDelayedTaskList指向的列表中，否则就挂接到列表指针pxDelayedTaskList指向的列表中。

每次系统节拍时钟中断，中断服务函数都会检查这两个延时列表，查看延时的任务是否到期，如果时间到期，则将任务从延时列表中删除，重新加入就绪列表。如果新加入就绪列表的任务优先级大于当前任务，则会触发一次上下文切换。

2. 绝对延时函数vTaskDelayUntil()

考虑下面的任务，任务B首先调用绝对延时函数vTaskDelayUntil ()进入阻塞状态，阻塞时间到达后，执行任务主体代码。

系统中除了任务B外，还有其它任务，但是任务B的优先级最高。

void vTaskB( void * pvParameters )  
{  
    static portTickType xLastWakeTime;  
    const portTickType xFrequency = pdMS_TO_TICKS(500);  
   
    // 使用当前时间初始化变量xLastWakeTime ,注意这和vTaskDelay()函数不同 
    xLastWakeTime = xTaskGetTickCount();  
   
    for( ;; )  
    {  
        /* 调用系统延时函数,周期性阻塞500ms */        
        vTaskDelayUntil(