STC单片机uC/OS-II移植记（9）：RTOS或DOS？三论STC单片机RTOS中的临界区保护方法

杨***

笔者前面的系列文章讨论了在RTOS中用“关闭全局中断作为临界区保护方法”的利弊和临界区保护嵌套的合理性。

本文将再次讨论在STC单片机上的RTOS采用“关闭全局中断作为临界区保护方法”的必要性，以及阐明未来避免在STC单片机上采用“关闭全局中断作为临界区保护方法”的终极对策是采用DOS。

一、关闭总中断的合理性

事出反常必有妖，为什么已经移植到STC单片机上的国内单片机上普遍使用的uC/OS-II、FreeRTOS以及尚未移植到的RT-Thread，它们均采用了关闭全局中断作为临界区保护方法？

（1）以笔者正在进行移植uC/OS-II RTOS为例，下图为测试程序的中断服务程序部分：

其中第408行到第425行是系统中断（定时器0中断）的ISR程序，在其中第417行调用了RTOS系统的时间节拍功能，第435行调用了系统级任务调度功能，这两个功能中均使用了临界区保护功能。

目前测试程序中的临界区保护方法为关闭和打开总中断方法：#define OS_ENTER_CRITICAL() EA=0// 直接禁止总中断

#defineOS_EXIT_CRITICAL()    EA=1 // 直接允许总中断

（2）如果只考虑在系统中断内才进行“系统级任务调度”，那么可以将上面的临界区保护方法修改为：

#defineOS_ENTER_CRITICAL()  ET0=0 // 只禁止定时器0中断

#defineOS_EXIT_CRITICAL()    ET0=1 //只允许定时器0中断

这种方法被称为“在RTOS系统中内不关闭总中断（全局中断）”，只关闭系统定时器中断的方法。

（3）对于ADC功能和计算能力都很强大的STC单片机，考虑某个应用需要准确第每毫秒采集一轮ADC作为测量值，每一轮ADC测量需要10次ADC采样来求平均值，同时要求使用RTOS的某个高优先级的实时任务（任务级别函数，由系统级调度来切换）来处理测量得到的数据，比如进行机电控制或数据传输。完成这个任务，用RTOS的术语来说就是要求RTOS的实时任务响应时间为1毫秒。前文测试程序中设置了一个10KHz的定时器3中断，就是模拟这个应用的，上图第428行到第439行程序为定时器3的ISR程序，实际应用时只需要在第434行处加上“LCALL XXXXX”ADC单次采集处理程序即可。

其中XXXXX是一个中断内调用的函数（系统级函数），在其中单次ADC采集和累加，完成10次累加后将ADC处理实时任务的状态设置为就绪，等待下次系统级调度就可以切换到该任务进行处理了。

（4）重点：测试程序中系统中断的周期是20毫秒，实时任务的响应时间是10毫秒，这时如果uC/OS的设计者只允许在系统中断内进行系统级任务调度，那么显然不能满足上面应用的1毫秒响应时间的条件了。这时大概率出现的是在某轮ADC采集完成后，ADC实时任务已经就绪，然后平均要等10毫秒后才会发生系统级任务调度，才会执行ADC处理任务，最终结果是ADC实时任务每秒钟只执行了100次，不符合要求。

（5）结论：作为通用的RTOS，uC/OS的设计者必须允许在非系统中断内进行系统级任务调度，比如定时器3。如果要同时允许在定时器0和定时器3内都进行系统级任务调度，不但在定时器3中要加上第435行的系统级调度函数，临界区保护方法还必须改写为：

#defineOS_ENTER_CRITICAL()  ET0=0; IE2 &=  ~ET3

#defineOS_EXIT_CRITICAL()    ET0=1; IE2 |=  ET3

（6）在STC官方介绍的uC/OS-II移植范例中，是以串口1中断为例子的，其ISR程序如下图：

该范例程序也采用了标准的uC/OS-II的ISR编程规范，其中第442行为调用串口1中断服务子程序。

作为串口1，中断是按照每收到1个字节就中断一次发生的。如果使用115200的波特率，字符串中的每个字符的间隔大约也是1毫秒，理论上要求实时任务的响应时间也是1毫秒的量级（即使采用缓冲区接收，但对于字符流等通信过程，如果收到某个行结束符不及时处理，也可能产生数据丢失），单靠20毫秒的系统中断进行系统级任务调度时不行的，所以就需要第445行程序进行系统级任务调度，这时临界区保护方法还必须加上UART1中断允许位操作：

