FreeRTOS提供了兩個系統(tǒng)延時函數(shù)：相對延時函數(shù)vTaskDelay()和絕對延時函數(shù)vTaskDelayUntil()。

· 相對延時：指每次延時都是從任務(wù)執(zhí)行函數(shù)vTaskDelay()開始，延時指定的時間結(jié)束。

· 絕對延時：指每隔指定的時間，執(zhí)行一次調(diào)用vTaskDelayUntil()函數(shù)的任務(wù)。

相對延時函數(shù)

函數(shù)原型：void vTaskDelay( portTickType  xTicksToDelay )

函數(shù)參數(shù)xTicksToDelay：延時的時間長度，單位是系統(tǒng)時鐘節(jié)拍周期

函數(shù)用法分析：調(diào)用vTaskDelay()函數(shù)后，任務(wù)會進入阻塞狀態(tài)，持續(xù)時間由參數(shù)xTicksToDelay指定，單位是系統(tǒng)節(jié)拍時鐘周期。延時時間是從調(diào)用vTaskDelay()后開始計算的相對時間。比如vTaskDelay(100)，那么從調(diào)用vTaskDelay()后，任務(wù)進入阻塞狀態(tài)，經(jīng)過100個系統(tǒng)時鐘節(jié)拍周期后任務(wù)解除阻塞。

使用示例如下，示例中系統(tǒng)時鐘節(jié)拍設(shè)置為1ms，包含紅色和綠色LED兩個用戶任務(wù)，綠色LED任務(wù)的優(yōu)先級最高。在綠色LED閃爍的任務(wù)中，調(diào)用vTaskDelay函數(shù)延時100ms，執(zhí)行綠色LED任務(wù)需要50ms，任務(wù)再次執(zhí)行的時間間隔為延時時間100ms加上任務(wù)執(zhí)行花費的50ms共計150ms。低優(yōu)先級的紅色LED任務(wù)執(zhí)行10ms。

圖1

圖2

因為綠色LED任務(wù)為系統(tǒng)中最高優(yōu)先級任務(wù)，會搶占低優(yōu)先級紅色LED任務(wù)執(zhí)行，所以執(zhí)行過程中紅色LED任務(wù)并不會對vTaskDelay函數(shù)造成影響。綠色LED任務(wù)再次執(zhí)行的時間間隔為延時時間加上任務(wù)本身所用的時間，即延時時間100ms加上任務(wù)執(zhí)行時間50ms共150ms。在Tracealyzer中的跟蹤視圖中顯示的時間間隔圖3所示。

圖3

如果調(diào)用vTaskDelay()函數(shù)的任務(wù)在執(zhí)行過程中被更高優(yōu)先級的任務(wù)或者中斷所打斷，那么調(diào)用vTaskDelay()函數(shù)的任務(wù)將會受到影響，此時將不能保持一個固定的時間間隔運行。

繼續(xù)上文的例子，如果我們將綠色LED任務(wù)和紅色LED任務(wù)的優(yōu)先級進行調(diào)換，那么綠色LED任務(wù)在執(zhí)行過程中將被紅色LED任務(wù)打斷，那么我們可以再分析一下此時該任務(wù)的執(zhí)行情況。Tracealyzer的跟蹤視圖如圖4所示，可以看到綠色LED任務(wù)在執(zhí)行過程中被紅色LED任務(wù)搶占，紅色LED任務(wù)執(zhí)行了10ms，因此綠色LED任務(wù)的執(zhí)行間隔增加10ms變?yōu)榱?60ms。

紅色LED是否會搶占綠色LED任務(wù)，以及何時發(fā)生任務(wù)搶占都是難以預(yù)知的，因此綠色LED任務(wù)的執(zhí)行間隔或頻率也變得難以預(yù)測，這是在使用vTaskDelay()函數(shù)時需要注意的事項。

圖4

如果我們想要任務(wù)以固定的時間間隔重復(fù)運行，那么可以使用絕對延時函數(shù)。

絕對延時函數(shù)

函數(shù)原型：void vTaskDelayUntil( portTickType  *pxPreviousWakeTime, portTickType  xTimeIncrement );

函數(shù)參數(shù)：

pxPreviousWakeTime：指針，指向一個變量，該變量保存任務(wù)最后一次解除阻塞的時間。第一次使用前，該變量必須初始化為當(dāng)前時間。之后這個變量會在vTaskDelayUntil()函數(shù)內(nèi)自動更新。

xTimeIncrement：絕對延時時間，即任務(wù)重復(fù)執(zhí)行的時間間隔。

將上述例子中的vTaskDelay()函數(shù)替換為vTaskDelayUntil()函數(shù)，紅色LED任務(wù)的優(yōu)先級同樣高于綠色LED任務(wù)。

圖5

再次運行得到的跟蹤視圖如圖6所示，可以看到此時系統(tǒng)中仍然發(fā)生了任務(wù)搶占，但是綠色LED任務(wù)的執(zhí)行時間間隔為我們通過vTaskDelayUntil()函數(shù)指定的100ms。

調(diào)用vTaskDelayUntil()函數(shù)時，絕對延時的時間包含該任務(wù)本身的執(zhí)行時間，以及任務(wù)被打斷的時間。例如綠色LED任務(wù)執(zhí)行所用的50ms，以及紅色任務(wù)搶占占用的10ms，都屬于絕對延時的時間范圍內(nèi)。任務(wù)執(zhí)行過程中被短暫打斷也不會影響絕對延時，從而保證任務(wù)能夠以設(shè)定的時間周期重復(fù)運行。相對延時的時間則不會包含任務(wù)本身的執(zhí)行時間和任務(wù)被打斷的時間，這一點是兩種延時函數(shù)之間的重要區(qū)別。

注意事項：

如果任務(wù)延時過程中被打斷的時間太長，回來之后延時都超過了，那么則會立馬執(zhí)行程序，不會再執(zhí)行延時操作（任務(wù)不會再阻塞延時）。

上述示例中我們調(diào)用vTaskDelayUntil()函數(shù)的任務(wù)優(yōu)先級為最高優(yōu)先級任務(wù)，但實際應(yīng)用中可能并非如此，因此該任務(wù)依然可能被中斷或者更高優(yōu)先級的任務(wù)打斷，此時vTaskDelayUntil()函數(shù)延時時間到了之后該任務(wù)將恢復(fù)就緒狀態(tài)，但無法保證該任務(wù)能夠馬上執(zhí)行。

兩種延時函數(shù)都面臨可能存在的中斷或者高優(yōu)先級任務(wù)打斷的問題，無法保證任務(wù)一定能夠以指定的時間間隔重復(fù)運行，因此實踐中還需要借助類似Tracealyzer這樣的RTOS可視化分析工具進一步分析來保證RTOS復(fù)雜應(yīng)用的可靠性。

想學(xué)習(xí)并了解Tracezlyzer更多信息和知識，可以參考《嵌入式實時操作系統(tǒng)-基于STM32Cube、FreeRTOS和Tracealyzer的應(yīng)用開發(fā)》圖書！

歡迎關(guān)注微信公眾號【麥克泰技術(shù)】