|
- UID
- 872238
|
μ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具有可重入性， |
|
