STC单片机uC/OS-II移植记（10）：RTOS中的中断嵌套保护方法

杨***

由于STC单片机的基本架构是8051或80251单片机架构，这种架构（包括传统的80x86架构）的中断机制不允许在其上运行的RTOS在有中断嵌套时进行任务切换，因此在STC单片机的RTOS上必须采用特殊方法来实现中断嵌套保护。

一、uC/OS-II原移植程序中断的中断嵌套保护方法问题

（1）“RTOS中断嵌套保护问题”，是指如果在一个中断尚未结束并且被中断的任务的优先级较低的情况下，刚好优先级较高系统中断发生中断，就产生“中断嵌套”，在系统中断中如果又检测到一个优先级更高的任务休眠到期了，那么系统中断将会退出中断并把任务切换到新任务，CPU转向到新任务程序去执行。

发生这种情况时先前的中断现场（堆栈中的寄存器）留在被切换走的老任务中，余下的中断代码也没有执行，包括中断返回指令“RETI”也没有没有执行，这意味上一个被嵌套的中断没有退出。

如果这样就会带来两个极危险的后果：一是如果老任务由于优先级低而迟迟得不到执行，这时第一个中断的剩余程序也就迟迟得不到执行，中断迟迟不会退出，这将会阻塞优先级和它一样以及比它低的所有中断。二是如果第一个中断正在执行不能被打断的任务，比如正在与外界进行通讯，比如正在进行机电控制，这时会产生执行超时等不可预料的故障。

避免这种危险的问题就称为“RTOS中断嵌套保护问题”。

（2）如果系统中断采用不可屏蔽中断，则其优先级最高，且不受EA和ET0的控制，它可以中断其他任何中断程序的执行，因此产生中断嵌套的机会非常大，很容易产生RTOS中断嵌套保护问题。

（3）RTOS中常见的解决中断嵌套保护问题的方法是设置一个中断嵌套计数变量，每次进入任何中断时就将其加1，退出任何中断时减1，这样在系统中断任务调度程序中读取中断嵌套计数变量就知道有没有发生中断嵌套，如果有，就不进行调度，等到下次系统中断发生时再检测和调度。

（4）笔者认为对于任何单片机RTOS采用中断嵌套保护措施都是必要的，主流的单片机RTOS比如uC/OS-II、FreeRTOS和RT-Thread都采用了中断嵌套保护措施，只是方法不同而已。

（5）原移植uC/OS-II的中断嵌套保护程序如下图：

其中“OSIntNesting”是中断嵌套计数变量，进入中断时第639行将其加1，进行系统级任务调度时，第655行先将其减1，然后第657行判断是否有中断嵌套，如果没有再进行第666行的任务调度，如果有就跳过第666行，不进行任务调度。

（6）不过移植的uC/OS-II的中断嵌套保护程序存在隐患，它的中断ISR程序如下图：

1）每个中断开始和结尾移植者都试图用一对关闭中断和打开中断语句来避免中断嵌套，但是这是没有用的。一是在中断过程中第415行系统时间Tick函数调用和第439行串口通讯中断处理函数中都包括临界区保护语句，这些语句中的退出保护语句“EA=1”等不到中断ISR最后一行程序，提前就将总中断打开了。二是系统中断是不可屏蔽中断模式，串口中断中的第434行根本不能避免系统中断的嵌入。

2）由于原中断嵌入保护程序是用C语言写的，因此在中断ISR中，进入中断语句第436行只能写在寄存器现场保存语句第435行之后，退出中断语句第442行只能写在寄存器现场恢复语句第443行前面。这就产生一个隐患，由于第435行和第443行时宏定义包含多条汇编指令，如果在这时发生系统中断，则会产生中断嵌套保护问题。

二、改造后uC/OS-II中断嵌套的保护方法

（7）改变中断嵌入计数变量的存储类型。原移植程序的定义是：

OS_EXT  INT8U  OSIntNesting;      

变量是XDATA类型的。

改造后的uC/OS-II中的定义是：

OS_EXT  INT8U data uCx51_IntNesting;

变量是DATA类型的。

（8）取消中断进入和退出函数，直接操作中断嵌入计数变量。下图是改造后的uC/OS-II的中断ISR的程序：

