FreeRTOS系統延時實例分析

這篇文章主要講解了“FreeRTOS系統延時實例分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“FreeRTOS系統延時實例分析”吧！

FreeRTOS提供了兩個系統延時函數：相對延時函數vTaskDelay()和絕對延時函數

vTaskDelayUntil()。相對延時是指每次延時都是從任務執行函數vTaskDelay()開始，延時指定的時間結束；

絕對延時是指每隔指定的時間，執行一次調用vTaskDelayUntil()函數的任務。換句話說：任務以固定的頻率執行。

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。

圖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指向的列表中。
        每次系統節拍時鐘中斷，中斷服務函數都會檢查這兩個延時列表，查看延時的任務是否到期，如果時間到期，則將任務從延時列表中刪除，重新加入就緒列表。如果新加入就緒列表的任務優先級大于當前任務，則會觸發一次上下文切換。

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( &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：將任務加入延時列表的三種情況

        計算的喚醒時間合法后，就將當前任務加入延時列表，同樣延時列表也有兩個。每次系統節拍中斷，中斷服務函數都會檢查這兩個延時列表，查看延時的任務是否到期，如果時間到期，則將任務從延時列表中刪除，重新加入就緒列表。如果新加入就緒列表的任務優先級大于當前任務，則會觸發一次上下文切換。

感謝各位的閱讀，以上就是“FreeRTOS系統延時實例分析”的內容了，經過本文的學習后，相信大家對FreeRTOS系統延時實例分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！