FreeRTOS进阶之任务通知示例完全解析
前言
在FreeRTOS版本V8.2.0中推出了全新的功能：任务通知。在大多数情况下，任务通知可以替代二进制信号量、计数信号量、事件组，可以替代长度为1的队列（可以保存一个32位整数或指针值），并且任务通知速度更快、使用的RAM更少！我在FreeRTOS任务通知一文中介绍了任务通知如何使用以及局限性，今天我们将分析任务通知的实现源码，看一下任务通知是如何做到效率与RAM消耗双赢的。
在FreeRTOS信号量分析一文中我们已经知道，FreeRTOS的信号量是使用队列机制实现的，数据结构也完全是队列的那一套。而任务通知则不同，它的数据结构嵌在任务TCB（任务控制块，见FreeRTOS进阶之任务创建中的，并且数据结构十分简单，涉及到任务TCB的两个字段，我们将它单独列出来：
volatile uint32_t ulNotifiedValue;
volatile uint8_t ucNotifyState; 这两个字段占用5字节RAM（本文都是在32位系统下讨论），而一个队列数据结构至少占用76字节RAM！这不是同一数量级的，所以任务通知在RAM消耗上完胜。
在分析队列和信号量的文章中，我们知道在使用队列、信号量前，必须先创建队列和信号量，目的是为了创建队列数据结构。比如使用API函数xQueueCreate()创建队列，用API函数xSemaphoreCreateBinary()创建二进制信号量等等。再来看任务通知，由于任务通知的数据结构包含在任务TCB中，只要任务存在，任务通知数据结构就已经创建完毕，可以直接使用！在易用性上，任务通知再次获胜。
要想了解任务通知在性能上占优的原因，就要分析源代码了。
只有任务可以等待通知，中断服务函数中不可以。如果等待的通知无效，任务会进入阻塞状态，我们可以将等待通知的任务看作是消费者；其它任务和中断可以向等待通知的任务发送通知，发送通知的任务和中断服务函数可以认为是生产者。处于阻塞的消费者得到通知后会再次进入就绪态。
任务通知API函数主要有两类，一类发送通知，一类等待通知。发送通知API函数可以用于任务和中断服务函数，等待通知API函数只能用在任务中。
1.发送通知
我们先看一下发送通知API函数。这类函数比较多，有6个。但仔细分析会发现它们只能完成3种操作，每种操作有两个API函数，分别为带中断保护版本和不带中断保护版本。FreeRTOS将API细分为带中断保护版本和不带中断保护版本是为了节省中断服务程序处理时间，提升性能。
和信号量类似，大多数发送通知API接口也是由宏实现的，如表1-1所示。
表1-1：发送通知API函数与实际调用函数列表
1.1 xTaskGenericNotify()
不带中断保护的发送通知API函数实际都是调用函数xTaskGenericNotify()实现的，我们看一下这个函数原型：
BaseType_t xTaskGenericNotify(
TaskHandle_t xTaskToNotify,
uint32_t ulValue,
eNotifyAction eAction,
uint32_t *pulPreviousNotificationValue )xTaskToNotify：被通知的任务句柄。
ulValue：更新的通知值
eAction：枚举类型，指明更新通知值的方法，枚举变量成员以及作用见表1-2所示。
pulPreviousNotifyValue：回传未被更新的任务通知值。如果不需要回传未被更新的任务通知值，这里设置为NULL。
表1-2：eNotifyAction枚举成员以及作用
与入队操作相比较，发送通知API函数显得非常简单，整理后的源码如下所示：
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();
if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
{
( void ) uxListRemove( &( pxTCB->xStateListItem ) );
prvAddTaskToReadyList( pxTCB );
if( pxTCB->uxPriority > pxCurrentTCB->uxPriority )
{
taskYIELD_IF_USING_PREEMPTION();
}
}
}
taskEXIT_CRITICAL();
return xReturn;
}函数的功能可以概括为：按照指定的方法更新通知值，如果被通知的任务处于阻塞状态，则将它解除阻塞，解除阻塞任务的优先级如果大于当前任务的优先级，则触发一次任务切换。
与释放信号量API函数相比，本函数少了很多调用子函数开销、少了很多判断、少了对事件列表的操作等等，确实是比释放信号量的实现要简洁的多。这也是有原因的，因为任务通知有它自己的局限性，并不能完全代替信号量。比如一个任务只能阻塞到一个通知上，如想要实现多个任务阻塞到同一个事件上，只能使用信号量了。也正是因为这种局限性，使得任务通知实现起来简单高效，并且大多数情况下，任务通知的方法就已经能解决问题了。
1.2 vTaskNotifyGiveFromISR()
这个API函数是vTaskNotifyGive()的带中断保护版本，是专门设计用来在某些情况下代替二进制信号量和计数信号量的。函数也很简单，我们直接看源码，源码经过整理和注释，以方便理解。
void vTaskNotifyGiveFromISR( TaskHandle_t xTaskToNotify, BaseType_t *pxHigherPriorityTaskWoken )
{
TCB_t * pxTCB;
uint8_t ucOriginalNotifyState;
UBaseType_t uxSavedInterruptStatus;
pxTCB = ( TCB_t * ) xTaskToNotify;
uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
{
ucOriginalNotifyState = pxTCB->ucNotifyState;
pxTCB->ucNotifyState = taskNOTIFICATION_RECEIVED;
( pxTCB->ulNotifiedValue )++;
if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
{
if( uxSchedulerSuspended == ( UBaseType_t ) pdFALSE )
{
( void ) uxListRemove( &( pxTCB->xStateListItem ) );
prvAddTaskToReadyList( pxTCB );
}
else
{
vListInsertEnd( &( xPendingReadyList ), &( pxTCB->xEventListItem ) );
}
if( pxTCB->uxPriority > pxCurrentTCB->uxPriority )
{
if( pxHigherPriorityTaskWoken != NULL )
{
*pxHigherPriorityTaskWoken = pdTRUE;
}
else
{
xYieldPending = pdTRUE;
}
}
}
}
portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );
}1.3 xTaskGenericNotifyFromISR()
如表1-1所示，带中断保护版本的API函数xTaskNotifyFromISR()和xTaskNotifyAndQueryFromISR()都是宏定义，真正被调用的函数为xTaskGenericNotifyFromISR()。
这个函数用于在中断在中发送通知，与不带中断保护的API函数xTaskGenericNotify()非常相似，只是增加了一些中断保护措施，我们直接看源码。通用源码经过整理和注释，以方便理解。
BaseType_t xTaskGenericNotifyFromISR( TaskHandle_t xTaskToNotify, uint32_t ulValue, eNotifyAction eAction, uint32_t *pulPreviousNotificationValue, BaseType_t *pxHigherPriorityTaskWoken )
{
TCB_t * pxTCB;
uint8_t ucOriginalNotifyState;
BaseType_t xReturn = pdPASS;
UBaseType_t uxSavedInterruptStatus;
pxTCB = ( TCB_t * ) xTaskToNotify;
uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
{
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_FROM_ISR();
if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
{
if( uxSchedulerSuspended == ( UBaseType_t ) pdFALSE )
{
( void ) uxListRemove( &( pxTCB->xStateListItem ) );
prvAddTaskToReadyList( pxTCB );
}
else
{
vListInsertEnd( &( xPendingReadyList ), &( pxTCB->xEventListItem ) );
}
if( pxTCB->uxPriority > pxCurrentTCB->uxPriority )
{
if( pxHigherPriorityTaskWoken != NULL )
{
*pxHigherPriorityTaskWoken = pdTRUE;
}
else
{
xYieldPending = pdTRUE;
}
}
}
}
portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );
return xReturn;
}2.等待通知
等待通知API函数只能用在任务中，没有带中断保护版本，因此只有两个API函数：
ulTaskNotifyTake()和xTaskNotifyWait ()
前者是为代替二进制信号量和计数信号量而专门设计的，它和发送通知API函数xTaskNotifyGive()、vTaskNotifyGiveFromISR()配合使用；
后者是全功能版的等待通知，可以根据不同的参数实现轻量级二进制信号量、计数信号量、事件组和长度为1的队列。
等待通知API函数都带有最大阻塞时间参数，当任务因为等待通知而进入阻塞时，用来规定最大阻塞时间。
2.1 ulTaskNotifyTake()
这个API函数用于实现轻量级的二进制信号量和计数信号量，源码如下所示。它有两个参数，如果第一个参数xClearCountOnExit设置为pdTRUE，则用来实现二进制信号量，函数退出时将通知值清零；如果第一个参数设置为pdFALSE，则用来实现计数信号量，函数退出时，将通知值减一。
uint32_t ulTaskNotifyTake( BaseType_t xClearCountOnExit, TickType_t xTicksToWait )
{
uint32_t ulReturn;
taskENTER_CRITICAL();
{
if( pxCurrentTCB->ulNotifiedValue == 0UL )
{
pxCurrentTCB->ucNotifyState = taskWAITING_NOTIFICATION;
if( xTicksToWait > ( TickType_t ) 0 )
{
prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
traceTASK_NOTIFY_TAKE_BLOCK();
portYIELD_WITHIN_API();
}
}
}
taskEXIT_CRITICAL();
taskENTER_CRITICAL();
{
traceTASK_NOTIFY_TAKE();
ulReturn = pxCurrentTCB->ulNotifiedValue;
if( ulReturn != 0UL )
{
if( xClearCountOnExit != pdFALSE )
{
pxCurrentTCB->ulNotifiedValue = 0UL;
}
else
{
pxCurrentTCB->ulNotifiedValue = ulReturn - 1;
}
}
pxCurrentTCB->ucNotifyState = taskNOT_WAITING_NOTIFICATION;
}
taskEXIT_CRITICAL();
return ulReturn;
}与获取二进制信号量和获取计数信号量函数相比，本函数少了很多调用子函数开销、少了很多判断、少了事件列表处理、少了队列上锁与解锁处理等等，因此本函数相对效率很高。
2.2 xTaskNotifyWait()
这个函数用于实现全功能版的等待通知，根据参数的不同，可以灵活的用于实现轻量级的队列、二进制信号量、计数信号量和事件组功能，函数原型为：
BaseType_t xTaskNotifyWait( uint32_tulBitsToClearOnEntry,
uint32_tulBitsToClearOnExit,
uint32_t*pulNotificationValue,
TickType_txTicksToWait );ulBitsToClearOnEntry：在使用通知之前，先将任务的通知值与参数ulBitsToClearOnEntry的按位取反值按位与操作。设置参数ulBitsToClearOnEntry为0xFFFFFFFF(ULONG_MAX)，表示清零任务通知值。
ulBitsToClearOnExit：在函数xTaskNotifyWait()退出前，将任务的通知值与参数ulBitsToClearOnExit的按位取反值按位与操作。设置参数ulBitsToClearOnExit为0xFFFFFFFF(ULONG_MAX)，表示清零任务通知值。
pulNotificationValue：用于向外回传任务的通知值。这个通知值在参数ulBitsToClearOnExit起作用前将通知值拷贝到*pulNotificationValue中。如果不需要返回任务的通知值，这里设置成NULL。
xTicksToWait：因等待通知而进入阻塞状态的最大时间。时间单位为系统节拍周期。宏pdMS_TO_TICKS用于将指定的毫秒时间转化为相应的系统节拍数。
这个函数的实现和ulTaskNotifyTake()有很多相通之处，我将整个流程以注释形式置于源码中，源码如下所示：
BaseType_t xTaskNotifyWait( uint32_t ulBitsToClearOnEntry, uint32_t ulBitsToClearOnExit, uint32_t *pulNotificationValue, TickType_t xTicksToWait )
{
BaseType_t xReturn;
taskENTER_CRITICAL();
{
if( pxCurrentTCB->ucNotifyState != taskNOTIFICATION_RECEIVED )
{
pxCurrentTCB->ulNotifiedValue &= ~ulBitsToClearOnEntry;
pxCurrentTCB->ucNotifyState = taskWAITING_NOTIFICATION;
if( xTicksToWait > ( TickType_t ) 0 )
{
prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
traceTASK_NOTIFY_WAIT_BLOCK();
portYIELD_WITHIN_API();
}
}
}
taskEXIT_CRITICAL();
taskENTER_CRITICAL();
{
traceTASK_NOTIFY_WAIT();
if( pulNotificationValue != NULL )
{
*pulNotificationValue = pxCurrentTCB->ulNotifiedValue;
}
if( pxCurrentTCB->ucNotifyState == taskWAITING_NOTIFICATION )
{
xReturn = pdFALSE;
}
else
{
pxCurrentTCB->ulNotifiedValue &= ~ulBitsToClearOnExit;
xReturn = pdTRUE;
}
pxCurrentTCB->ucNotifyState = taskNOT_WAITING_NOTIFICATION;
}
taskEXIT_CRITICAL();
return xReturn;
}纵观整个任务通知的实现，可以发现它比队列、信号量相比要简单很多。它可以实现轻量级的队列、二进制信号量、计数信号量和事件组，并且使用更方便、更节省RAM、更高效。FreeRTOS的作者做过测试，在同一平台下，使用使用GCC编译器、-o2优化级别，相比使用信号量解除任务阻塞，使用任务通知可以快45%！这个性能的提升是巨大的。
我们分析过信号量的源码，今天又分析了任务通知的源码，这使得我们知道，之所以有这么大的性能提升，一方面缘于任务通知数据结构简单、实现简洁；
另一方面也跟FreeRTOS的信号量机制臃肿、效率低下有关。因为信号量的实现全部是使用队列机制，并没有为信号量做专门优化。
此外，着重说明一下任务通知并不能完全代替队列、二进制信号量、计数信号量和事件组，任务通知有自己的局限性，我们就以它的局限性来结束本文：
只能有一个任务接收通知事件。
接收通知的任务可以因为等待通知而进入阻塞状态，但是发送通知的任务即便不能立即完成发送通知，也不能进入阻塞状态。
以上就是FreeRTOS进阶任务通知示例分析的详细内容，更多关于FreeRTOS任务通知分析的资料请关注编程网其它相关文章！
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
