QNX驱动开发——中断处理
在操作系统中，对于中断的处理一直是一件麻烦事，其实主要是对操作系统的中断管理机制不熟悉。当中断产生时，内核去执行中断服务程序ISR，中断服务程序中要做尽量少的工作，以提高系统执行效率，有些人在中断服务程序中使用延时函数和printf函数和malloc函数，其实是很不可取的。延时函数不仅大大降低了中断执行的效率，也可能会屏蔽下次中断的产生，从而丢失对中断的响应。对于printf函数为什么不行呢？可以从输出原理上进行解释。通过调用Printf函数，将字符串输出到console的时候要调用到串口，这里涉及到身躯信号量以及阻塞操作，会加大中断服务程序的执行时间；malloc是不可重入函数，如果在其还没返回就再对其调用将出现灾难性后果。为了尽量减少中断服务程序执行的时间，减小调度等待时间，那么在操作系统中ISR最好的实现方式就是，发生中断时，设置标志，构造一个尽量简短的ISR，其他工作单独创建相应的线程去执行。就好比有人给你打电话，当你突然接到任务指示时是一边听电话一边花大量时间做完，还是挂掉电话再去做具体的任务呢？当然是后者了，可是大部分人还是选择把所有的事情都放在中断服务程序中去处理，其实是很不科学的。
当硬件产生中断后，会一直将中断线拉高，直到ISR清中断。然而如果中断服务程序忘记清除中断标志，那么当中断程序执行完时，PIC又会因检测到中断而重复执行，这样就出问题了！所以好的方法就是一进入中断程序就先清除中断标志。
那么在QNX中如何写一个中断呢？QNX提供了两种连接中断的方法：
Int InterruptAttachEvent (int intr, const struct sigevent *event, unsigned flags);
Int InterruptAttach (int intr, const struct sigevent * (*handler) (void *arg, int id), const void *area, int size, unsigned flags);
其中int intr代表了中断向量号，在startup中初始化PIC的时候按照数据手册写进去的，代表了哪个中断发生时会执行相应的ISR。
首先看看第一个函数，InterruptAttachEvent，这个函数告诉系统在硬件发生中断时要返回一个event来指出由哪个线程去执行具体任务，当然在这个线程中要先屏蔽这个中断源以免在任务还没处理完的时候再次发生中断。当调用这个函数的时候与查询的机制类似，其主干如下所示：
struct sigevent event;
intId = InterruptAttachEvent (HW_SERIAL_IRQ, &event, 0);
thread_a()
{
for(;;){
InterruptWait (0, NULL);
InterruptUnmask (HW_SERIAL_IRQ, intId);//get next event
ClearInterruptStatus();
Dosth();
}
}
当中断发生时，InterruptWait都会捕获到event，再针对不同的任务进行相应的处理。可是对于上边提到的主干程序，可能会有所疑问，为什么刚发现中断就去打开中断屏蔽呢，而不是等中断之行完再说呢？考虑到如果一个硬件产生的速度比较快，那么我们先处理在打开中断屏蔽就有可能对丢失对中断的处理。这里边InterruptWait可以将所有收到的event排成队列，对于不及时处理的中断请求稍后再做处理，这就很好的解决了上述问题。
再看第二个函数，InterruptAttach，这个函数在发生中断时直接调用了handler这个中断处理函数，是真正的ISR，在函数中使用的全局变量要使用volatile关键字修饰，告诉编译器这是一个会在中断中和其他线程中改变的变量，对其的一切操作都要去源地址进行读取，否则会出现错误。这个函数为什么要返回一个event呢，因为这样可以唤醒相应的线程去做具体的事情。
那么对于这两个函数哪个更好一点呢？显然每个函数都有自己的优缺点，视具体情况而定。InterruptAttachEvent()，用法简单，运行在用户空间，可以激发单独的线程去处理特定的任务，可是虽然好用，每当中断时都会引起上下文切换，降低了效率。对于InterruptAttach()，因为是ISR将原线程中断，产不产生新的进程由ISR决定，所以对于不是自己要处理的中断，可以减少上下文切换的开支。