嵌入式操作系统之时钟节拍下的任务切换

  嵌入式操作系统如FreeRTOS。FreeRTOS 中任务切换的过程， 提到触发任务切换的两种情况 ： 高优先级任务就绪抢占和同优先级任务时间共享（包括提前挂起）。 系统中，时间延时和任务阻塞，时间片都以 Systick 为单位。通过设置文件 FreeRTOSConfig.h 中 configTICK_RATE_HZ 设置任务节拍中断频率， 在启动任务调度器时，系统会根据另一个变量， CPU 的频率configCPU_CLOCK_HZ 计算对应写入节拍计数器的值，启动定时器中断。 系统在每一次节拍计数器中断服务程序xPortSysTickHandler(平台实现 port.c 中) 中调用处理函数 xTaskIncrementTick, 依据该函数返回值判断是否需要触发 PendSV 异常， 进行任务切换。 
涉及任务时间片轮循， 任务阻塞超时， 以及结束以此实现的延时函数。 分析的源码版本是 v9.0.0

xTaskIncrementTick()

系统每次节拍中断服务程序中主要任务由函数 xTaskIncrementTick 完成。 
在任务调度器没有挂起的情况下（ xTaskIncrementTick ！= pdFALSE ），该函数主要完成 ： 
* 判断节拍计数器xTickCount 是否溢出， 溢出轮换延时函数队列 
* 判断是否有阻塞任务超时，取出插入就绪链表 
* 同优先级任务时间片轮 而当任务调度器被挂起时， 该函数累加挂起时间计数器 uxPendedTicks， 调用用户钩子函数， 此时，正在运行的任务不会被切换， 一直运行。 
当恢复调度时， 系统会先重复调用 xTaskIncrementTick 补偿 （uxPendedTicks次）。 不管, 系统调度器是否挂起， 每次节拍中断都会调用用户的钩子函数 vApplicationTickHook。 由于函数是中断中调用，不要在里面处理太复杂的事情！！

节拍计数器溢出

涉及的变量, 定义在 task.c开头。  

1. PRIVILEGED_DATA static List_t xDelayedTaskList1;
2. PRIVILEGED_DATA static List_t xDelayedTaskList2;
3. PRIVILEGED_DATA static List_t * volatile pxDelayedTaskList;
4. PRIVILEGED_DATA static List_t * volatile pxOverflowDelayedTaskList;

初始化时， pxDelayedTaskList 指向 xDelayedTaskList1， pxOverflowDelayedTaskList 指向 pxOverflowDelayedTaskList，一开始我还在郁闷延时链表为什么要两个，到这里才明白。 当任务由于等待事件（延时，消息队列什么的堵塞）时，会设置一个时间，这时候，响应的任务会被挂到延时链表中，如果超过设置时间没有事件响应，则系统会从延时链表中取出任务恢复就绪。 
系统任务延时参考系统节拍计数器 xTickCount， 加入链表前依据当前计数器的值计算出超时的值 （ xTickCount+ xTicksToDelay ）， 顺序插入到延时链表中。 对不同平台xTickCount 表示的位数不同，但是每次节拍中断加一，总会溢出。 上述计算任务延时时间，如果系统发现计算出来的时间已经溢出，则会将该任务加入到 pxOverflowDelayedTaskList 这个链表中。 
在系统节拍中断时， 节拍计数器每次加一， 系统判断是否溢出，如果溢出， 调用宏 taskSWITCH_DELAYED_LISTS()切换上述的链表指针。 
宏主要实现如下 ：  

1. pxTemp = pxDelayedTaskList;
2. pxDelayedTaskList = pxOverflowDelayedTaskList;
3. pxOverflowDelayedTaskList = pxTemp;
4. xNumOfOverflows++;
5. prvResetNextTaskUnblockTime();

这就是设置两个链表的原因，轮流倒应对计数器的溢出。

唤醒超时任务

全局变量 xNextTaskUnblockTime 记录下一个需要退出延时链表的任务时间， 因此， 接下来判断当前时间，延时链表中是否有任务需要推出阻塞状态。  

1. if( xConstTickCount >= xNextTaskUnblockTime )
2. {
3. for ( ;; ) {
4. // 取出唤醒任务， 推进就绪链表
5. }
6. }

