μC／OS—II是一个针对微控制器和嵌入式应用而设计的轻量级实时操作系统，通过了美国联邦航空管理局符合RTCA D0178B标准的认证。这表明μC／OS—II能用于与人性命攸关的、安全性条件极为苛刻的系统。由于其轻量级的设计，源代码开放和优秀的实时性能等诸多优点，成为了众多嵌入式开发者的首选。
    但是对于中断处理，即使是最新版本的μC／0S—IIv2．85也未能提供层次化的处理机制来帮助开发者开发更灵活高效的中断服务程序。中断随时可能发生，而中断服务程序执行的越快越好。因此很多优秀操作系统均实现了分层次处理中断响应的机制来达到这个目的。例如，Linux提供了中断上／下半部的分层处理机制，上半部是常规意义的中断服务程序，而中断下半部则在允许中断的情况下执行上半部可延后的工作。一般而言，很多处理器在处理中断时是不允许中断嵌套响应的。所以中断下半部处理机制的意义在于尽量缩短中断服务程序(即中断上半部)的执行时间，而一些可以被延后和允许被中断的工作推后到中断下半部执行。在中断下半部允许中断，处理器就可以更快、更及时地响应中断，更少地丢失中断信号。在理想的情况下，最好是上半部所有的工作都交给下半部分执行。
    简而言之，层次化的中断处理机制实质上是一种可以使开发者在处理中断时尽量缩短屏蔽中断时间，提高异步事件响应的机制。μC／OS—II的设计者Jean J．Labrosse在其著作中谈到：实时内核最重要的指标就是中断关了多长时间。所以为了帮助开发者合理设计中断服务程序，以使其嵌入式系统获得最好的实时性，μC／OS—II有必要实现层次化的中断处理机制。本文将从分析μC／OS—II的中断处理入手，介绍通过引入中断下半部来实现层次化的中断处理机制的设计方案和实现方法，并通过在ARM7处理器上的测试来说明这种机制的引入对于提高系统实时性的意义。

1 中断下半部的设计方案
    目前，在μC／OS—II内核中任务的运行空间分为中断空间和任务空间。中断空间即为中断服务程序运行所处的空间，这时处理器执行中断服务程序，而所有任务(task)都被处于被中断态。对很多处理器而言，在中断空间内中断请求是被屏蔽的。中断下半部的引入将中断空间一分为二，如图1所示。中断的上半部为中断服务程序，执行那些有严格时限要求不能被打断的工作；中断的下半部执行那些在中断上半部被延后，允许被中断的工作。中断上半部和下半部都应有自己独立的栈空间，二者不会干扰。

    μC／0S—II已经设计了完善的中断服务程序的入口和出口函数，所以为了实现中断上半部和下半部的衔接，要从μC／0S—II的中断出口函数OSintExit()着手进行修改。修改后的OSIntExit()实现的功能将是：退出中断的上半部，检查中断下半部是否有就绪的服务程序，若有则在允许中断的情况下执行中断下半部的处理函数，若没有则进行任务调度恢复处理器到任务空间执行。
    中断下半部的核心是中断下半部的管理函数OSDo-Sirq()。它的功能是检查中断下半部的状态变量，依据优先级顺序选择就绪的下半部服务程序顺序执行，并且对相应的下半部状态进行修改，最后跳转到下半部的出口函数。出口函数OSSirqExit()使处理器完成从中断空间到任务空间的转换。至此，中断服务全部完成，用户任务得以继续执行。
    本设计使用softirq来指中断下半部的服务程序。中断下半部支持最多32个具有不同静态优先级的softirq。中断优先级范围为0～31，O是最高优先级，31是最低优先级。这里引入了优先级的思想，因为上半部服务程序可能需要对应的softirq来完成延后的任务，类似的softirq也应有不同的优先级来标识它们先后的运行顺序。而采用静态实现的目的是为了实时性和稳定性的考虑，若采用动态实现，代价是可能产生内存碎片和更多的处理器资源损耗。每一个softirq都有对应的标志变量来标识它的使能、屏蔽和就绪的状态。一组具有明确功能定义的API用于softirq的注册、屏蔽和使能等功能。
    一般情况下，中断服务程序是不会重入的，因为绝大多数处理器会在中断执行时禁止中断，至少是禁止同级和更低优先级的中断。本设计的中断下半部同样不要求softirq具有可重入性，因为在下半部的实现中已通过巧妙的设计消除了重入的可能性。softirq遵循μC／OS—II对编写中断服务程序的限制要求，例如中断服务函数不能执行可能会导致任务阻塞的函数等，在此不再赘述。

