1270_FreeRTOS的TickHandler实现分析

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)

前面把FreeRTOS初始化涉及到的代码都分析了一遍，这一次再看一下这个Tickhandler的实现。能够跟一个移植相关的点其实不是很多，这个就是其中的一部分，因此应该重点关注一下。

我修改过的工程中，TickHandler的实现方式已经变成了上面这部分。

这部分只是一个CubeIDE的封装，还是很容易读懂的。接下来，看看这个调度器状态获取的接口实现。

从预处理的信息看，2个条件满足的时候都该提供这个状态获取的接口。一个是明确要求配置使用状态获取功能的时候，另一个是使用了计时器的时候。看起来，OS的软件定时器功能还是依赖于调度器状态判断的。

整个调度器的状态判断很简单，就是状态信息的组合。一个是没运行的状态，而运行状态有运行和挂起两种状态。

看一下调度器运行这个变量信息，这是一个私有量，只有这一个文件中再用。只有2个地方涉及到了赋值，其他的都是判断。其实，如果提供了状态判断接口直接用接口判断状态可读性更好，但是可能会有低一些的效率。

赋值为True的地方在于调度器的启动接口。

赋值为false的时候是调度器停止的时候。

而调度器的挂起状态的处理，在于挂起接口自己恢复调度接口中。这个不是一个二值信息，而是一个有嵌套性质的计数器。

之后需要分析的就是这个FreeRTOS提供的TickHandler接口了。

这个接口的命名在FreeRTOS的配置中其实是进行了一个名字的修改的。

上面是这个接口的具体实现，从实现看来，就是进行了一个中断保护然后增加tick。如果增加tick成功之后，请求一个PendSV的操作。

Tick的增加也不仅仅是一个数字的增加，里面对OS的一些链表等做了处理。上面这部分，增加了系统的tick数值之后判断tick计数器的溢出并在溢出的时候切换了延迟链表。

切换延迟的链表，实现的额功能是把指向延迟任务链表的指针与指向溢出延迟任务链表的指针做了一个交换。之后，溢出计数器增加1，然后复位任务解锁时间。

从代码信息看，这个接口实现的功能是：如果延迟任务链表存在，那么从中提取出他的时间技术参数赋值给一个变量xNextTaskUnblockTime。而这个变量与tick计数器的数值关系会决定任务的调度。

这样，继续回到tickhandler的分析。上面这部分，处理了delay 任务链表。选出在时间上符合条件的任务，加入到任务就绪链表。

如果调度支持抢占，那么查看是否有更高优先级的任务就绪。有的话，请求任务切换标志使能。如此可以推测知道，后面应该还有根据这个状态判断是否进行任务调度切换的操作。而整个delay任务链表的处理只需要找到一个任务进行响应的处理即退出全部任务链表的处理。如果一直没有找到，会在这里等待有相应的任务调度需求出现。

优先级抢占以及切片的处理。

如果调度器挂起，tick handler中需要记录信息用以后续追加执行判断。

如果，tick handler中发现有请求切换产生（可能来自其他的接口），那么任务切换请求置位。最后，这个请求的信息作为返回值提供出来用以指示调度。

再回到TickHandler的最上层调度点，这样就很容易理解调度的发生了。这个调度还是通过PendSV的方式在tick handler的最后生效。这样，能够看清楚OS调度实现的一个关键点其实还是在于使用PendSV请求来实现上下文切换。后面关于这部分内容还得继续做一下分析理解。