FreeRTOS（21）---FreeRTOS 系統延時分析
FreeRTOS 系統延時分析
FreeRTOS 系統延時分析
FreeRTOS提供了兩個系統延時函式：相對延時函式vTaskDelay()和絕對延時函式vTaskDelayUntil()。相對延時是指每次延時都是從任務執行函式vTaskDelay()開始，延時指定的時間結束；絕對延時是指每隔指定的時間，執行一次呼叫vTaskDelayUntil()函式的任務。換句話說：任務以固定的頻率執行。
在《FreeRTOS（5）—FreeRTOS 任務控制》一文中，已經介紹了這兩個API函式的原型和用法，本文將分析這兩個函式的實現原理。
相對延時函式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。
圖1-1:相對延時函式執行示意圖
我們來看一下原始碼。
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指向的列表中。
每次系統節拍時鐘中斷，中斷服務函式都會檢查這兩個延時列表，檢視延時的任務是否到期，如果時間到期，則將任務從延時列表中刪除，重新加入就緒列表。如果新加入就緒列表的任務優先順序大於當前任務，則會觸發一次上下文切換。
絕對延時函式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( &xLastWakeTime,xFrequency );
// ...
// 這裡為任務主體程式碼,週期性執行.注意這和vTaskDelay()函式也不同
// ...
}
}
對於這樣一個任務，執行過程如圖2-1所示。當任務B獲取CPU使用權後，先呼叫系統延時函式vTaskDelayUntil()使任務進入阻塞狀態。任務B進入阻塞後，其它任務得以執行。FreeRTOS核心會週期性的檢查任務A的阻塞是否達到，如果阻塞時間達到，則將任務A設定為就緒狀態。由於任務B的優先順序最高，會搶佔CPU，接下來執行任務主體程式碼。任務主體程式碼執行完畢後，會繼續呼叫系統延時函式vTaskDelayUntil()使任務進入阻塞狀態，周而復始。
從圖2-1可以看出，從呼叫函式vTaskDelayUntil()開始，每隔固定週期，任務B的主體程式碼就會被執行一次，即使任務B在執行過程中發生中斷，也不會影響這個週期性，只是會縮短其它任務的執行時間！所以這個函式被稱為絕對延時函式，它可以用於週期性的執行任務A的主體程式碼。
圖2-1：絕對延時函式執行示意圖
函式vTaskDelayUntil()是如何做到週期性的呢，我們來看一下原始碼。
void vTaskDelayUntil( TickType_t * const pxPreviousWakeTime, const TickType_t xTimeIncrement )
{
TickType_t xTimeToWake;
BaseType_t xAlreadyYielded, xShouldDelay = pdFALSE;
vTaskSuspendAll();
{
/* 儲存系統節拍中斷次數計數器 */
const TickType_t xConstTickCount = xTickCount;
/* 計算任務下次喚醒時間(以系統節拍中斷次數表示) */
xTimeToWake = *pxPreviousWakeTime + xTimeIncrement;
/* *pxPreviousWakeTime中儲存的是上次喚醒時間,喚醒後需要一定時間執行任務主體程式碼,如果上次喚醒時間大於當前時間,說明節拍計數器溢位了 */
if( xConstTickCount < *pxPreviousWakeTime )
{
/*只有當週期性延時時間大於任務主體程式碼執行時間,才會將任務掛接到延時列表.*/
if( ( xTimeToWake < *pxPreviousWakeTime ) && ( xTimeToWake > xConstTickCount ) )
{
xShouldDelay = pdTRUE;
}
}
else
{
/* 也都是保證週期性延時時間大於任務主體程式碼執行時間 */
if( ( xTimeToWake < *pxPreviousWakeTime ) || ( xTimeToWake > xConstTickCount ) )
{
xShouldDelay = pdTRUE;
}
}
/* 更新喚醒時間,為下一次呼叫本函式做準備. */
*pxPreviousWakeTime = xTimeToWake;
if( xShouldDelay != pdFALSE )
{
/* 將本任務加入延時列表,注意阻塞時間並不是以當前時間為參考,因此減去了當前系統節拍中斷計數器值*/
prvAddCurrentTaskToDelayedList( xTimeToWake - xConstTickCount, pdFALSE );
}
}
xAlreadyYielded = xTaskResumeAll();
/* 強制執行一次上下文切換 */
if( xAlreadyYielded == pdFALSE )
{
portYIELD_WITHIN_API();
}
}
與相對延時函式vTaskDelay不同，本函式增加了一個引數pxPreviousWakeTime用於指向一個變數，變數儲存上次任務解除阻塞的時間。這個變數在任務開始時必須被設定成當前系統節拍中斷次數（見上文的任務B舉例），此後函式vTaskDelayUntil()在內部自動更新這個變數。
由於變數xTickCount可能會溢位，所以程式必須檢測各種溢位情況，並且要保證延時週期不得小於任務主體程式碼執行時間。這很好理解，不可能出現每5毫秒執行一個需要20毫秒才能執行完的任務。
如果我們以橫座標表示變數xTickCount的範圍，則橫座標左端為0，右端為變數xTickCount所能表示的最大值。在如圖2-2所示的三種情況下，才可以將任務加入延時列表。圖2-2中，*pxPreviousWakeTime和xTimeToWake之間表示任務週期性延時時間，*pxPreviousWakeTime和xConstTickCount之間表示任務B主體程式碼執行時間。
圖2-2中第一種情況處理系統節拍中斷計數器（xConstTickCount）和喚醒時間計數器（xTimeToWake）溢位情況；第二種情況處理喚醒時間計數器（xTimeToWake）溢位情況；第三種情況處理常規無溢位的情況。從圖中可以看出，不管是溢位還是無溢位，都要求在下次喚醒任務之前，當前任務主體程式碼必須被執行完。表現在圖2-2中，就是變數xTimeToWake總是大於變數xConstTickCount（每溢位一次的話相當於加上一次最大值Max）。
圖2-2：將任務加入延時列表的三種情況
計算的喚醒時間合法後，就將當前任務加入延時列表，同樣延時列表也有兩個。每次系統節拍中斷，中斷服務函式都會檢查這兩個延時列表，檢視延時的任務是否到期，如果時間到期，則將任務從延時列表中刪除，重新加入就緒列表。如果新加入就緒列表的任務優先順序大於當前任務，則會觸發一次上下文切換。
小結
上面的例子中，呼叫系統延時的任務都是最高優先順序，這是為了便於分析而特意為之的，實際上的任務可不一定能設定為最高優先順序。對於相對延時，如果任務不是最高優先順序，則任務執行週期更不可測，這個問題不大，我們本來也不會使用它作為精確延時；對於絕對延時函式，如果任務不是最高優先順序，則仍然能週期性的將任務解除阻塞，但是解除阻塞的任務不一定能獲得CPU許可權，因此任務主體程式碼也不會總是精確週期性執行。
如果要想精確週期性執行某個任務，可以使用系統節拍鉤子函式vApplicationTickHook()，它在系統節拍中斷服務函式中被呼叫，因此這個函式中的程式碼必須簡潔。