eCos和μC/OS-II的中断处理比较 （一）

本文原创转载请注明出处  http://blog.csdn.net/rickleaf  

1.中断上下文切换

μC/OS-II

μC/OS-II 中断没有独立的堆栈，响应中断的时候需要通过线程的堆栈空间来保存现场。

eCos

嵌套中断是这种机制可能在处理中断的时候开始另一个中断。当处理这个新的中断时，被中断的状态信息将会存放在堆栈上。被中断的状态信息的数量依赖于具体的CPU结构，有时候数量很多。这意味着堆栈空间应当足够大能够存放“N”个中断框架（被中断的状态信息）。对于有很多线程的实时系统来说，这是一个不能容忍的局面。为了解决这个问题，在处理中断时，eCos应用了一个独立的中断栈。这个栈需要足够大能够存放“N”个中断框架（被中断的状态信息），而每个线程堆栈只需单个中断状态的开销。这是因为线程状态被保存在自己的堆栈上，包括导致这个线程被调度的中断的状态信息。这是一个好得多的结局，既然只有这个中断栈需要足够大以处理潜在的中断服务需求。

eCos允许中断栈完全地可配置。用户可以选择不使用这个独立的中断栈，通过禁止CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK来完成。这需要所有的线程堆栈足够大，但是在中断处理时，这省去了切换栈的开销。如果内存很紧张，每次处理中断时以几个机器周期（cycle）为代价，选择一个独立的中断栈是比较明智的。

2.中断处理过程

μC/OS-II

μC/OS-II 中，中断服务子程序需要用汇编来写，当然有时候我们可以在C语言中用潜入汇编的方式来做。

为了系统知道目前做的是中断服务程序还需要

OSIntEnter()和OSIntExit()标记中断处理的开始和结束。

为了减少锁调度器的时间，可以在中断服务程序中调用OSMboxPost()，OSQPost()，OSQPostFront()，OSSemPost()

来唤醒一个线程处中断以后要做的事情，让中断服务程序尽快的结束恢复系统的调度器。

eCos

eCos中有相对完备的中断管理函数，用户可以通过如下等函数对中断类型和中断处理函数进行创建和更改。

cyg_interrupt_create

cyg_interrupt_detlete

cyg_interrupt_attach

cyg_interrupt_detach

cyg_interrupt_configure

eCos把中断划分为两个部分ISR和DSR，在创建中断的时候需要指定对应的函数指针。

ISR中处理必须关中断的部分，DSR作为中断的延后处理可以在系统调度开启的时候进行，并且DSR可以用很多的线程同步函数

完成更复杂的功能。

3.中断嵌套

μC/OS-II支持中断嵌套，

eCos需要在配置CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING来开启中断嵌套的支持。

4.总结

μC/OS-II和eCos关于中断处理的部分，eCos有更加丰富的API可以应用，但是DSR和ISR的机制也增加了中断处理的复杂性。

在CPU资源相同的情况下，如果开启中断嵌套，分配独立的堆栈空间的eCos可能会节省部分内存。