FreeRTOS兩種延時函數(shù)的區(qū)別是什么？

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

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

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

相對延時函數(shù)

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

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

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

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

圖1

圖2

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

圖3

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

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

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

圖4

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

絕對延時函數(shù)

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

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

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

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

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

圖5

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

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

注意事項：

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

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

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

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

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