2 中断下半部的实现
    基于操作系统设计全局的考虑，中断下半部的实现应遵循以下几点原则：
    ①中断下半部也将运行于中断空间，这意味着任务空间的所有任务都要被阻塞。中断下半部与中断上半部(即中断服务程序)一个根本的不同是：中断下半部允许中断。
    ②尽量对原μC／0S—II体系结构做最小化的修改，如任务调度机制、任务空间的各种保护和同步机制等。改动所涉及的范围越大，引入bug的可能性也越大。在所增加的代码中尽量利用原μC／0S—II提供的系统调用，如开关中断还有任务调度等函数，这样兼顾了效率和安全性。
    ③尽量减少使用平台相关性代码，保证μC／OS—II的可移植性。
    ④设计简洁明确的API接口，以方便其他开发者能够轻松使用这种机制。
    根据中断下半部的设计方案，其实现分为以下4个主要的模块。
2．1 中断下半部入口的实现
    μC／OS—II核心代码os_core．c中的OSIntExit()函数是μC／OS—II中断处理程序的出口。为了实现中断下半部的入口，应将OSIntExit()函数中if((OSIntNesting=0)&&(OSLockNesting==O))语句以下列代码来代替：

    第1条if语句判断是否所有中断服务程序都已经结束，注意这里也包括softirq。因为在进入下半部管理函数后会执行OSIntNesting++，若softirq正在执行则OSInt-Nesting一定大于O。这个简单的if判断语句消除了soft—irq的重入的可能性。判断条件为真后，继续判断全局变量softirq_flag，若其值为SOFTIRQ_ENABLE则启用中断下半部。全局变量softirq_stat可能的值有3个：
    ①SOFTIRQ_READY，说明有就绪的softirq等待运行；
    ②SOFTIRQ_RUNNING，说明softirq正在被调度但其状态可能为被中断态；
    ③SOFTIRQ_NONE，说明没有softirq处于就绪状态。
   
    此判断语句条件为真时，函数OSIntCallSirq()将会保存被中断任务的上下文，初始化中断下半部堆栈指针，并执行下半部管理函数OSDo-Sirq()。若判断结果为假，则中断处理返回被中断的语句继续执行。而这条语句可能为中断下半部的代码，也可能为任务空间的代码。0S—IntCallSirq()是一段具有平台相关性的汇编代码，在不同的处理器平台上有不同的实现代码，其流程如图2所示。

2．2 下半部管理函数OSDoSirq()的实现
    这是中断下半部实现的核心部分。其代码如下：

   

    首先，通过使用OSIntNesting++以防止softirq的重入，设置softirq_stat的值为S0FTIRQ_RUNNING以标识softirq在执行。通过检查softirq_pending的值来判断是否还有就绪的softirq等待执行。
    然后，利用INTS_0N()显示允许中断，并执行getHighPrioSirq()函数快速地判断已就绪最高优先级的softirq的序号。getHighPrioSirq()利用了PendingMap[]数组实现了以空间换时间的思想，能够快速计算出一个32位无符号整数中最低一位“1”的序号。PendingMap口是有256个INT32U类型数据的数组，PendingMap[temp]的值就是以二进制表示的8位无符号整数temp中最低一位“1”的序号。getHighPrioSirq()判断一个32位整型无符号数中最低一位“1”的序号，最多只要经过4次与操作和移位操作。所以，getHighPrioSirq()是一个非常快速的函数，不会给处理器带来明显的负担。
    softirq[]是中断下半部服务函数指针数组，它内含32个数据对应不同的32个softirq。(*softirq[num])()会将PC设为第num个服务函数的入口地址，从而执行这个服务函数。执行完成后立即关闭中断并清除这个softirq的就绪标志。
    当所有的就绪softirq执行完成后，设置softirq_stat为SOFTIRQ_NONE，执行OSIntNesting一一，并调度下半部出口函数OSSirqExit()离开中断下半部。
2．3 中断下半部出口函数OSSirqExit()的实现
    OSSirqExit()将首先判断OSLockNesting的值，若为O，则执行OSStartHighRdy()调度执行已就绪的最高优先级的任务；若非0，则执行OSResumeCur()调度执行被中断的任务，如图3所示。以上两个函数都会从对应任务的堆栈中恢复出任务的上下文，使得处理器返回到任务空间。