#defineOS_ENTER_CRITICAL()  ET0=0; IE2 &=  ~ET3;ES=0

#defineOS_EXIT_CRITICAL()    ET0=1; IE2 |=  ET3;ES=1

（7）哈哈：相信读者这时已经看出笔者下的逻辑圈套了，如果RTOS的设计者要为像STC单片机的DMA、端口电平等这些先进的和高速的片上设备的中断提供快速的实时任务响应时间，作为通用的RTOS框架就要想进行临界区保护而又不关闭总中断，就需要在上面的临界区保护方法中一一加上这些设备单独的中断允许语句！

这是何必，就像成语中所说的多此一举：关闭每一个中断允许也就等效于关闭总中断——直接关闭总中断EA=0即可！

（8）笔者认为，作为RTOS，就应该为用户提供尽可能快的实时任务响应时间，对于单片机应用中最重要的中断服务程序，应该允许在每个中断中都可以进行系统级任务调度，这就对应临界区保护方法是关闭和打开总中断。因此这就是主流的FreeRTOS、uC/OS-II和RTT均采用这种“简单粗暴”却行之有效的临界区保护方法的原因。

二、临界区保护的终极方法就是采用DOS操作系统

这里的“DOS”是一个简称，不是指PC-DOS这个狭义的操作系统，而是指像Unix、Linux和Windows等标准的磁盘操作系统。

（9）在DOS中，由中断驱动的实时任务总是能够得到及时响应的，比如键盘、鼠标、网络和USB等外部设备，这时实现实时人机交互的前提。同时在用户的任务程序中，并不提供关闭总中断之类的操作接口，哪怕是用户手写关闭总中断的汇编指令或者机器码指令，DOS操作系统也都进行了临界区保护，不但不执行这些指令，而会报警出错，采取保护DOS系统的措施，甚至杀死用户任务。

（10）在DOS系统中，将所有的任务分为两个级别：系统级和任务级。所有的中断管理、设备管理、任务调度管理以及磁盘文件管理任务和程序都是属于系统级的，用户任务和程序属于任务级的。这些DOS运行的CPU都在指令级别上分为核心级指令和用户级指令，用户编写的程序（黑客编写的除外）都只能运行用户级指令，当CPU处于用户级状态时像关闭总中断或者读写操作系统变量数据这样的核心级指令根本不会被执行，只会掉进陷阱中断，进入操作系统核心，从而实现系统临界区保护的功能了。在DOS的这种临界区保护方法中，并不需要关闭总中断，也不允许关闭总中断。

（11）现代的DOS操作系统都是属于RTOS，都能提供用户任务的实时响应。

用户任务通过调用DOS的系统功能接口（比如GUI，比如Sleep接口函数），实现用户级任务调度（任务级，其实还是通过了DOS系统操作）。

而DOS操作系统则是通过“回调函数”，唤醒用户任务，实现系统的任务调度。

与前面介绍的单片机RTOS编程方法不同，无论是系统功能接口或者是回调函数，都通过“句柄”与具体的设备和操作对应，实现了操作系统与用户程序都能理解发生了什么事情和对方想干什么，但又不互相干扰，同时实现了操作系统和用户程序的双向临界区保护。

（12）目前典型的基于DOS的RTOS有基于Linux系统的uCLinu和RTLinux，基于Windows系统的Intewell，以及基于多种平台的VxWorks。这些都可以在网上查到，这里就不再一一介绍了。

（13）笔者在利用树莓派开发板进行外部设备PWM控制、NRF24L01多点通信和LORA远距离通信研究时，深感树莓派操作系统的临界区保护功能的强大，不仅保护了操作系统本身的系统资源，而且连外接管脚这种公共资源（临界资源）的高低电平和工作模式都进行了保护，而且提供了完善的操作出错的系统回调功能，感觉是达到了临界区保护的天花板了。

三、结 论

对于小资源（主频和RAM）的STC单片机上的RTOS，应该采用像uC/OS-II、uC/OS-II 、FreeRTOS和RTT这些有完备的系统级任务调度临界区保护功能类型的RTOS，未来大资源的STC32系列单片机应该采用DOS类型的RTOS。

大刀***

杨老师的大作，马住拜读！

神***

必须学习