FreeRTOS系列（1）：基础知识——中断嵌套
FreeRTOS系列文章（2）：PendSV功能，为什么需要PendSV
前言
在上一篇文章中，我们详细分析了PendSV的功能，也分析了SysTick和PendSV结合，实现OS任务调度，简单的分析了SysTick的优先级。我觉得有必要针对SysTick的优先级，单独写一篇文章分析。
结论概述
嵌入式实时OS的【实时】不仅仅是OS对任务调度及时，更重要的是要求嵌入式OS具有【可剥夺/抢占】的特性，既允许高优先级任务抢占低优先级任务，又要允许外部中断能够抢占OS运行，事实上，我个人理解，之所以将SysTick的优先级设置为最低，就是为了最大限度的保证外部IRQ的优先级高于OS。
具体分析
PendSV的优先级设置为最低，我们很容易理解，对于SysTick的优先级设置，目前有两种思路：
- SysTick的优先级一定要最高，因为SysTick关系着OS的心跳节拍的是否精确，关系着OS软件定时器是否准确，所以必须要高优先级，不能被打断。
- SysTick的优先级要设置为最低，具体原因不好说，反正uC/OS、FreeRTOS都是这么设置的，肯定有他们的道理。
我在遇到这个问题的时候，也是有些迷惑的，之前我也倾向于将SysTick优先级设置为最高，毕竟那是操作系统的心跳啊，不准可能不行吧，会不会影响OS的各种功能啊，尤其是软件定时器。
我们先使用上一篇文章的流程图，看一下这两种情况下，操作系统调度的流程：
SysTick的优先级设置为高，调度流程
因为SysTick的优先级高于IRQ的优先级，所以会导致某些情况下IRQ的响应速度变慢，执行时间变长。
SysTick的优先级设置为最低，调度流程
因为SysTick的优先级为最低，并且将任务调度放到了PendSV，可以最大限度的减少SysTick中断服务程序消耗时间，IRQ不会被中断，并且能够最快的时间去响应。
这里可能有人会说，OS的代码中，一般在SysTick中会关中断，这个时候不照样会关闭IRQ吗？ 想到这块的时候，我们就要考虑一下，提到这个问题，其实就是过于追求完美了，没有十全十美的解决方案，使用SysTick + PendSV的目的就是为了最大限度的减少任务调度 对于IRQ的影响。做不到完全不影响，做到最少的影响的方案就是最好的方案.
外部IRQ的优先级
对于CPU来说，嵌入式OS也只是一个稍微复杂的程序而已，只是因为我们把操作系统看的太重要了，总感觉操作系统非常神秘，应该是最高级的，这其实是一个错误的认知，操作系统说白了，就是为了方便程序员写出稳定的程序框架，操作系统并不是CPU的一部分，它只是有一些高级的骚操作而已，在CPU眼里，跟裸机程序是一样的。
所以，既然操作系统也是程序，那么操作系统的优先级肯定不能超过外部中断的优先级，因为外部中断一般是硬件中断，优先级都需要很高。
SysTick的优先级低，影响RTOS时钟精度怎么办？
答案是：不怎么办。
操作系统的心跳节拍本质上讲，就是一个保证操作系统正常运行的节拍而已，就像人的心跳一样，有的人60次/分，有的人70次/分，有的人80次/分，没有唯一答案，你肯定也不会想着要让自己的心跳整齐划一的一直是66次/分。有个大概正常稳定的范围就可以了。嵌入式OS的时钟节拍，压根就不是精准的，也不需要太准，大概准就可以了，因为只要有周期性的节拍，就能保证周期性的调度。软件定时器也不是特别准的，一般用于【短时间】、对时间要求不严苛的场景。如果非要对时间要求的特别准，还是需要用硬件定时器实现的。这里我举一个例子：
笔者之前开发过一个控制器，其中有个简单的逻辑：周期的执行某次动作。对于【周期】的实现方法，我开始是简单的使用 操作系统的 OSDelay(10)ms + cnt 计数的方式来实现，经过测试发现，短周期的精度是可以的，如果是几十秒的周期，误差会很大。后来我就想，我用操作系统的软件定时器总可以了吧，经过测试发现，效果仍然不好，只要是几十秒的周期，误差大的问题仍然不能解决，当时一度很蒙蔽：这可是操作系统啊，时钟这么不靠谱吗？
直到后来，我换成硬件定时器，才解决了周期有误差的问题。
总结
- 嵌入式RTOS对于CPU来说，只是一个稍微复杂的应用程序。
- 嵌入式RTOS的优先级要低于外部硬件IRQ的优先级。
- RTOS的时钟节拍不需要很精准，只要有周期的心跳，就能保证操作系统周期的运行、周期的调度。
- ROTS的软件定时器只能用于【短时间】、对时间要求不严苛的应用场景。
- SysTick的优先级设置为最低，不是完美的解决方案，是一种对外部IRQ影响最小的解决方案，是最合适的方案。
