单片机RTOS的一种不关闭任何中断的临界区保护方法

其中第169行和第191行调用任务切换加锁函数“OSSchedLock()”进入临界区保护，
然后第210行和第216行调用任务切换解锁函数“OSSchedUnlock()”退出临界区保护。

（2）方法0的测试结果。采用方法0运行上面的测试3程序，运行结果的时序见下图：
可以看到通道0、通道6和通道7的中断信号是连续的，没有被临界区保护中断掉。与上篇文章无任何临界区保护的时序图（见下图）相比：
可以看到任务A和任务B的执行位置不同了。在进入了禁止任务切换的临界区保护状态之后，第187行的“OSTaskResume(2)”激活任务A语句和第206行的“OSTaskResume(3)”激活任务B语句在分别将任务A和任务B的状态改变为“就绪”之后，尽管它们的优先级比正在执行的任务C的优先级高，但在临界区保护中并不能够立即进行任务切换得到执行，也就是说区间3和区间5并不能得到执行。从图上可以看在第170行到第216行的临界区保护的程序区间，任务C程序的程序连续执行不被打断，实现了不依赖关闭任何中断的临界区保护。（3）当任务C的程序按照区间1、2、4、6顺序执行到第210行解除禁止任务切换后，由于系统中断产生的中断内任务调度程序就会将CPU控制权交给最高优先级的就绪任务A执行，见前图的通道4，等到任务A挂起自己后，中断内任务调度程序就会将CPU控制权交给次高优先级的就绪任务B执行，见前图的通道5，等到任务B挂起自己后，CPU控制权被切换回任务C继续执行区间7和9。最终整个测试程序是按照区间1、2、4、6、3、5、7、8的顺序执行的，与无临界区保护的顺序不同。（4）方法3的测试结果。虽然采用了方法3，但用户程序中并没有使用关闭中断的临界区保护方法语句，因此对两个移植版的测试结果均与方法0一样。
（5）测试3结论：如果采用方法0则整个测试运行的过程中都没有关闭总中断（程序中也没有关闭任何中断），本测试本质上是实现了一种不关闭任何中断进行临界区保护的方法。

