嵌入式系统优先级详解
在嵌入式软件开发中 ， 我们不可避免的需要接触优先级的概念 ， 掌握优先级的概念对于设计一个好的软件系统尤为重要 。
本篇笔记的主要内容有以下几个方面：
1、中断优先级
2、操作系统中的任务优先级
3、同等优先级处理
4、中断嵌套
今天鱼鹰借助大家熟悉的STM32F103平台和各位聊聊其中的密事 。
不管发生哪种情况 ， 当程序执行到C位置时 ， B的值都是一样的 。
当然 ， 以上分析是从C语言的角度进行分析的 ， 如果以汇编的视角进行分析（自加操作在汇编中分为三个步骤） ， 你会发现 ， 这里面其实还有第三种情况：
对于程序而言 ， 就好像根本没有进入中断一样！
这就是全局变量的使用隐患 。
但是善于分析的道友可能会提出这样一个疑问 ， 为什么上面只考虑了main函数中的B++被打断的可能 ， 却没有考虑中断(橙色部分)的B++被打断的可能 ， 是鱼鹰忽略了吗?
不不 ， 其实这里面就涉及到了今天的主题 ， 优先级 。
在裸机系统中 ， 中断优先级高于main函数的处理 ， 也就是说 ， 一且中断来临 ， 不管main函数执行到哪个位置 ， 都会优先处理中断程序 ， 只有中断程序执行完成后 ， 才会继续执行main函数 ， 所以中断的B++不可能被main函数打断！
这里插两个问题：
怎么进入中断函数的？
当中断请求(中断请求可以认为是种电平信号 ， 在寄存器中就表现为某一位的标志位)来临时 ， 硬件负责把部分寄存器存储到栈（一种特殊的数据结构）中 ， 这里面就包含了PC寄存器（用于指示下一条指令执行的位置） ， 之后从向量表中找到中断处理函数的入口地址 ， 开始进入中断处理函数中执行 。
怎么回到原来的位置？
因为在进入中断前已经保存了PC等其他寄存器的值 ， 所以只要在执行完中断处理函数后 ， 将之前的保存到栈中的值恢复回来 ， 那么CPU就可以继续从被打断的指令开始继续执行 。
更多相关的中断行为请查看《权威指南》 ， 鱼鹰不再细说 。
回到刚才的优先级话题 ， 正因为中断的执行优先级比main高 ， 所以中断中的B++不会被打断 ， 这也是为什么有些时候 ， 我们不需要对中断中的变量进行临界保护的原因所在 。
在Cortex-M3内核中 ， 中断分为可屏蔽和不可屏蔽中断 ， 同时又有可编程优先级和不可编程优先级之分 。
而不可屏蔽 ， 就是说这个中断是不可以屏蔽的 ， 比如复位中断（是不是不可思议 ， 代码执行的第一条指令竟然是中断处理函数里面的） ， 如果复位中断都被屏蔽了 ， 那么系统也就别想运行了 。
可编程 ， 意味着这个中断的优先级可以由软件修改（不可编程 ， 即优先级固定死了 ， 不能修改） 。
中断的优先级在设置时又有抢占式优先级和非抢占式优先级两种设置（根据单片机不同 ， 抢占式和非抢占式可设置的位数不同 ， 并且可以分配各自的位数 ， 即所谓的中断分组 ， 如STM32F103共有四位 ， 通过设置中断分组来决定抢占式和非抢占的位数） 。
抢占优先级 ， 即如果中断1的优先级比中断2的抢占优先级高的话 ， 一旦中断1发出中断请求 ， 即使已经在中断2执行了 ， 也会强制进入中断1执行 ， 这个类似于main函数与中断的关系 ， 只不过这里两个都是中断而已 。
但是如果不是同时发生呢？那么就会依次处理中断请求 ， 在其中一个中断处理过程中 ， 是不可以被另一个中断打断的 ， 同时如果本中断再来一个请求 ， 也不会重新进入中断函数处理 。
即中断本身不可打断自身的处理 ， 换句话说中断不会执行到一半时又因为自身新的中断请求来临而重新再次进入本中断处理函数执行 。
如果抢占优先级和非抢占优先级都设置成一样呢 ， 此时如果两个中断同时发生 ， 又该选择哪个先执行 ， 随机吗？
这里就涉及到硬件优先级了 。
在上图中 ， 每一个中断其实都是有固定的默认优先级的 ， 这个优先级肯定不同 ， 所以当抢占优先级和非抢占优先级一样的情况下 ， 在中断同时发生时 ， 先执行默认优先级高的 。
看图：
但是一旦中断打开了 ， 那么之前被屏蔽的中断就会立刻开始执行（有一个中断挂起位 ， 代表中断的发生 ， 只有CPU执行了中断处理函数 ， 并清零相应标志位 ， 该挂起位才会清除） 。
如果在关闭中断的过程中发送了两次中断 ， 比如外部中断发生了两次 ， 那么在开启中断后 ， 也只会响应一次中断 ， 因为挂起位就只有那么一位（不像队列一样可以保留多个标志位） 。
对于一般功能而言 ， 禁止全局中断确实有用 ， 对于保护全局变量也非常有效 ， 但是对于整个系统而言会有一定的影响 。
如果禁止中断的时间很短 ， 那么确实无关紧要 ， 但是一旦需要禁止较长的时间（毫秒级别） ， 对于那些需要及时处理的中断而言 ， 就是一个不可忽视的延迟 。
而在操作系统中 ， 为了保护那些全局变量 ， 禁止中断的操作时有发生 ， 那么是否有一种方法可以屏蔽部分中断 ， 而让高优先级的中断不被屏蔽呢？
有的 ， 在Cortex-M3内核中 ， 有一个寄存器专门干这事 ， 即BASEPRI 。
当设置该寄存器时 ， 将屏蔽所有优先级不高于某个具体值的中断 。
比如设置该寄存器为3 ， 那么优先级0~2的中断不会被屏蔽 。
所以在操作系统中 ， 我们可以修改禁止中断的代码 ， 使其不会屏蔽高优先级的中断 ， 对于高优先级中断来说 ， 可增加实时性 。
uCOSII中默认是直接全局禁止中断的（可以修改它） ， 但是FreeRTOS是可以禁止部分中断的 ， 使用的就是上述寄存器 ， 当然这个功能需要单片机本身支持才行 。
以上就是中断优先级的内容 ， 如果只会裸机的话 ， 那么以上内容就差不多了 ， 但是如果是操作系统 ， 那么需要再增加一个任务优先级的概念 。
所谓任务 ， 你也可以认为是一种中断 ， 只不过 ， 这种特殊的中断优先级低于所有的硬件触发的中断 。
中断的优先级凌驾于所有任务之上 。
但是操作系统是纯软件行为 ， 那么操作系统的任务优先级又是谁管理的？又是如何管理的呢？
答案就在Systick中断 。
既然要管理所有任务的优先级 ， 即在合适时选择运行优先级最高的任务 ， 那么操作系统本身必然需要有能剥夺所有任务执行的能力 ， 而中断是凌驾于任务之上的 ， 可以在任何时候剥夺任务的执行 ， 从而获得CPU的使用权 ， 所以选择中断作为操作系统的核心是合适的 。
但是中断那么多 ， 选择什么中断比较合适呢？没有比Systick中断更合适的了 ， 因为它就是为此而生的 。
Systick说白了就是一个定时器 ， 但是和普通定时器不同的是 ， 功能比较单一 ， 就是一个计数器而已 ， 所以使用它管理任务是合适的 ， 不会占用其他定时器 。
那么Systick又是如何管理任务的呢？
一般而言 ， Systick会设置成几毫秒中断一次 ， 在每次中断时 ， Systick处理程序（即操作系统内核）都会从所有的任务中选择最高优先级的任务执行 ， 也就是说 ， 系统总是运行最高的任务 。
而这个特性也就导致你的高优先级任务不可以无限执行而不主动释放CPU ， 因为一旦高优先级任务无限执行了 ， 那么低优先级任务将永远得不到执行机会 ， 这就给人一种死机的假象 。
所以 ， 空闲任务需要永远处于运行状态 。
从这个角度来说 ， 操作系统主要的功能就是定时从所有任务中寻找最高优先级的任务 ， 然后让该任务得到运行机会（使用PendSV中断切换到任务中 ， 模拟中断切换过程） ， 功能类似于中断管理器 。
而正因为操作系统只会寻找最高优先级的任务来执行（对于实时操作系统是这样 ， 有些操作系统可能先来先处理的策略） ， 所以任务本身主动释放CPU就显得尤为重要了 。
最常用的主动释放CPU的函数就是系统延时函数了 ， 调用这个函数后 ， 任务将延时一段时候才回来继续执行 ， 而在延时过程中 ， 操作系统就可以调用其他任务执行了 ， 正因为如此 ， 操作系统才显得高效 。
虽然操作系统需要中断来剥夺所有任务的执行 ， 从而拥有CPU的控制权 ， 但是一般而言 ， 它的优先级却是所有中断中最低的 ， 因为它的优先级只需要高于任务即可 ， 如果设置的更高 ， 那么就会影响到真正需要高优先处理的中断 ， 因为Systick中断的处理还是比较频繁和繁重的 ， 如果设置的太高 ， 那么在Systick处理时 ， 更低优先级的中断将无法处理 ， 这可不是我们想看到的结果 。
而如果设置成中断优先级最低的话 ， 既可以剥夺任务的执行 ， 又可以在高优先级中断来临时及时处理中断 ， 让系统的实时得到提高 。
与Systick配套的中断 ， 还有一个PendSV中断 ， 这个优先级一般和Systick设置成一样 ， 一般而言该中断的触发是由操作系统内核主动触发的（在切换任务时软件触发该中断） ， 而不像Systick一样 ， 定时被动触发 ， 关于两个中断更具体描述可参考《Cortex-M3权威指南》 。
既然中断可以设置成优先级一样的 ， 那么任务应该也可以才对 ， 确实一般的操作系统都可以设置相同优先级的任务（uCOSII不可以 ， uCOSIII和FreeRTOS、RT-Thread可以） ， 那么操作系统又是如何处理同等优先级的任务？
一般而言 ， 在任务初始化时 ， 会设置任务的时间片 ， 这个时间片就是在任务优先级相同的情况下才会发生作用 。
比如 ， 任务1设置5个时间片（即Systick中断时间） ， 任务2设置10个时间片 ， 如果两个任务的优先级一样 ， 那么在15个时间片内 ， 任务1将执行5个时间片 ， 之后切换到任务2执行10个时间片 ， 来回往复 。
那么比任务1和任务2优先级更高的任务该什么时候执行呢？答案是随时 ， 即只要高优先级任务有需要 ， 那么不管任务1和任务2是否主动释放CPU ， 都会被操作系统强制切换到高优先级任务中执行（由Systick完成 ， 所以可能会有一点延时） 。
那么优先级比它们低的任务呢？这个就靠它们的自觉了 ， 如果它们自觉的主动释放CPU（比如调用系统延时函数） ， 那么低优先级任务就有执行机会 ， 否则 ， 低优先级任务将不会执行！
该用一张图来说明整个系统的优先级关系了：
【嵌入式系统优先级详解】其实我们可以从Cortex-M3的中断优先级得到启发 ， 即空开部分优先级不使用 ， 留待后面扩展用 ， 比如设计优先级时可以设置成3、5、7、9、11 ， 留出最高的0~2用于可能的高优先级任务 ， 中间空出一个或两个优先级用于扩展 ， 这样一旦后面需要增加其他优先级的任务 ， 会显得异常简单（可能会有额外的一点内存损耗 ， 但却是值得的） 。
推荐阅读
- 现代迎来技术“爆发”解读第十代索纳塔动力系统
- 苹果|再次确认如果安卓系统不支持微信，鸿蒙OS是最大赢家
- Android系统|如果华为Mate40Pro定价5999元起，那我一定会劝你买它
- 精神药品|重磅！银河麒麟操作系统V10发布 支持海量安卓应用
- 华为鸿蒙系统|噱头还是真有用？如何看待PCIe 4.0
- 鸿蒙系统|华为Mate40稳了！迎来两大好消息，iPhone 12迎来劲敌
- IOS系统|iOS的TestFlight应用获得新图标 更加立体与写实
- 小米科技|鸿蒙系统手机或很快推出，小米实行合伙人制度
- 打破安卓系统垄断？华为鸿蒙系统手机或很快推出
- 华为鸿蒙系统|华为鸿蒙OS手机被曝即将推出，今年能看到真机吗？