FreeRTOS高级篇10---系统节拍时钟分析
操作系统的运行是由系统节拍时钟驱动的。 在FreeRTOS中,我们知道系统延时和阻塞时间都是以系统节拍时钟周期为单位。在配置文件FreeRTOSConfig.h,改变宏configTICK_RATE_HZ的值,可以改变系统节拍时钟的中断频率,也间接的改变了系统节拍时钟周期(T=1/f)。比如设置宏configTICK_RATE_HZ为100,则系统节拍时钟周期为1......
操作系统的运行是由系统节拍时钟驱动的。
在FreeRTOS中,我们知道系统延时和阻塞时间都是以系统节拍时钟周期为单位。在配置文件FreeRTOSConfig.h,改变宏configTICK_RATE_HZ的值,可以改变系统节拍时钟的中断频率,也间接的改变了系统节拍时钟周期(T=1/f)。比如设置宏configTICK_RATE_HZ为100,则系统节拍时钟周期为10ms,设置宏configTICK_RATE_HZ为1000,则系统节拍时钟周期为1ms。
系统节拍中断服务程序会调用函数xTaskIncrementTick()来完成主要工作,如果该函数返回值为真(不等于pdFALSE),说明处于就绪态任务的优先级比当前运行的任务优先级高。这会触发一次PendSV中断,进行上下文切换。我们重点看一下函数xTaskIncrementTick()做了哪些事情,以及什么情况下返回真值。
1.调度器正常情况
调度器正常(没有挂起),即变量uxSchedulerSuspended的值为pdFALSE。变量uxSchedulerSuspended是定义在tasks.c文件中的静态变量,记录调度器运行状态。当调用API函数vTaskSuspendAll()挂起调度器时,会将变量uxSchedulerSuspended增1。所以变量uxSchedulerSuspended为真时,表示调度器被挂起。
调度器正常情况下,首先将变量xTickCount增1。变量xTickCount也是在tasks.c文件中定义的静态变量,它在启动调度器时被清零,在每次系统节拍时钟发生中断后加1,用来记录系统节拍时钟中断的次数。内核会将所有阻塞的任务跟这个变量比较,以判断是否超时(超时意味着可以解除阻塞)。
变量xTickCount的数据类型跟具体硬件有关,32位架构硬件一般是无符号32位变量、8位或16位架构一般是无符号16位变量。即便是32位变量,xTickCount累加到0xFFFFFFFF后也会溢出。因此,在程序中要判断变量xTickCount是否溢出。如果溢出(xTickCount为0),则调用宏taskSWITCH_DELAYED_LISTS()交换延时列表指针和溢出延时列表指针。这个牵扯的有点广,我们慢慢说明。
为了解决xTickCount溢出问题,FreeRTOS使用了两个延时列表:xDelayedTaskList1和xDelayedTaskList2。并使用延时列表指针pxDelayedTaskList和溢出延时列表指针pxOverflowDelayedTaskList分别指向上面的延时列表1和延时列表2(在创建任务时将延时列表指针指向延时列表)。顺便说一下,上面的两个延时列表指针变量和两个延时列表变量都是在tasks.c中定义的静态局部变量。
比如我们使用API延时函数vTaskDelay( xTicksToDelay ) 将任务延时xTicksToDelay个系统节拍周期,延时函数会以当前的系统节拍中断次数xTickCount为参考,这个值加上参数规定的延时时间xTicksToDelay,即xTickCount+ xTicksToDelay,就是下次唤醒任务的时间。xTickCount+xTicksToDelay会被记录到任务TCB中,随着任务一起挂接到延时列表。如果内核判断出xTickCount+ xTicksToDelay溢出(大于32位可以表示的最大值),就将当前任务挂接到列表指针pxOverflowDelayedTaskList指向的列表中,否则就挂接到列表指针pxDelayedTaskList指向的列表中。任务按照延时时间,顺序的插入到延时列表中。
所以当系统节拍中断次数计数器xTickCount溢出时,必须将延时列表指针pxDelayedTaskList和溢出延时列表指针pxOverflowDelayedTaskList交换以便正确处理延时的任务。宏taskSWITCH_DELAYED_LISTS()的代码如下所示:
#definetaskSWITCH_DELAYED_LISTS() \
{ \
List_t *pxTemp \
\
/* The delayed tasks list should beempty when the lists are switched. */ \
configASSERT( ( listLIST_IS_EMPTY( pxDelayedTaskList) ) ); \
\
pxTemp = pxDelayedTaskList; \
pxDelayedTaskList = pxOverflowDelayedTaskList; \
pxOverflowDelayedTaskList = pxTemp; \
xNumOfOverflows++; \
prvResetNextTaskUnblockTime \
}
这段代码完成两部分工作,第一是将延时列表指针pxDelayedTaskList和溢出延时列表指针pxOverflowDelayedTaskList交换;第二是调用函数prvResetNextTaskUnblockTime()重新获取下一次解除阻塞的时间,这个时间保存在静态变量xNextTaskUnblockTime中,该变量也是定义在tasks.c中。下面检查延时列表任务是否到期时,会用到这个变量。
接下来函数会检查延时列表,查看延时的任务是否到期。前面我们说过,延时的任务根据延时时间先后,顺序的插入到延时列表中,延时时间短的在前,延时时间长的在后,并且下一个要被唤醒任务的时间数值保存在变量xNextTaskUnblockTime中。所以使用xTickCount与xNextTaskUnblockTime比较就可以知道是否有任务可以被唤醒。
if( xConstTickCount >=xNextTaskUnblockTime )
{
/* 延时的任务到期,需要被唤醒 */
}
如果任务被唤醒,则将任务从延时列表中删除,重新加入就绪列表。如果新加入就绪列表的任务优先级大于当前任务优先级,则会触发一次上下文切换。
FreeRTOS支持多个任务共享同一个优先级,如果设置为抢占式调度(宏configUSE_PREEMPTION设置为1)并且宏configUSE_TIME_SLICING也为1(或未定义),则相同优先级的多个任务间进行任务切换。
最后还会调用时间片钩子函数vApplicationTickHook()。可以看到时间片钩子函数实在中断服务函数中调用的,所以这个钩子函数必须简洁、不可以调用不带中断保护的API函数。
2.调度器挂起情况
如果调度器挂起,正在执行的任务会一直继续执行,内核不再调度(意味着当前任务不会被切换出去),直到该任务调用了xTaskResumeAll()函数。
在调度器挂起阶段内,FreeRTOS使用静态变量uxPendedTicks记录挂起期间,系统节拍中断的次数。当调用恢复调度器函数xTaskResumeAll()时,会执行uxPendedTicks次本函数(xTaskIncrementTick())。变量uxPendedTicks同样是在tasks.c中定义的。
3.自动任务切换
函数的最后几行代码颇让人难以理解,其中局部变量xSwitchRequired是本函数的返回值,在文章开始也说过:“如果该函数返回值为真,说明处于就绪态任务的优先级高于当前运行任务的优先级,则会触发一次PendSV中断,进行上下文切换”,现在如果变量xYieldPending为真,则返回值也会为真,函数结束后会进行上下文切换。这个变量xYieldPending的作用是什么?又是在什么时候被赋值为真呢?还真要从头说起。
if( xYieldPending != pdFALSE )
{
xSwitchRequired = pdTRUE;
}
带中断保护的API函数,都会有一个参数pxHigherPriorityTaskWoken。如果API函数导致一个任务解锁,并且解锁的任务优先级高于当前运行的任务,则API函数将*pxHigherPriorityTaskWoken设置成pdTRUE。在中断退出前,老版本的FreeRTOS需要手动触发一次任务切换。比如在《 FreeRTOS系列第15篇---使用任务通知实现命令行解释器》一文中,我们在串口接收中断中调用了带中断保护的API函数vTaskNotifyGiveFromISR(),在函数执行完后,会使用代码portYIELD_FROM_ISR(xHigherPriorityTaskWoken)判断参数xHigherPriorityTaskWoken是否为真,为真则手动强制上下文切换。
BaseType_txHigherPriorityTaskWoken = pdFALSE;
/*收到一帧数据,向命令行解释器任务发送通知*/
vTaskNotifyGiveFromISR(xCmdAnalyzeHandle,&xHigherPriorityTaskWoken);
/*是否需要强制上下文切换*/
portYIELD_FROM_ISR(xHigherPriorityTaskWoken );
从FreeRTOSV7.3.0起,pxHigherPriorityTaskWoken成为一个可选参数,并可以设置为NULL。如果将参数xHigherPriorityTaskWoken设置为NULL,并且带中断保护的API函数导致更高优先级任务解锁,任务什么时候、怎么切换呢?
原来从FreeRTOSV7.3.0起,内核增加了一个静态变量xYieldPending,这个变量也是在tasks.c中定义的。如果将变量xYieldPending设置为pdTRUE,则会在下一次系统节拍中断服务函数中,触发一次任务切换,见本小节第一段代码描述。
让我们看一下这个过程是如何实现的。
对于队列以及使用队列机制的信号量、互斥量等,在中断服务程序中调用了这些API函数,将任务从阻塞中解除,则需要调用函数xTaskRemoveFromEventList()将任务的事件列表项从事件列表中移除。在移除事件列表项的过程中,会判断解除的任务优先级是否大于当前任务的优先级,如果解除的任务优先级更高,会将变量xYieldPending设置为pdTRUE。在下一次系统节拍中断服务函数中,触发一次任务切换。代码如下所示:
if(pxUnblockedTCB->uxPriority > pxCurrentTCB->uxPriority)
{
/*任务具有更高的优先级,返回pdTRUE。告诉调用这个函数的任务,它需要强制切换上下文。*/
xReturn= pdTRUE;
/*带中断保护的API函数的都会有一个参数参数"xHigherPriorityTaskWoken",如果用户没有使用这个参数,这里设置任务切换标志。在下个系统中断服务例程中,会检查xYieldPending的值,如果为pdTRUE则会触发一次上下文切换。*/
xYieldPending= pdTRUE;
}
对于FreeRTOSV8.2.0新推出的任务通知,也提供了带中断保护版本的API函数。按照逻辑推断,这些API函数的参数xHigherPriorityTaskWoken也可以不使用,变量xYieldPending也应该作用于这些API函数。但事实是,在FreeRTOSV9.0之前的版本,FreeRTOS都没有实现这个功能,如果使用这些API函数解除了一个更高优先级任务,必须手动的进行上下文切换。这可能是一个BUG,因为在FreeRTOS V9.0版本中,已经修复了这个问题,可以使用变量xYieldPending自动切换上下文。这个BUG由QQ昵称为“所长”的网友遇到。
在V9.0以及以上版本中,如果在中断中释放的通知引起更高优先级的任务解锁,API函数会判断参数xHigherPriorityTaskWoken是否有效,有效则将*xHigherPriorityTaskWoken设置为pdTRUE,此时需要手动切换上下文;否则,将变量xYieldPending设置为pdTRUE,在下一次系统节拍中断服务函数中,触发一次任务切换。代码如下所示:
if( pxTCB->uxPriority >pxCurrentTCB->uxPriority )
{
/*如果解除阻塞的任务优先级大于当前任务优先级,则设置上下文切换标识,等退出函数后手动切换上下文,或者在系统节拍中断服务程序中自动切换上下文*/
if(pxHigherPriorityTaskWoken != NULL )
{
*pxHigherPriorityTaskWoken= pdTRUE; /* 设置手动切换标志*/
}
else
{
xYieldPending= pdTRUE; /* 设置自动切换标志*/
}
}
函数xTaskIncrementTick()完整代码如下所示,根据上面的讲解以及代码的注释,理解这些代码应该不是难事。
BaseType_t xTaskIncrementTick( void )
{
TCB_t * pxTCB;
TickType_t xItemValue;
BaseType_t xSwitchRequired = pdFALSE;
/* 每当系统节拍定时器中断发生,移植层都会调用该函数.函数将系统节拍中断计数器加1,
然后检查新的系统节拍中断计数器值是否解除某个任务.*/
if(uxSchedulerSuspended == ( UBaseType_t ) pdFALSE )
{ /* 调度器正常情况 */
const TickType_txConstTickCount = xTickCount + 1;
/* 系统节拍中断计数器加1,如果计数器溢出(为0),交换延时列表指针和溢出延时列表指针 */
xTickCount = xConstTickCount;
if( xConstTickCount == ( TickType_t ) 0U )
{
taskSWITCH_DELAYED_LISTS();
}
/* 查看是否有延时任务到期.任务按照唤醒时间的先后顺序存储在队列中,这意味着只要队列中的最先唤醒任务没有到期,其它任务一定没有到期.*/
if( xConstTickCount >=xNextTaskUnblockTime )
{
for( ;; )
{
if( listLIST_IS_EMPTY( pxDelayedTaskList) != pdFALSE )
{
/* 如果延时列表为空,设置xNextTaskUnblockTime为最大值 */
xNextTaskUnblockTime = portMAX_DELAY;
break;
}
else
{
/* 如果延时列表不为空,获取延时列表第一个列表项值,这个列表项值存储任务唤醒时间.
唤醒时间到期,延时列表中的第一个列表项所属的任务要被移除阻塞状态 */
pxTCB = ( TCB_t * )listGET_OWNER_OF_HEAD_ENTRY( pxDelayedTaskList );
xItemValue =listGET_LIST_ITEM_VALUE( &( pxTCB->xStateListItem ) );
if( xConstTickCount < xItemValue )
{
/* 任务还未到解除阻塞时间?将当前任务唤醒时间设置为下次解除阻塞时间. */
xNextTaskUnblockTime = xItemValue;
break;
}
/* 从阻塞列表中删除到期任务 */
( void ) uxListRemove( &( pxTCB->xStateListItem ) );
/* 是因为等待事件而阻塞?是的话将到期任务从事件列表中删除 */
if(listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) != NULL )
{
( void ) uxListRemove( &( pxTCB->xEventListItem ) );
}
/* 将解除阻塞的任务放入就绪列表 */
prvAddTaskToReadyList( pxTCB );
#if ( configUSE_PREEMPTION == 1 )
{
/* 使能了抢占式内核.如果解除阻塞的任务优先级大于当前任务,触发一次上下文切换标志 */
if( pxTCB->uxPriority >= pxCurrentTCB->uxPriority )
{
xSwitchRequired= pdTRUE;
}
}
#endif /*configUSE_PREEMPTION */
}
}
}
/* 如果有其它任务与当前任务共享一个优先级,则这些任务共享处理器(时间片) */
#if ( (configUSE_PREEMPTION == 1 ) && ( configUSE_TIME_SLICING == 1 ) )
{
if(listCURRENT_LIST_LENGTH( &( pxReadyTasksLists[ pxCurrentTCB->uxPriority ] ) ) > ( UBaseType_t ) 1 )
{
xSwitchRequired = pdTRUE;
}
else
{
mtCOVERAGE_TEST_MARKER();
}
}
#endif /* ( (configUSE_PREEMPTION == 1 ) && ( configUSE_TIME_SLICING == 1 ) ) */
#if (configUSE_TICK_HOOK == 1 )
{
/* 调用时间片钩子函数*/
if( uxPendedTicks == ( UBaseType_t ) 0U )
{
vApplicationTickHook();
}
}
#endif /*configUSE_TICK_HOOK */
}
else
{ /* 调度器挂起状态,变量uxPendedTicks用于统计调度器挂起期间,系统节拍中断次数.
当调用恢复调度器函数时,会执行uxPendedTicks次本函数(xTaskIncrementTick()):
恢复系统节拍中断计数器,如果有任务阻塞到期,则删除阻塞状态 */
++uxPendedTicks;
/* 调用时间片钩子函数*/
#if (configUSE_TICK_HOOK == 1 )
{
vApplicationTickHook();
}
#endif
}
#if (configUSE_PREEMPTION == 1 )
{ /* 如果在中断中调用的API函数唤醒了更高优先级的任务,并且API函数的参数pxHigherPriorityTaskWoken为NULL时,变量xYieldPending用于上下文切换标志 */
if( xYieldPending!= pdFALSE )
{
xSwitchRequired = pdTRUE;
}
}
#endif /*configUSE_PREEMPTION */
return xSwitchRequired;
}
读后有收获,资助博主养娃 - 千金难买知识,但可以买好多奶粉 (〃'▽'〃)
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)