2．4 通过API使用中断下半部
    本设计的中断下半部提供了以下API，供开发者使用这种机制：

    这个调用将使当前任务阻塞并立即切换到中断下半部执行softirq的系统调用。开发者可能希望在开启中断并且禁止任务调度的情况下执行某个任务(利用softirq，这很容易做到)，并且对实时响应外部中断无任何影响。这个调用实现的功能类似于模拟一个中断的发生。
    以上API接口均经过良好的设计，功能定义明确，实现代码短小精悍，所有带返回值的函数在遇到参数错误的情况下，能返回相应的错误信息以有利于开发者调试。

3 测试中断下半部对实时性的贡献
3．1 测试平台及测试方法说明
    测试采用三星公司基于ARM7核的S3C44BOX处理器，其工作在66 MHz的频率。μC／OS—II版本号为2．85。用处理器内部的定时器在调试环境下进行时间测试，因为调试环境下可以通过设置断点，快速、准确地查看定时器的当前值。
    测试方法：使用中断下半部对一个中断服务的典型应用进行修改，分别测试修改前和修改后的中断响应中关闭中断的时间，并对比关闭中断时间来说明实时性。
3．2 测试中断下半部屏蔽中断的时间
    主要函数屏蔽中断的时间如表1所列。

    从表1可以看出，在中断下半部入口函数OSIntExit()中所增加的代码给内核增加了约6．2μs的关中断时间，中断下半部管理函数OSDoSirq()给内核增加了约3．5μs的关中断时间，中断下半部出口函数OSSirqExit()屏蔽中断的时间约为4．4μs。经过计算，一次完整的中断下半部处理增加了约14．1μs的关中断时间。
3．3 测试中断下半部缩短中断关闭的时间
    Uart_Printf()为常用的串口打印函数，其常用于满足特定条件时通过串口打印信息。很多开发者喜欢在中断服务程序中使用它，所以，仅仅包含一句Uart_Printf()的中断服务程序，可以被认为是一个普遍而简单的应用。下面给出针对只包含一句Uart_Printf()的中断服务程序进行测试的结果。
    中断上半部除设置中断相关寄存器指令外，仅包含一条Uart_Printf(“real-time test＼n”)，其通过串口发送一串字符。通过S3C44BOX内部定时器测试得到，CPU从中断触发到回到任务空间继续执行所花的时间为970μs，在这段时间内所有中断都被屏蔽。
    若在中断服务程序中使用OSRegSirq()注册softirq，将Uart_Printf(“real—time test＼n”)转移到中断的下半部执行，这时从中断发生到回到任务空间继续执行所花的时间为990 μs。总的运行时间虽然增加了20μs；但在此过程中，中断仅仅被屏蔽了30．6μs，剩下的959．4μs时间里，所有的中断屏蔽都被开启。可见，将一句简单的Uart_Printf(“real—time test＼n”)移到中断下半部执行就能够节省939．4μs的中断屏蔽时间。
3．4 测试结果分析
    通过以上的测试结果可以看出：中断下半部为μC／0S-II内核带来的负担极小，一次完整的中断上／下半部处理时间延长了约20μs，而关中断时间增加了约14．1μs；通过测试一个简单而普遍的中断服务应用，并采用中断下半部实现，缩短了中断关闭时间约939．4μs，这相当于94．9％的中断响应的总耗时。如果粗略地以中断屏蔽时间来衡量系统的实时性，这个测试中，使用中断下半部将实时性提高了约32倍。若对更加复杂的中断服务程序使用这种机制来进行设计，则实时性的提高将更为显著。因此，采用中断下半部将极大地缩短中断服务处理中屏蔽中断的时间，这对于实时系统的意义不言而喻。

结 语
    中断上／下半部的层次化处理机制为开发者提供了一种灵活、便捷的中断服务程序的设计方法。通过合理利用中断下半部，中断上半部的执行时间将明显缩短，中断被屏蔽的时间也会大大减少，处理器可以更快地响应中断，从而将大大减小丢失中断信号的可能性。
    本设计实现了基于μC／OS-II的中断下半部。这种机制的实现充分利用了μC／0S—II的现有资源，代码简洁而高效，且与平台相关性代码极少，方便移植。一组功能定义明确的API极大地方便了开发者使用这种机制。通过在ARM7处理器上的测试表明，这种机制极大地改良了原μC／OS—II内核简陋的中断处理方式，给μC／OS—II内核带来的负担极小，却能为使用μC／OS—II的开发者带来极大的益处，对于嵌入式系统整体实时性的提高具有重要意义。