FreeRTOS进阶之任务通知示例完全解析

目录
  • 前言
  • 1.发送通知
    • 1.1 xTaskGenericNotify()
    • 1.2 vTaskNotifyGiveFromISR()
    • 1.3 xTaskGenericNotifyFromISR()
  • 2.等待通知
    • 2.1 ulTaskNotifyTake()
    • 2.2 xTaskNotifyWait()

前言

在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 )
            {
                /* 如果被通知的任务优先级高于当前任务,则触发PendSV中断,退出临界区后进行上下文切换T*/
                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;
        /* 通知值加1,相当于释放了一个信号量 */
        ( 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();
    {
        /* 仅当通知值为0,才进行阻塞操作*/
        if( pxCurrentTCB->ulNotifiedValue == 0UL )
        {
            /* 设置标志,表示当前任务等待一个通知*/
            pxCurrentTCB->ucNotifyState = taskWAITING_NOTIFICATION;
            if( xTicksToWait > ( TickType_t ) 0 )
            {
                /* 将任务加入延时列表 */
                prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
                traceTASK_NOTIFY_TAKE_BLOCK();
                /* 触发PendSV中断,等到退出临界区时立即执行任务切换 */
                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;    /* 如果返回值为0,说明是任务阻塞超时了 */
}

与获取二进制信号量和获取计数信号量函数相比,本函数少了很多调用子函数开销、少了很多判断、少了事件列表处理、少了队列上锁与解锁处理等等,因此本函数相对效率很高。

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 )
        {
            /* 使用任务通知值之前,先将参数ulBitsToClearOnEntryClear取反后与任务通知值位与.可以用这种方法在使用任务通知值之前,将通知值的某些或全部位清零 */
            pxCurrentTCB->ulNotifiedValue &= ~ulBitsToClearOnEntry;
            /* 设置任务状态标识:等待通知 */
            pxCurrentTCB->ucNotifyState = taskWAITING_NOTIFICATION;
            if( xTicksToWait > ( TickType_t ) 0 )
            {
                /* 阻塞当前任务 */
                prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
                traceTASK_NOTIFY_WAIT_BLOCK();
                /* 触发PendSV中断,等到退出临界区后,执行任务切换 */
                portYIELD_WITHIN_API();
            }
        }
    }
    taskEXIT_CRITICAL();
    /* 到这里说明其它任务或中断向这个任务发送了通知,或者任务阻塞超时,现在继续处理*/
    taskENTER_CRITICAL();
    {
        traceTASK_NOTIFY_WAIT();
        if( pulNotificationValue != NULL )
        {
            /* 输出当前通知值,通过指针参数传递*/
            *pulNotificationValue = pxCurrentTCB->ulNotifiedValue;
        }
         /* 判断是否是因为任务阻塞超时 */
        if( pxCurrentTCB->ucNotifyState == taskWAITING_NOTIFICATION )
        {
            /* 没有收到任务通知,是阻塞超时 */
            xReturn = pdFALSE;
        }
        else
        {
            /* 收到任务值,先将参数ulBitsToClearOnExit取反后与通知值位与,用于在退出函数前,将通知值的某些或者全部位清零. */
            pxCurrentTCB->ulNotifiedValue &= ~ulBitsToClearOnExit;
            xReturn = pdTRUE;
        }
        /* 更改任务通知状态,解除任务通知等待 */
        pxCurrentTCB->ucNotifyState = taskNOT_WAITING_NOTIFICATION;
    }
    taskEXIT_CRITICAL();
    return xReturn;
}

纵观整个任务通知的实现,可以发现它比队列、信号量相比要简单很多。它可以实现轻量级的队列、二进制信号量、计数信号量和事件组,并且使用更方便、更节省RAM、更高效。FreeRTOS的作者做过测试,在同一平台下,使用使用GCC编译器、-o2优化级别,相比使用信号量解除任务阻塞,使用任务通知可以快45%!这个性能的提升是巨大的。

我们分析过信号量的源码,今天又分析了任务通知的源码,这使得我们知道,之所以有这么大的性能提升,一方面缘于任务通知数据结构简单、实现简洁;

另一方面也跟FreeRTOS的信号量机制臃肿、效率低下有关。因为信号量的实现全部是使用队列机制,并没有为信号量做专门优化。

此外,着重说明一下任务通知并不能完全代替队列、二进制信号量、计数信号量和事件组,任务通知有自己的局限性,我们就以它的局限性来结束本文:

只能有一个任务接收通知事件。

接收通知的任务可以因为等待通知而进入阻塞状态,但是发送通知的任务即便不能立即完成发送通知,也不能进入阻塞状态。

以上就是FreeRTOS进阶任务通知示例分析的详细内容,更多关于FreeRTOS任务通知分析的资料请关注我们其它相关文章!

(0)

相关推荐

  • FreeRTOS进阶内存管理示例完全解析

    内存管理对应用程序和操作系统来说都非常重要.现在很多的程序漏洞和运行崩溃都和内存分配使用错误有关. FreeRTOS操作系统将内核与内存管理分开实现,操作系统内核仅规定了必要的内存管理函数原型,而不关心这些内存管理函数是如何实现的.这样做大有好处,可以增加系统的灵活性:不同的应用场合可以使用不同的内存分配实现,选择对自己更有利的内存管理策略.比如对于安全型的嵌入式系统,通常不允许动态内存分配,那么可以采用非常简单的内存管理策略,一经申请的内存,甚至不允许被释放.在满足设计要求的前提下,系统越简单

  • FreeRTOS进阶之任务创建完全解析

    目录 在FreeRTOS基础系列<FreeRTOS系列第10篇---FreeRTOS任务创建和删除>中介绍了任务创建API函数xTaskCreate(),我们这里先回顾一下这个函数的声明: BaseType_t xTaskCreate( TaskFunction_tp vTaskCode, const char * constpcName, unsigned short usStackDepth, void *pvParameters, UBaseType_t uxPriority, Task

  • FreeRTOS进阶系统节拍时钟示例的完全解析

    目录 操作系统的运行是由系统节拍时钟驱动的. 在FreeRTOS中,我们知道系统延时和阻塞时间都是以系统节拍时钟周期为单位.在配置文件FreeRTOSConfig.h,改变宏configTICK_RATE_HZ的值,可以改变系统节拍时钟的中断频率,也间接的改变了系统节拍时钟周期(T=1/f).比如设置宏configTICK_RATE_HZ为100,则系统节拍时钟周期为10ms,设置宏configTICK_RATE_HZ为1000,则系统节拍时钟周期为1ms. 系统节拍中断服务程序会调用函数xTa

  • FreeRTOS进阶之队列示例分析

    目录 FreeRTOS提供了多种任务间通讯方式,包括:任务通知(版本V8.2以及以上版本)队列二进制信号量计数信号量互斥量递归互斥量      其中,二进制信号量.计数信号量.互斥量和递归互斥量都是使用队列来实现的,因此掌握队列的运行机制,是很有必要的.      队列是FreeRTOS主要的任务间通讯方式.可以在任务与任务间.中断和任务间传送信息.发送到队列的消息是通过拷贝实现的,这意味着队列存储的数据是原数据,而不是原数据的引用.先看一下队列的数据结构: typedef struct Que

  • FreeRTOS进阶之调度器启动过程分析

    目录 使用FreeRTOS,一个最基本的程序架构如下所示: int main(void) { 必要的初始化工作; 创建任务1; 创建任务2; ... vTaskStartScheduler(); /*启动调度器*/ while(1); } 任务创建完成后,静态变量指针pxCurrentTCB(见<FreeRTOS进阶之任务创建完全解析>第7节内容)指向优先级最高的就绪任务.但此时任务并不能运行,因为接下来还有关键的一步:启动FreeRTOS调度器. 调度器是FreeRTOS操作系统的核心,主要

  • FreeRTOS进阶列表和列表项示例分析

    目录 前言 1.初始化列表 2.初始化列表项 4.将列表项插入到列表末端 前言 FreeRTOS内核调度大量使用了列表(list)和列表项(list item)数据结构.我们如果想一探FreeRTOS背后的运行机制,首先遇到的拦路虎就是列表和列表项.对于FreeRTOS内核来说,列表就是它最基础的部分.我们在这一章集中讲解列表和列表项的结构以及操作函数,在下一章讲解任务创建时,会用到本章的知识点. 列表被FreeRTOS调度器使用,用于跟踪任务,处于就绪.挂起.延时的任务,都会被挂接到各自的列表

  • FreeRTOS进阶信号量示例的完全解析

    目录 FreeRTOS的信号量包括二进制信号量.计数信号量.互斥信号量(以后简称互斥量)和递归互斥信号量(以后简称递归互斥量).关于它们的区别可以参考< FreeRTOS系列第19篇---FreeRTOS信号量>一文. 信号量API函数实际上都是宏,它使用现有的队列机制.这些宏定义在semphr.h文件中.如果使用信号量或者互斥量,需要包含semphr.h头文件. 二进制信号量.计数信号量和互斥量信号量的创建API函数是独立的,但是获取和释放API函数都是相同的:递归互斥信号量的创建.获取和释

  • FreeRTOS进阶之任务切换完全分析

    目录 FreeRTOS任务切换过程 代码分析 运行FreeRTOS过程 FreeRTOS任务切换过程 FreeRTOS任务相关的代码大约占总代码的一半左右,这些代码都在为一件事情而努力,即找到优先级最高的就绪任务,并使之获得CPU运行权.任务切换是这一过程的直接实施者,为了更快的找到优先级最高的就绪任务,任务切换的代码通常都是精心设计的,甚至会用到汇编指令或者与硬件相关的特性,比如Cortex-M3的CLZ指令.因此任务切换的大部分代码是由硬件移植层提供的,不同的平台,实现发方法也可能不同,这篇

  • FreeRTOS进阶之任务通知示例完全解析

    目录 前言 1.发送通知 1.1 xTaskGenericNotify() 1.2 vTaskNotifyGiveFromISR() 1.3 xTaskGenericNotifyFromISR() 2.等待通知 2.1 ulTaskNotifyTake() 2.2 xTaskNotifyWait() 前言 在FreeRTOS版本V8.2.0中推出了全新的功能:任务通知.在大多数情况下,任务通知可以替代二进制信号量.计数信号量.事件组,可以替代长度为1的队列(可以保存一个32位整数或指针值),并且

  • FreeRTOS进阶之空闲任务示例完全解析

    目录 当RTOS调度器开始工作后,为了保证至少有一个任务在运行,空闲任务被自动创建,占用最低优先级(0优先级). xReturn = xTaskCreate( prvIdleTask, "IDLE",configMINIMAL_STACK_SIZE, (void * ) NULL, (tskIDLE_PRIORITY | portPRIVILEGE_BIT ), &xIdleTaskHandle); 空闲任务是FreeRTOS不可缺少的任务,因为FreeRTOS设计要求必须至少

  • FreeRTOS进阶任务通知示例分析

    目录 在FreeRTOS版本V8.2.0中推出了全新的功能:任务通知.在大多数情况下,任务通知可以替代二进制信号量.计数信号量.事件组,可以替代长度为1的队列(可以保存一个32位整数或指针值),并且任务通知速度更快.使用的RAM更少!我在< FreeRTOS系列第14篇---FreeRTOS任务通知>一文中介绍了任务通知如何使用以及局限性,今天我们将分析任务通知的实现源码,看一下任务通知是如何做到效率与RAM消耗双赢的.        在<FreeRTOS高级篇6---FreeRTOS信

  • FreeRTOS进阶之队列示例完全解析

    目录 前言 1.队列创建函数 2.入队 2.1 xQueueGenericSend() 2.2 xQueueGenericSendFromISR () 3.出队 前言 FreeRTOS提供了多种任务间通讯方式,包括: 任务通知(版本V8.2以及以上版本) 队列 二进制信号量 计数信号量 互斥量 递归互斥量 其中,二进制信号量.计数信号量.互斥量和递归互斥量都是使用队列来实现的,因此掌握队列的运行机制,是很有必要的. 队列是FreeRTOS主要的任务间通讯方式.可以在任务与任务间.中断和任务间传送

  • FreeRTOS实时操作系统的内核控制示例解析

    目录 前言 1.强制上下文切换宏 2.进入临界区宏 3.退出临界区宏 4.禁止可屏蔽中断宏 5.使能可屏蔽中断宏 6.启动调度器 6.1函数描述 7.停止调度器 7.1函数描述 8.挂起调度器 8.1函数描述 9.恢复被挂起的调度器 9.1函数描述 9.2返回值 9.3用法举例 10.调整系统节拍 10.1函数描述 10.2参数描述 10.3用法举例 前言 内核控制的一些功能需要移植层提供,为了方便移植,这些API函数用宏来实现,比如上下文切换.进入和退出临界区.禁止和使能可屏蔽中断.内核控制函

随机推荐