FreeRTOS系列第26篇---FreeRTOS任務通知分析

關注、星標公眾號，直達精彩內容

ID：技術讓夢想更偉大

整理：李肖遙

在FreeRTOS版本V8.2.0中推出了全新的功能：任務通知。

在大多數(shù)情況下，任務通知可以替代二進制信號量、計數(shù)信號量、事件組，可以替代長度為1的隊列（可以保存一個32位整數(shù)或指針值），并且任務通知速度更快、使用的RAM更少！

我在《 FreeRTOS系列第14篇---FreeRTOS任務通知》一文中介紹了任務通知如何使用以及局限性，今天我們將分析任務通知的實現(xiàn)源碼，看一下任務通知是如何做到效率與RAM消耗雙贏的。

在《FreeRTOS高級篇6---FreeRTOS信號量分析》一文中我們已經(jīng)知道，F(xiàn)reeRTOS的信號量是使用隊列機制實現(xiàn)的，數(shù)據(jù)結構也完全是隊列的那一套。

而任務通知則不同，它的數(shù)據(jù)結構嵌在任務TCB（任務控制塊，見《FreeRTOS高級篇2---FreeRTOS任務創(chuàng)建分析》）中的，并且數(shù)據(jù)結構十分簡單，涉及到任務TCB的兩個字段，我們將它單獨列出來：

volatile?uint32_t?ulNotifiedValue;??/*任務通知值*/??
volatile uint8_t ucNotifyState;?/*任務通知狀態(tài)，標識任務是否在等待通知等*/
這兩個字段占用5字節(jié)RAM（本文都是在32位系統(tǒng)下討論），而一個隊列數(shù)據(jù)結構至少占用76字節(jié)RAM！這不是同一數(shù)量級的，所以任務通知在RAM消耗上完勝。

在分析隊列和信號量的文章中，我們知道在使用隊列、信號量前，必須先創(chuàng)建隊列和信號量，目的是為了創(chuàng)建隊列數(shù)據(jù)結構。

比如使用API函數(shù)xQueueCreate()創(chuàng)建隊列，用API函數(shù)xSemaphoreCreateBinary()創(chuàng)建二進制信號量等等。

再來看任務通知，由于任務通知的數(shù)據(jù)結構包含在任務TCB中，只要任務存在，任務通知數(shù)據(jù)結構就已經(jīng)創(chuàng)建完畢，可以直接使用！在易用性上，任務通知再次獲勝。

要想了解任務通知在性能上占優(yōu)的原因，就要分析源代碼了。

只有任務可以等待通知，中斷服務函數(shù)中不可以。

如果等待的通知無效，任務會進入阻塞狀態(tài)，我們可以將等待通知的任務看作是消費者；

其它任務和中斷可以向等待通知的任務發(fā)送通知，發(fā)送通知的任務和中斷服務函數(shù)可以認為是生產者。

處于阻塞的消費者得到通知后會再次進入就緒態(tài)。

任務通知API函數(shù)主要有兩類，一類發(fā)送通知，一類等待通知。

發(fā)送通知API函數(shù)可以用于任務和中斷服務函數(shù)，等待通知API函數(shù)只能用在任務中。

1.發(fā)送通知

我們先看一下發(fā)送通知API函數(shù)。這類函數(shù)比較多，有6個。

但仔細分析會發(fā)現(xiàn)它們只能完成3種操作，每種操作有兩個API函數(shù)，分別為帶中斷保護版本和不帶中斷保護版本。

FreeRTOS將API細分為帶中斷保護版本和不帶中斷保護版本是為了節(jié)省中斷服務程序處理時間，提升性能。

和信號量類似，大多數(shù)發(fā)送通知API接口也是由宏實現(xiàn)的，如表1-1所示。

1.1 xTaskGenericNotify()

不帶中斷保護的發(fā)送通知API函數(shù)實際都是調用函數(shù)xTaskGenericNotify()實現(xiàn)的，我們看一下這個函數(shù)原型：

BaseType_t?xTaskGenericNotify(?
????????TaskHandle_t?xTaskToNotify,?
????????uint32_t?ulValue,?
????????eNotifyAction?eAction,?
????????uint32_t?*pulPreviousNotificationValue?)


• 「xTaskToNotify」：被通知的任務句柄。
• 「ulValue」：更新的通知值
• 「eAction」：枚舉類型，指明更新通知值的方法，枚舉變量成員以及作用見表1-2所示。
• 「pulPreviousNotifyValue」：回傳未被更新的任務通知值。如果不需要回傳未被更新的任務通知值，這里設置為NULL。

與入隊操作相比較，發(fā)送通知API函數(shù)顯得非常簡單，整理后的源碼如下所示：

BaseType_t?xTaskGenericNotify(?TaskHandle_t?xTaskToNotify,?uint32_t?ulValue,?eNotifyAction?eAction,?uint32_t?*pulPreviousNotificationValue?)
{
TCB_t?*?pxTCB;
BaseType_t?xReturn?=?pdPASS;
uint8_t?ucOriginalNotifyState;
?
?
????configASSERT(?xTaskToNotify?);
????pxTCB?=?(?TCB_t?*?)?xTaskToNotify;
?
?
????taskENTER_CRITICAL();
????{
????????if(?pulPreviousNotificationValue?!=?NULL?)
????????{
???/*?回傳更新前的通知值*/
????????????*pulPreviousNotificationValue?=?pxTCB->ulNotifiedValue;
????????}
?
?
????????ucOriginalNotifyState?=?pxTCB->ucNotifyState;
?
?
????????pxTCB->ucNotifyState?=?taskNOTIFICATION_RECEIVED;
?
?
????????switch(?eAction?)
????????{
????????????case?eSetBits???:
????????????????pxTCB->ulNotifiedValue?|=?ulValue;
????????????????break;
?
?
????????????case?eIncrement?:
????????????????(?pxTCB->ulNotifiedValue?) ;
????????????????break;
?
?
????????????case?eSetValueWithOverwrite?:
????????????????pxTCB->ulNotifiedValue?=?ulValue;
????????????????break;
?
?
????????????case?eSetValueWithoutOverwrite?:
????????????????if(?ucOriginalNotifyState?!=?taskNOTIFICATION_RECEIVED?)
????????????????{
????????????????????pxTCB->ulNotifiedValue?=?ulValue;
????????????????}
????????????????else
????????????????{
????????????????????/*?上次的通知值還未取走,本次通知值丟棄?*/
????????????????????xReturn?=?pdFAIL;
????????????????}
????????????????break;
?
?
????????????case?eNoAction:
????????????????/*?不需要更新通知值*/
????????????????break;
????????}
?
?
????????traceTASK_NOTIFY();
?
?
????????/*?如果被通知的任務因為等待通知而阻塞,現(xiàn)在將它解除阻塞?*/
????????if(?ucOriginalNotifyState?==?taskWAITING_NOTIFICATION?)
????????{
????????????(?void?)?uxListRemove(?