关于中断架构在raw os 中的设计

jorya_txj

关于中断架构在raw os 中的设计 [复制链接]

由于中断在系统中的特殊作用，历来被os设计者一直所看重。raw os 系统内核最大关中断时间在S3c2440平台上实测为8.2us, 虽然不是皎皎冠军，但是也不至于落到最后。

本人一直认为整个应用系统的最大瓶颈是在中断的驱动架构这里，只要抓好这个整体，系统的最大关中断时间是可以控制在10 us以下的。落眼于系统设计的架构，抓住事物内部的主要矛盾，从宏观角度处理问题比微观更为直接有效。

为了设计raw os 的中断架构，首先要对中断的紧迫性和中断处理的时间做好划分。一般认为越快的中断，意味着时间越短，紧迫性越高。比如高速的gpio 中断可以很快。像串口这样的中断是很慢的。其次必须认识清楚发生中断后，中断处理需要的时间是多长，时间长的和时间短的处理方式不同。

整体来说在raw  os中总共有3种设计的方法：

第一种假如中断处理的时间很短，这样的话直接可以在中断里面完成，这个是很容易理解的，和传统的操作方式是一样的。但是前提是中断处理的时间一定要足够短和足够快。

第二种是中断处理的时间长，但是时间紧迫性不高，这样的话可以采用protothread的方式去解决这个问题。Protothread 是跑在raw os 的idle 任务中的，优先级是最低的。 而且采用的是事件处理的方式，整个中断处理过程是不需要关中断的。

第三种是中断处理时间长，紧迫性也高。这个时候可以开一个最高优先级的任务，比如优先级为0的任务。 优先级为0的任务处于queue 的阻塞接收中，接收的信息是中断号， 硬件中断来了之后发中断号消息给这个任务，同时清除interrupt pending 位，然后退出自动运行该任务。备注：紧迫性更高的中断可以甚至发消息到头部，直接插队^_^.

大概流程如下：

Isr()

{

       发送中断号给最高优先级任务(0)

       清除自身的中断pend 位

}

Hightest_priority_task()

{

       While (1) {

              接收消息队列中的数据，即中断号。（无消息则阻塞queue）

              根据中断号处理相应中断。

    }

}

以上Hightest_priority_task 中断是始终打开的。

总结，通过以上的设计后，系统驱动最大的关中断时间可以达到最小，而且是最自然的处理中断方式，对于芯片公司提供的驱动可以不需要任何修改，直接可以上面使用，只要遵循以上的设计架构。