其中在进入中断后的第一行就使用“INC  uCx51_IntNesting”指令将中断嵌入计数加1，在退出中断前的最后一行程序才使用“DEC  uCx51_IntNesting”指令将中断嵌入计数减1，这就避免了前面说的第二个隐患。由于这两条指令均不会影响单片机的PSW寄存器，所以可以这样做不影响中断的现场。

另外RTOS的中断嵌套保护不是“保护中断不被嵌套”，所以原移植程序中的中断服务程序中开始和结束的关闭和打开中断语句是多余的，在改造中去掉了。

（9）改变原中断退出函数“OSIntExit”为系统级任务调度函数，见下图：

对比前面的移植函数，去掉了将中断嵌套减1的语句，将第660行判断嵌套的条件改为等于1（中断还未退出）。修改之后该函数只有系统级任务调度功能，所以将函数名也修改为“uCx51_IntSched”，以示区别。

另外，改造还必须将整个uC/OS-II中涉及中断嵌套计数变量的地方都做相应的修改。

三、改造后的uC/OS-II的系统中断

（10）改造后的uC/OS-II的系统中断使用两个定时器：定时器0和定时器3。这两个定时器的初始化程序如下：

其中定时器0工作频率为1KHz，模式是16位自动重载，定时器3工作频率为10KHz，模式是16位自动重载。

最早陈是知先生移植时使用的51单片机是12T的CPU，定时器0只能工作在50Hz量级，因此任务休眠函数“OSTimeDly”的时间精度是20毫秒。现在工作1KHz频率，任务休眠函数的时间精度提升到1毫秒。

在改造后的uC/OS-II，直接使用宏定义语句：

#define uCx51_Task_SleepMS  OSTimeDly  

就实现了以毫秒为单位的休眠函数。

（11）改造后的uC/OS-II的定时器0系统中断目前只承担一个功能：系统节拍处理，见前面改造后的uC/OS-II的中断ISR的程序的第176行“LCALL _?OSTimeTick”。

（12）改造后的uC/OS-II的定时器3系统中断目前只承担一个功能：系统级任务调度处理，见前面改造后的uC/OS-II的中断ISR的程序的第196行系统级任务调度函数“LCALL _?uCx51_IntSched”，这个定时器3中断优先级固定为最低级。

四、改造后的uC/OS-II系统指标测试

（13）为了进行RTOS性能指标的数量测试，本文范例在P2端口连接了一个8通道逻辑分析仪，并且在程序中加入了测试语句。下图是实时任务程序：

其中P22第2通道显示任务A波形，P24和P25显示任务B波形，P26和P27显示任务C波形。

（14）上面程序中第75行P23=1显示任务级调度函数“OSTaskResume(3)”的开始，由于任务B（优先级3）的优先级比任务C（优先级4）的高，所以这个函数会立即将任务控制权切换给任务B。

任务B是在第55行被挂起的，获得任务控制权后会执行下面的第56行程序P23=0，因此测量P23第3通道的正脉冲时间就是任务级调度（非中断任务切换）的时间。

（15）在前面定时器3的中断中，只调用了系统级任务调度（中断任务切换）函数“_?uCx51_IntSched”，如果没有更高优先级的任务就绪，该函数返回，这时上面程序中第185行（P20=1）执行到第192行（P20=0）的正脉冲时间就是一轮系统级任务调度查询时间，如果进行了任务切换，则会调用“OSIntCtxSw()”函数，在那里退出，正脉冲时间就是系统级任务调度任务切换时间。

（16）下面是本文系统测量范例运行的整体效果逻辑分析仪截图：

其中第4通道高电平时间是任务B获得CPU控制权的时间，第6通道高电平时间是任务C获得CPU控制权的时间。

第3通道的尖峰是任务C到任务B的切换时间，将这部分放大看为下图：

测量结果是：任务级切换时间为32.25微秒。

（17）下图第1通道的测量图：

第1通道对应系统节拍的时间，其中“OSTimeTick()”函数处理那些按指定时间休眠的任务，将它们的时间节拍计数减1，然后判断是否已经完成了休眠并唤醒它。

测量结果是：每个系统节拍最少花费29微秒。

（18）上图第0通道有宽窄不同的正脉冲，其中宽的脉冲对应系统级任务调度时间，测量结果是：系统级切换时间为20微秒。

窄的脉冲对应系统级任务调度查询时间，测量结果为中断查询时间为5.75微秒。

神***