FreeRTOS進階之系統(tǒng)延時完全解析
FreeRTOS提供了兩個系統(tǒng)延時函數(shù):相對延時函數(shù)vTaskDelay()和絕對延時函數(shù)
vTaskDelayUntil()。相對延時是指每次延時都是從任務執(zhí)行函數(shù)vTaskDelay()開始,延時指定的時間結束;
絕對延時是指每隔指定的時間,執(zhí)行一次調(diào)用vTaskDelayUntil()函數(shù)的任務。換句話說:任務以固定的頻率執(zhí)行。
在《FreeRTOS任務控制》一文中,已經(jīng)介紹了這兩個API函數(shù)的原型和用法,本文將分析這兩個函數(shù)的實現(xiàn)原理。
1. 相對延時函數(shù)vTaskDelay()
考慮下面的任務,任務A在執(zhí)行任務主體代碼后,調(diào)用相對延時函數(shù)vTaskDelay()進入阻塞狀態(tài)。系統(tǒng)中除了任務A外,還有其它任務,但是任務A的優(yōu)先級最高。
void vTaskA( void * pvParameters ) { /* 阻塞500ms. 注:宏pdMS_TO_TICKS用于將毫秒轉成節(jié)拍數(shù),FreeRTOS V8.1.0及 以上版本才有這個宏,如果使用低版本,可以使用 500 / portTICK_RATE_MS */ const portTickType xDelay = pdMS_TO_TICKS(500); for( ;; ) { // ... // 這里為任務主體代碼 // ... /* 調(diào)用系統(tǒng)延時函數(shù),阻塞500ms */ vTaskDelay( xDelay ); } }
對于這樣一個任務,執(zhí)行過程如圖1-1所示。當任務A獲取CPU使用權后,先執(zhí)行任務A的主體代碼,之后調(diào)用系統(tǒng)延時函數(shù)vTaskDelay()進入阻塞狀態(tài)。任務A進入阻塞后,其它任務得以執(zhí)行。
FreeRTOS內(nèi)核會周期性的檢查任務A的阻塞是否達到,如果阻塞時間達到,則將任務A設置為就緒狀態(tài)。由于任務A的優(yōu)先級最高,會搶占CPU,再次執(zhí)行任務主體代碼,不斷循環(huán)。
從圖1-1可以看出,任務A每次延時都是從調(diào)用延時函數(shù)vTaskDelay()開始算起的,延時是相對于這一時刻開始的,所以叫做相對延時函數(shù)。
從圖1-1還可以看出,如果執(zhí)行任務A的過程中發(fā)生中斷,那么任務A執(zhí)行的周期就會變長,所以使用相對延時函數(shù)vTaskDelay(),不能周期性的執(zhí)行任務A。
圖1-1:相對延時函數(shù)執(zhí)行示意圖
我們來看一下源碼。
void vTaskDelay( const TickType_t xTicksToDelay ) { BaseType_t xAlreadyYielded = pdFALSE; /* 如果延時時間為0,則不會將當前任務加入延時列表 */ if( xTicksToDelay > ( TickType_t ) 0U ) { vTaskSuspendAll(); { /* 將當前任務從就緒列表中移除,并根據(jù)當前系統(tǒng)節(jié)拍計數(shù)器值計算喚醒時間,然后將任務加入延時列表 */ prvAddCurrentTaskToDelayedList( xTicksToDelay, pdFALSE ); } xAlreadyYielded = xTaskResumeAll(); } /* 強制執(zhí)行一次上下文切換*/ if( xAlreadyYielded == pdFALSE ) { portYIELD_WITHIN_API(); } }
如果延時大于0,則會將當前任務從就緒列表刪除,然后加入到延時列表。是調(diào)用函數(shù)prvAddCurrentTaskToDelayedList()完成這一過程的。我們在前面一系列博文中多次提到,tasks.c中定義了很多局部靜態(tài)變量,其中有一個變量xTickCount定義如下所示:
static volatile TickType_t xTickCount = ( TickType_t ) 0U;
這個變量用來計數(shù),記錄系統(tǒng)節(jié)拍中斷的次數(shù),它在啟動調(diào)度器時被清零,在每次系統(tǒng)節(jié)拍時鐘發(fā)生中斷后加1。相對延時函數(shù)會使用到這個變量,xTickCount表示了當前的系統(tǒng)節(jié)拍中斷次數(shù),這個值加上參數(shù)規(guī)定的延時時間(以系統(tǒng)節(jié)拍數(shù)表示)xTicksToDelay,就是下次喚醒任務的時間,xTickCount+ xTicksToDelay會被記錄到任務TCB中,隨著任務一起被掛接到延時列表。
我們知道變量xTickCount是TickType_t類型的,它也會溢出。在32位架構中,當xTicksToDelay達到4294967295后再增加,就會溢出變成0。為了解決xTickCount溢出問題,F(xiàn)reeRTOS使用了兩個延時列表:xDelayedTaskList1和xDelayedTaskList2,并使用兩個列表指針類型變量pxDelayedTaskList和pxOverflowDelayedTaskList分別指向上面的延時列表1和延時列表2(在創(chuàng)建任務時將延時列表指針指向延時列表)。順便說一下,上面的兩個延時列表指針變量和兩個延時列表變量都是在tasks.c中定義的靜態(tài)局部變量。
如果內(nèi)核判斷出xTickCount+ xTicksToDelay溢出,就將當前任務掛接到列表指針pxOverflowDelayedTaskList指向的列表中,否則就掛接到列表指針pxDelayedTaskList指向的列表中。
每次系統(tǒng)節(jié)拍時鐘中斷,中斷服務函數(shù)都會檢查這兩個延時列表,查看延時的任務是否到期,如果時間到期,則將任務從延時列表中刪除,重新加入就緒列表。如果新加入就緒列表的任務優(yōu)先級大于當前任務,則會觸發(fā)一次上下文切換。
2. 絕對延時函數(shù)vTaskDelayUntil()
考慮下面的任務,任務B首先調(diào)用絕對延時函數(shù)vTaskDelayUntil ()進入阻塞狀態(tài),阻塞時間到達后,執(zhí)行任務主體代碼。系統(tǒng)中除了任務B外,還有其它任務,但是任務B的優(yōu)先級最高。
void vTaskB( void * pvParameters ) { static portTickType xLastWakeTime; const portTickType xFrequency = pdMS_TO_TICKS(500); // 使用當前時間初始化變量xLastWakeTime ,注意這和vTaskDelay()函數(shù)不同 xLastWakeTime = xTaskGetTickCount(); for( ;; ) { /* 調(diào)用系統(tǒng)延時函數(shù),周期性阻塞500ms */ vTaskDelayUntil( &xLastWakeTime,xFrequency ); // ... // 這里為任務主體代碼,周期性執(zhí)行.注意這和vTaskDelay()函數(shù)也不同 // ... } }
對于這樣一個任務,執(zhí)行過程如圖2-1所示。當任務B獲取CPU使用權后,先調(diào)用系統(tǒng)延時函數(shù)vTaskDelayUntil()使任務進入阻塞狀態(tài)。任務B進入阻塞后,其它任務得以執(zhí)行。FreeRTOS內(nèi)核會周期性的檢查任務A的阻塞是否達到,如果阻塞時間達到,則將任務A設置為就緒狀態(tài)。
由于任務B的優(yōu)先級最高,會搶占CPU,接下來執(zhí)行任務主體代碼。任務主體代碼執(zhí)行完畢后,會繼續(xù)調(diào)用系統(tǒng)延時函數(shù)vTaskDelayUntil()使任務進入阻塞狀態(tài),周而復始。
從圖2-1可以看出,從調(diào)用函數(shù)vTaskDelayUntil()開始,每隔固定+
-周期,任務B的主體代碼就會被執(zhí)行一次,即使任務B在執(zhí)行過程中發(fā)生中斷,也不會影響這個周期性,只是會縮短其它任務的執(zhí)行時間!所以這個函數(shù)被稱為絕對延時函數(shù),它可以用于周期性的執(zhí)行任務A的主體代碼。
圖2-1:絕對延時函數(shù)執(zhí)行示意圖
函數(shù)vTaskDelayUntil()是如何做到周期性的呢,我們來看一下源碼。
void vTaskDelayUntil( TickType_t * const pxPreviousWakeTime, const TickType_t xTimeIncrement ) { TickType_t xTimeToWake; BaseType_t xAlreadyYielded, xShouldDelay = pdFALSE; vTaskSuspendAll(); { /* 保存系統(tǒng)節(jié)拍中斷次數(shù)計數(shù)器 */ const TickType_t xConstTickCount = xTickCount; /* 計算任務下次喚醒時間(以系統(tǒng)節(jié)拍中斷次數(shù)表示) */ xTimeToWake = *pxPreviousWakeTime + xTimeIncrement; /* *pxPreviousWakeTime中保存的是上次喚醒時間,喚醒后需要一定時間執(zhí)行任務主體代碼,如果上次喚醒時間大于當前時間,說明節(jié)拍計數(shù)器溢出了 */ if( xConstTickCount < *pxPreviousWakeTime ) { /*只有當周期性延時時間大于任務主體代碼執(zhí)行時間,才會將任務掛接到延時列表.*/ if( ( xTimeToWake < *pxPreviousWakeTime ) && ( xTimeToWake > xConstTickCount ) ) { xShouldDelay = pdTRUE; } } else { /* 也都是保證周期性延時時間大于任務主體代碼執(zhí)行時間 */ if( ( xTimeToWake < *pxPreviousWakeTime ) || ( xTimeToWake > xConstTickCount ) ) { xShouldDelay = pdTRUE; } } /* 更新喚醒時間,為下一次調(diào)用本函數(shù)做準備. */ *pxPreviousWakeTime = xTimeToWake; if( xShouldDelay != pdFALSE ) { /* 將本任務加入延時列表,注意阻塞時間并不是以當前時間為參考,因此減去了當前系統(tǒng)節(jié)拍中斷計數(shù)器值*/ prvAddCurrentTaskToDelayedList( xTimeToWake - xConstTickCount, pdFALSE ); } } xAlreadyYielded = xTaskResumeAll(); /* 強制執(zhí)行一次上下文切換 */ if( xAlreadyYielded == pdFALSE ) { portYIELD_WITHIN_API(); } }
與相對延時函數(shù)vTaskDelay不同,本函數(shù)增加了一個參數(shù)pxPreviousWakeTime用于指向一個變量,變量保存上次任務解除阻塞的時間。這個變量在任務開始時必須被設置成當前系統(tǒng)節(jié)拍中斷次數(shù)(見上文的任務B舉例),此后函數(shù)vTaskDelayUntil()在內(nèi)部自動更新這個變量。
由于變量xTickCount可能會溢出,所以程序必須檢測各種溢出情況,并且要保證延時周期不得小于任務主體代碼執(zhí)行時間。這很好理解,不可能出現(xiàn)每5毫秒執(zhí)行一個需要20毫秒才能執(zhí)行完的任務。
如果我們以橫坐標表示變量xTickCount的范圍,則橫坐標左端為0,右端為變量xTickCount所能表示的最大值。在如圖2-2所示的三種情況下,才可以將任務加入延時列表。
圖2-2中
*pxPreviousWakeTime和xTimeToWake之間表示任務周期性延時時間,
*pxPreviousWakeTime和xConstTickCount之間表示任務B主體代碼執(zhí)行時間。
圖2-2中
第一種情況處理系統(tǒng)節(jié)拍中斷計數(shù)器(xConstTickCount)和喚醒時間計數(shù)器(xTimeToWake)溢出情況;
第二種情況處理喚醒時間計數(shù)器(xTimeToWake)溢出情況
第三種情況處理常規(guī)無溢出的情況。
從圖中可以看出,不管是溢出還是無溢出,都要求在下次喚醒任務之前,當前任務主體代碼必須被執(zhí)行完。表現(xiàn)在圖2-2中,就是變量xTimeToWake總是大于變量xConstTickCount(每溢出一次的話相當于加上一次最大值Max)。
圖2-2:將任務加入延時列表的三種情況
計算的喚醒時間合法后,就將當前任務加入延時列表,同樣延時列表也有兩個。每次系統(tǒng)節(jié)拍中斷,中斷服務函數(shù)都會檢查這兩個延時列表,查看延時的任務是否到期,如果時間到期,則將任務從延時列表中刪除,重新加入就緒列表。如果新加入就緒列表的任務優(yōu)先級大于當前任務,則會觸發(fā)一次上下文切換。
3.小結
上面的例子中,調(diào)用系統(tǒng)延時的任務都是最高優(yōu)先級,這是為了便于分析而特意為之的,實際上的任務可不一定能設置為最高優(yōu)先級。對于相對延時,如果任務不是最高優(yōu)先級,則任務執(zhí)行周期更不可測,這個問題不大,我們本來也不會使用它作為精確延時;
對于絕對延時函數(shù),如果任務不是最高優(yōu)先級,則仍然能周期性的將任務解除阻塞,但是解除阻塞的任務不一定能獲得CPU權限,因此任務主體代碼也不會總是精確周期性執(zhí)行。
如果要想精確周期性執(zhí)行某個任務,可以使用系統(tǒng)節(jié)拍鉤子函數(shù)vApplicationTickHook(),它在系統(tǒng)節(jié)拍中斷服務函數(shù)中被調(diào)用,因此這個函數(shù)中的代碼必須簡潔。
以上就是FreeRTOS進階之系統(tǒng)延時完全解析的詳細內(nèi)容,更多關于FreeRTOS進階系統(tǒng)延時分析的資料請關注腳本之家其它相關文章!
相關文章
FreeRTOS實時操作系統(tǒng)的列表與列表項操作示例
這篇文章主要為大家介紹了FreeRTOS實時操作系統(tǒng)的列表與列表項操作示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步早日升職加薪2022-04-04FreeRTOS動態(tài)內(nèi)存分配管理heap_1示例
這篇文章主要為大家介紹了FreeRTOS動態(tài)內(nèi)存分配管理heap_1的示例分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步早日升職加薪2022-04-04FreeRTOS動態(tài)內(nèi)存分配管理heap_4示例
這篇文章主要為大家介紹了FreeRTOS動態(tài)內(nèi)存分配管理heap_4示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步早日升職加薪2022-04-04FreeRTOS動態(tài)內(nèi)存分配管理heap_2示例
這篇文章主要介紹了FreeRTOS動態(tài)內(nèi)存分配管理heap_2示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步早日升職加薪2022-04-04