对应的， 把所有阻塞时间达到的任务取出， 推入到就绪链表，更新下一个任务解除时间给变量 xNextTaskUnblockTime。

任务时间片轮循

处理完延时任务后， 开始判断当前运行任务， 对应优先级链表中是否有其他任务就绪， 如果有，需要保证每个任务都能获得运行时间， 标记需要任务切换， 作为函数返回。

完整函数

完整函数注释如下，  

1. BaseType_t xTaskIncrementTick( void )
2. {
3. TCB_t * pxTCB;
4. TickType_t xItemValue;
5. BaseType_t xSwitchRequired = pdFALSE;
6.  
7. traceTASK_INCREMENT_TICK( xTickCount );
8. // 调度器正在运行
9. if( uxSchedulerSuspended == ( UBaseType_t ) pdFALSE )
10. {
11. // 节拍计数器递增 1
12. const TickType_t xConstTickCount = xTickCount + 1;
13. xTickCount = xConstTickCount;
14.  
15. if( xConstTickCount == ( TickType_t ) 0U )
16. {
17. // 节拍计数器溢出
18. // 比如32位 0xFFFFFFFF + 1 -> 0
19. // 延时链表切换
20. taskSWITCH_DELAYED_LISTS();
21. }
22. else
23. {
24. mtCOVERAGE_TEST_MARKER();
25. }
26.  
27. if( xConstTickCount >= xNextTaskUnblockTime )
28. {
29. for( ;; )
30. {
31. if( listLIST_IS_EMPTY( pxDelayedTaskList ) != pdFALSE )
32. {
33. // 没有任务延时， 时间设置"无穷大" 退出循环
34. xNextTaskUnblockTime = portMAX_DELAY;
35. break;
36. }
37. else
38. {
39. // 取出延时链表头任务 TCB
40. pxTCB = (TCB_t *)listGET_OWNER_OF_HEAD_ENTRY( pxDelayedTaskList );
41. // 取该任务延时值
42. xItemValue = listGET_LIST_ITEM_VALUE(&(pxTCB->xStateListItem));
43. // 判断任务是否超时
44. if( xConstTickCount < xItemValue )
45. {
46. // 任务还没到时间，更新全局变量
47. // 直接退出
48. xNextTaskUnblockTime = xItemValue;
49. break;
50. }
51. else
52. {
53. mtCOVERAGE_TEST_MARKER();
54. }
55. // 任务恢复就绪， 从堵塞的链表中删除
56. ( void ) uxListRemove( &( pxTCB->xStateListItem ) );
57.  
58. if( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) != NULL )
59. {
60. ( void ) uxListRemove( &( pxTCB->xEventListItem ) );
61. }
62. else
63. {
64. mtCOVERAGE_TEST_MARKER();
65. }
66. // 插入就绪链表等待被执行
67. prvAddTaskToReadyList( pxTCB );
68. // 如果系统允许抢占
69. #if ( configUSE_PREEMPTION == 1 )
70. {
71. // 如果新就绪任务优先级高于当前任务
72. // 标记需要切换任务
73. if( pxTCB->uxPriority >= pxCurrentTCB->uxPriority )
74. {
75. xSwitchRequired = pdTRUE;
76. }
77. else
78. {
79. mtCOVERAGE_TEST_MARKER();
80. }
81. }
82. #endif /* configUSE_PREEMPTION */
83. }
84. }
85. }
86.  
87. // 同优先级任务 时间轮
88. #if ( ( configUSE_PREEMPTION == 1 ) && ( configUSE_TIME_SLICING == 1 ) )
89. {
90. if( listCURRENT_LIST_LENGTH( &( pxReadyTasksLists[ pxCurrentTCB->uxPriority ] ) ) > ( UBaseType_t ) 1 )
91. {
92. xSwitchRequired = pdTRUE;
93. }
94. else
95. {
96. mtCOVERAGE_TEST_MARKER();
97. }
98. }
99. #endif /* ( ( configUSE_PREEMPTION == 1 ) && ( configUSE_TIME_SLICING == 1 ) ) */
100.  
101. // 用户钩子函数
102. #if ( configUSE_TICK_HOOK == 1 )
103. {
104. if( uxPendedTicks == ( UBaseType_t ) 0U )
105. {
106. vApplicationTickHook();
107. }
108. else
109. {
110. mtCOVERAGE_TEST_MARKER();
111. }
112. }
113. #endif /* configUSE_TICK_HOOK */
114. }
115. else
116. {
117. // 记录调度器被挂起器件节拍中断次数
118. // 恢复后用于补偿， 执行本函数 uxPendedTicks 次先
119. ++uxPendedTicks;
120. #if ( configUSE_TICK_HOOK == 1 )
121. {
122. vApplicationTickHook();
123. }
124. #endif
125. }
126.  
127. // 函数返回值， 如果为 pdTRUE，
128. // 则调用的系统节拍中断会触发 PendSV 异常， 任务切换
129. #if ( configUSE_PREEMPTION == 1 ) // 允许抢占
130. {
131. // 其他地方标记需要执行一次任务切换
132. // 所以不管前面需不需要 这里都会返回需要切换
133. if( xYieldPending != pdFALSE )
134. {
135. xSwitchRequired = pdTRUE;
136. }
137. else
138. {
139. mtCOVERAGE_TEST_MARKER();
140. }
141. }
142. #endif /* configUSE_PREEMPTION */
143.  
144. return xSwitchRequired;
145. }