RTOS常用术语解释:1. 互斥: 使用RTOS后, 多个任务就好像是在并行运行一样, 这样给我们带来了极大的便利, 但是, 也带来了一些问题, 首当其冲的便是互斥. 典型的是全局变量的访问问题. 举例说明: 有个结构体包含8字节的数据, 现在任务2正在改写这个结构的数据, 但是写到一半时, CPU控制权突然被剥夺了, 此时任务1获得CPU控制权,并且任务1需要读取这个结构体的数据, 很显然, 如果没有特别的防护措施, 任务1将读到一个错误的数据, 因为任务2写数据才写了一半! 解决此类问题的办法便是互斥访问, 即当一个任务访问全局变量在所有操作未完成之前, 不允许其它任务或中断对该变量的访问. 除了变量互斥, 还有资源互斥等, RTOS提供了许多互斥访问的方法.2. 临界区. 临界区是一段执行流不可被打断的代码段. 在RTOS里, 有许多状态是非此即彼的, 即不存在中间状态. 典型的如任务切换, 当调度器正在切换任务,改写系统核心变量时, 此时执行流是不可以被打断的, 即->调度器现在要调度从任务1切换至任务2, 但是如果操作只执行了一半就被打断, 那么现在运行态的任务到底是任务1呢还是任务2呢, 总不会告诉我现在正在运行任务1.5吧. 所以这个时候执行流是不能被打断的. 临界区还有许多其它的用法, 比如上面说的互斥访问通常就是通过临界区的设定来实现. 小型RTOS一般是使用关总中断的方法来实现临界区功能, 因为关闭总中断以后, 当前的执行流就不会被打断.3. 可重入性. 在C语言里函数的可重入性通常是指嵌套和递归调用, 但使用RTOS后, 还有一种情况便是一个函数可能被多个任务调用, 如果这个函数是不可重入的, 那么将可能引发问题, 所以: 用RTOS后, 通常默认所有的函数都是可重入函数. 4. 信号量. 在这里, 二值信号量, 计数信号量, 消息邮箱, 队列, 标志集, 等统称为信号量 信号量用于任务和任务之间, 任务和中断之间的通信和同步. 从上面的RTOS框架代码可以看出, 每个任务彼此之间是独立的, 任务和任务之间并没有太多的关联, 但是我们想要使其中一个任务和另一个任务之间发生点什么, 比如同步运行, 比如互通数据,该怎么办呢? 各种信号量就是为此服务的, RTOS提供了一整套完整易用通信和同步的方法.5. 共享资源: 可以被一个以上任务使用的资源叫共享资源6. 死锁: 死锁是RTOS运行时,进入了一种类似于死机状态的假死状态. 多任务运行时, 当一个任务要使用互斥资源时, 要先获得并占用互斥资源的使用权, 如果互斥资源正在被其它任务使用, 则当前任务需要阻塞自己并等待资源. 如果以下情况发生,则产生死锁: 任务1运行需要使用资源A和B, 在获得A后, 发现B被占用, 于是阻塞自己等待资源. 任务2也是需要使用资源A和B, 任务2已经获得资源B, 但是无法获得资源A,于是也阻塞了自己等待资源, 如此一来, 死结, 两个任务都无法运行, 同时导致资源A和B也无法使用了. 避免死锁的办法是, 当一个任务需要使用多个互斥资源时, 如果无法获取全部的资源, 则需要放弃已经获取的资源. 另一个办法是使用下面介绍的互斥信号量.7. 优先级反转, 和死锁类似, 也是任务在抢夺互斥资源时可能会发生的的一种状态, 发生优先级反转后, 高优先级任务需要等待低优先级任务运行完后才能获得CPU控制权, 效果就像优先级被反转一样, 偏离了我们原本的设计目标. 感兴趣的可以去百度一下, 限于篇幅,这里不详述. 8. 互斥信号量, 互斥信号量也是信号量的一种, 但是这里单独分开了来讲, 是因为它相对别的信号量来说有些特殊. 互斥信号量是为了解决死锁和优先级反转的问题而专门推出的一种信号量, 在uC-OSII里, 如果一个互斥信号量被多个任务请求, 已获得信号量的任务将暂时提高自己的任务优先级运行, 做到尽快释放资源, 从而可以解决死锁和优先级反转的问题.

RTOS任务切换过程和原理: 从上面RTOS模型中, 可以看出, RTOS中所谓的任务, 对于编绎器来说, 就是一个独立的函数. 任务切换, 简单的来理解就是暂停当前正在运行的任务函数, 然后跳转到另一个任务函数去运行. 这里涉及到两个问题:1. 调度器在执行任务跳转前, 需要保存当前任务函数的运行状态, 重点是CPU寄存器组, 这些寄存器是每个任务函数都要用到的, 如果离开时不保存好,当返回的时候, 就无法恢复这些数据, 除此之外还会保存堆栈栈顶和断点位置等, 以 备返回时, 可以找到回家的路. RTOS有个专用的术语, 叫做保存上下文. 当执行返回动作时, 恢复离开时的寄存器数据, 这时候叫恢复上下文2. 调度器是如何操作从一个函数跳转到另一个函数的.
现在来聊一聊调度器是如何操作从一个函数跳转到另一个函数中去的, 懂C语言的朋友可能第一时间想到到goto跳转指令, 然而实际上goto指令并不能从一个函数跳转到另一个函数, 它只能在函数内完成跳转. 言归正传吧,RTOS最常用的手法是利用中断, 或子程序调用返回. 下面是这个过程的详解:
当我们调用一个函时, 编绎器产生一条调用指令, 比如LCALL, 该指令的效果是保存当前的断点位置(PC+3的值)至堆栈中, 然后跳转到子程序开始执行,最后我们用RET指令返回到原来的断点. 关键点来了, 如果我们把LCALL保存的断点信息偷偷的给替换掉, 那么当执子程序返回指令RET时, 就不是返回到原来的位置, 而是去到我们想要去的任何地方! 这就是利用RET指令实现任务切换的原理.