uCOS-II中断底半部机制.docVIP

uC/OS-Ⅱ中断底半部机制的设计与实现 uC/OS-Ⅱ是一个小型的嵌入式实时操作系统，支持基于优先级的抢先调度，结构精巧，可靠稳定，易学易用且源代码开放，在许多场合得到了广泛应用，已被先后移植到了40多种不同架构的CPU上。 众所周知，不管中断服务程序执行期间系统中断是否被屏蔽，系统中断服务程序不可过长。若在一个长中断执行的过程中，系统中断被屏蔽，则必会使大量异步事件被忽略，导致系统响应缓慢，使系统出现重大漏洞。若是在长中断服务程序中不屏蔽中断，此时会产生中断的多重嵌套，而中断没有独立上下文，它占用被中断的进程的堆栈，这要求系统每个进程的栈相当大，以便满足中断嵌套对存储空间的需求，这在嵌入式系统中显然是不允许的。这就要求中断服务程序尽可能短，只做必要的、紧急的工作。为此Linux等操作系统中，提供了中断底半部机制【2】【3】，所谓中断底半部是因与中断密切相关而得名，中断底半部程序做的事情就是中断中该做而未做的那部分不紧急的事情。 遗憾的是uC/OS-Ⅱ并没有像Linux那样提供中断底半部机制，大量的任务都要留给中断来做，这种设计方案应用于大型的、存在大量异步事件的嵌入式系统，是很危险的。鉴于此本文提出了一种针对uC/OS-Ⅱ系统的中断底半部机制的解决方案，实现了uC/OS-Ⅱ的中断底半部机制，扩展了uC/OS-Ⅱ的内核，实现了一个与内核本身提供的信号量，消息邮箱等同等层次的内核机制，设计了专用的中断底半部进程和对应的新的中断服务程序的实现方法，该解决方案同时支持有优先级的中断底半部静态触发和无优先级的动态注册。 底半部机制设计与实现 中断底半部机制本质上要求被推后执行的底半部任务在一个用户态进程的级别上运行，即它可以被中断，并且有这样的运行机制：在没有等待处理的底半部任务时，将自身挂起并触发进程调度，有了等待处理的底半部任务时该进程被唤醒。内核中已存在的结构不能满足这些要求，为此我实现了融入内核的BH辅助机制，我们称其为BH_Core，该部分有两个函数组成，第一个是bh_pend，第二个bh_post，其命名遵循了uC/OS-Ⅱ的习惯。 bh_pend的流程如图1所示，函数开始先检测是否是在中断服务程序中被调用，uC/OS-Ⅱ不允许在中断服务程序中作进程切换，而该函数可能引起进程切换所以不能在中断函数中被调用。uC/OS-Ⅱ的调度器可以被锁而不能触发调度，这种情况下这个函数也不应该被调用，第二步的检查就是出于这个目的。接下来判断如果有注册的等待处理的底半部任务，则该函数正常返回，那么调用该函数的进程便可依据底半部的申请而处理各底半部任务了。如果没有要处理的任务，则将当前进程挂起，此时一定要将当前进程设为OS_STAT_SUSPEND状态，这是由uC/OS-Ⅱ的时钟服务函数OSTimeTick 【1】的实现决定的，执行底半部服务的进程只有在有要处理的底半部任务时才运行，否则一直挂起，它没有挂起时限，而除非进程处于OS_STAT_SUSPEND态，否则早晚会被OSTimeTick 置为就绪态,因此底半部服务进程只能挂起为OS_STAT_SUSPEND状态。触发进程调度即调用内核函数OS_Sched ,它会保存当前进程的上下文，并将处于就绪态的优先级最高的进程投入运行。当OS_Sched 函数返回时，只有一种可能那就是有要处理的底半部任务（前面已经说过不可能是挂起超时），所以该函数也是正常返回。 bh_post的流程如图2所示。在说明其流程之前先说明一下为实现底半部机制而引入的特殊数据结构，一个是BH_struct，它的两个关键字段是： mask和taskletCnt。设计中考虑到多个底半部申请同时产生时，必须要有优先 图1 bh_pend流程图 级的区分，这个优先级是静态的，目前的实现只是给定时器、网络发送和网络接收这几个对时间要求严格的底半部任务分配了优先级，其优先级由mask字段中的相应位标识，当这些底半部服务申请产生时，mask的相应位被置位，这些任务便被触发并依优先级被顺序处理。另外，mask中还有一个TASKLET_BH标志，这个标志标识有其它类型 图2 bh_post流程图 的底半部服务申请，由于这些申请种类多样，而且也不像前几种服务请求那样急迫，这里用统一的无优先级机制来处理它们（确切说是先来先服务机制）。为此引入tasklet_t数据结构，它有两个字段：func和data，func是一个函数指针，而data是该func指向的函数的参数，为支持任意类型参数，data是void *类型。考虑到一般嵌入式系统，在一个较小的时间段内，产生的底半部申请不会超过32个，定义数组tasklet_t g_taskletArray[32]来存放所有申请,这样每次有这种申请时，一方面mask的TASKLET_BH位被置位，