系统延时函数

任务执行过程中需要使用到延时函数进行延时， 使用系统提供的延时函数可以将当前任务挂起，让出CPU 使用时间，当时间到达的时候， 有系统恢复任务运行。 FreeRTOS 提供两种类型的延时函数

普通延时函数 vTaskDelay

一般情况下，需要延时一定时间，就调用此函数，将需要的延时时间转换为对应系统节拍数传递（如宏pdMS_TO_TICKS（））， 之后，当前任务会从就绪链表移除， 加入到延时链表中，系统会在节拍中断中检查是否到达延时时间， 重新恢复任务就绪。 void vTaskDelay( const TickType_t xTicksToDelay ); 该函数调用到另一个函数是 prvAddCurrentTaskToDelayedList， 将任务加入到延时链表中， 函数中会判断设定时间是否溢出， 选择加入到对应的延时链表， 同上提到计数器溢出的问题。

循环延时函数 vTaskDelayUntil

相比上面的普通延时函数， 这个函数适用于任务周期性执行的。 
举个例子说明下， 有一个任务， 需要周期性 500ms 读取一次传感器数据， 用上例子可以这么写 ：  

1. void vTASKReadSensor(void *pvParameters)
2. {
3. // 500ms 转换为 节拍
4. const portTickType xDelay = pdMS_TO_TICKS(500);
5. for( ;; )
6. {
7. readSensor();
8. vTaskDelay( xDelay );
9. }
10. }

看起来是周期性 500 ms 执行， 但是考虑， 如果任务由于优先级比较低之类的问题， 在延时返回就绪状态后没有及时被运行，那么实际时间就开始飘了。 
如果使用函数 vTaskDelayUntil， void vTaskDelayUntil( TickType_t * const pxPreviousWakeTime, const TickType_t xTimeIncrement ) 多了一个参数 pxPreviousWakeTime， 就不会有这个问题了 
先看以下如何使用 ：  

1. void vTASKReadSensor(void *pvParameters)
2. {
3. const portTickType xDelay = pdMS_TO_TICKS(500);
4. static portTickType xLastWakeTime;
5. // 记录第一次调用函数的时间 ， 后续该变量由延时函数自己叠加
6. xLastWakeTime = xTaskGetTickCount();
7.  
8. for( ;; )
9. {
10. readSensor();
11. vTaskDelayUntil( xDelay );
12. }
13. }

周前性执行前调用一个变量， 获取当前节拍计数器 ，简单认为是第一次调用的时间， 而后开始周期性执行， 传入的变量第一次由我们设置后， 后续会由函数自动更新。 
比如， 我们在SystickCount 为 0 开始延时， 在500 返回读取数据， 再延时， 和上一个例子一样， 当 500 延时后返回， 调度原因延迟， 等到 600 才读取数据并开始下一次延时， 这里， 这个函数不同地方在于， 他会考虑这延迟的 100， 而第二次延时的时间， 其实还是从 500 开始算的， 也就是， 1000 的时候， 任务延时第二次就结束了， 而不是等到 1100 。 由于涉及到任务调度， 所以， 理论上来说， 两个函数定时都是”不住确”的。 时间单位是系统节拍 ！