基于uC/OS-II和MSP430单片机的RTOS的技术分析
其次，作为模拟中断堆栈指针的寄存器R4，必须在中断之外的任何情况下不被使用。因为，此时的R4必须时刻保持在中断堆栈的顶部，如果改变它的值，就会改变中断堆栈的结构。一般这个要求是由所使用的编译器来保证的，在我们所使用的IAR编译器中，有一个选项可以避免使用R4和/或R5。 本文引用地址： //m.amcfsurvey.com/article/172109.htm
具体设计时，我们在uC/OS-II每个任务的TCB(任务控制块)结构中加入以下几项：
TSP--任务堆栈指针。发生中断后，指向该任务的任务堆栈的顶部。
ISP--中断堆栈指针。如果在中断中发生任务切换，指向该任务在中断堆栈所保存状态的顶部。
FromInt标志--是否来自中断标志。用来判断该任务的状态是保存在中断堆栈中(为1)，还是保存在任务堆栈中(为0)。
下面假设一个普通任务1在执行过程发生中断，对它在中断执行过程中可能出现的几种情况进行分析。
(1)在普通任务1运行时引发中断，在中断中没有激活更高优先级的任务，而是正常结束中断，继续执行任务1，如图2所示。
开始中断：将在中断发生时保存在当前任务堆栈的SR和PC移到中断堆栈中保存，同时 SP回到中断前的位置并将它保存到该任务TCB中的TSP中(这是为了在中断结束后，保持任务堆栈的连续性)，然后将SP指到目前中断堆栈的顶部，按照自定义堆栈结构的顺序依次将所有寄存器都保存到中断堆栈中。保存的过程中R4必须与SP保持同步变化，同时将FromInt标志置l。
退出中断：由于没有激活更高优先级的任务，所以在中断任务完成后，将按正常的顺序退出中断，即将保存在中断堆栈中的寄存器推出堆栈，将FromInt标志置0，SP重新指向该任务的任务堆栈中，最后，将PC指针指向中断前的返回地址，继续程序运行。
(2)在普通任务1运行时引发中断，在中断中激活更高优先级的任务2。中断结束时由任务调度器调度去执行更高优先级的任务2，没有返回普通任务1。
当执行任务2时，任务调度器会将任务2保存在自己任务堆栈中的状态恢复并执行任务2。执行完后，如果没有激活更高优先级的任务，那么按照优先级高低的原则，调度器将调度执行任务1。通过判断任务1的TCB中的FromInt标志，可以知道任务1的状态是保存在任务堆栈中还是中断堆栈中，从而可以将其状态恢复，继续运行。
(3)在普通任务1运行时引发中断，在中断中激活更高优先级的任务2，执行任务2时又发生中断。
由于uC/OS-II是严格按照优先级抢占式原则进行任务调度的，所以将任务状态保存在中断堆栈顶部的任务的优先级一定比状态保存在它下面的任务的优先级高。在执行时，是由中断堆栈的顶部向底部顺序执行。在这种假设中，一定先执行任务2，然后执行任务1，如图3所示。
(4)在普通任务1运行时引发中断，在中断中激活更高优先级的任务2。在执行任务2时又发生中断，在中断过程中任务2由于等待信号量而被挂起。
这种情况在系统最初设计时已经被禁止，在中断中不允许使用信号量将中断挂起。
(5) 在普通任务1运行时引发中断，在中断中激活更高优先级的任务2。在执行任务2时又发生中断，中断中激活更高优先级的任务3。中断结束时由任务调度器调度去执行更高优先级的任务3。
这种情况与讨论的情况2是一样的。
(6)高优先级任务2被更高优先级的任务3中止，在任务3运行完后，任务调度器将直接调度执行任务1(按照优先级调度)。
由于各个任务的ISP和TSP在任务切换前都已经保存在该任务的TCB中，任务1的堆栈指针和R4可以回到该任务在其任务堆栈和中断堆栈的正确的位置。
任务2被中止包括两种情况。一是任务2被别的任务删除，此时任务2在中断堆栈中占用的空间会自动释放。二是任务2被别的任务挂起，此时应在将程序挂起的函数TaskSuspend()中添加一段代码，将其保存在中断堆栈中的状态移到自己的任务堆栈中，同时将其TCB中的FromInt标志设为0。这样，在任务2解除挂起后，会去任务堆栈中恢复其状态。
(7)中断中发生中断嵌套。
发生中断嵌套时，要按照中断嵌套的机制进行处理。首先，在中断嵌套中，不允许进行任务调度，这样，即使在中断嵌套中激发了更高优先级的任务，也必须等到最后中断退出前才进行调度执行。这一点是由uC/OS-II系统设计保证的。其次，保存寄存器和函数调用所占用的RAM字节全部在中断嵌套中。在退出中断嵌套时，不必将TCB中的FromInt标志复位。
5 程序设计流程
(1)中断程序结构和设计流程，如图4所示。
评论