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

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

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

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

相對(duì)延時(shí)函數(shù)

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

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

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

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

圖1

圖2

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

圖3

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

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

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

圖4

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

絕對(duì)延時(shí)函數(shù)

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

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

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

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

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

圖5

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

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

注意事項(xiàng)：

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

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

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

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

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