http://blog.csdn.net/chychc/article/details/8313458
eCos中断模型(1)ISR和DSR
英文全称 Interrupt Service Routine
中断处理是实时操作系统一个重要部分。及时地处理中断源是很重要的，但一些必须被视为原子操作(不能被中断)的动作对保证及时性带来了十分严重的影响。因
为执行这些动作时，都要disable中断。为了最大限度地减少这种动作，确保最可能少的中断延迟，eCos使用了一种分割式中断处理机制，在这种机制
中，中断处理被分为两部分。第一部分是大家都知道的中断服务例程(ISR)，第二部分是延迟服务例程(DSR)。明显地，这种分割允许中断被
enabled的情形下运行DSRs，因此在处理较低优先级的中断时，允许别的潜在的更高优先级的中断发生和处理。
为了使这种中断模型能够工作起来，ISR应当快速运行。如果中断引起的服务量少，ISR可以单独处理这个中断而不需要DSR。当然，如果中断服务比较复
杂，DSR就派上了用场。将会在稍后合适的时间执行这个DSR，在这个时候允许进行线程调度。推迟到这个时候运行DSRs使得kernel可以使用简单的
同步方式。
此外，这种受控的调用方式—当允许进行线程调度的时侯--意味着DSR可以和内核打交道，比如向内核发出信号：一个异步操作结束了。
为了可以在中断被enabled的情形下运行DSRs，对应于特定中断源(或硬件)的ISR必须作出安排保证这个中断不会再次发生，直到DSR结束。在有
的情况下，硬件完成这个动作：一旦一个中断被递送出去，别的中断将不会发生，除非中断被重新enabled。但是，一般情况下，是ISR来强迫这个行为的
发生。ISR将会屏蔽掉这个中断源，防止了再次产生中断。只有当DSR执行结束时，这个DSR将会unmask这个中断，这样如果新的中断再次发生了，允
许递送这个中断。
另外，如果每次中断时ISR要做的动作很少，比如传递内存上的一个字节到一个IO设备上，每一次“传递”结束时，它可能只需要与系统的其它部分打交道。在这种情况下，多次执行了ISR后，等到处理完这个缓冲区，这个ISR才真的需要请求执行它的DSR。
如果中断源是爆发性的，在执行一个被请求的DSR之前，可能产生了多个中断并且多次调用了这个ISR，这是正常的；内核记录下被posted的DSR的个
数。在这种情况下，这个DSR将会最终被调用，其中一个参数告诉它有多少个ISR请求执行这个DSR。编码时必须小心处理这种情形，因为一次对DSR的调
用需要完成好几次DSR的任务。
正如上面所说，这个DSR将会在稍后的时间得到执行。与系统的状态有关，它可能会在更迟的时间得到执行。执行一定的内核操作时，在某些时期内线程调度被禁
止，这使得不能执行DSR。eCos内核有意识地尽可能地限制了这些时期，尽管它们依然存在。另外，同时用户线程有能力挂起调度，因此影响了可能的DSR
执行延迟。如果不能足够快地执行一个DSR，这个中断源可能overrun。这应当视为系统失败。
eCos中断模型(2)用户栈和中断栈
系统设计者面临的一个问题是为每个线程应当分配多大的堆栈空间。eCos并没有指定线程堆栈的大小，它留给用户在创建线程的时候决定。堆栈的大小不但与线
程需求有关，也与一些固定的系统开销有关。这个系统开销是能够存放全部线程状态的足够的堆栈空间（它的实际数量与CPU结构有关）。抽象硬件层的
CYGNUM_HAL_STACK_SIZE_MINIMUM给出了所需的最小堆栈空间。
嵌套中断是这种机制潜在的一个问题。既然处理一个中断时它的DSR部分重新enable了中断，这样在处理DSR时，有可能来了一个新的中断
（hopefully来自别的中断源）。当处理这个新的中断时，被中断的状态信息将会存放在堆栈上。被中断的状态信息的数量依赖于具体的CPU结构，有时
候数量很多。这意味着堆栈空间应当足够大能够存放“N”个中断框架（被中断的状态信息）。对于有很多线程的实时系统来说，这是一个不能容忍的局面。为了解
决这个问题，在处理中断时，eCos应用了一个独立的中断栈。这个栈需要足够大能够存放“N”个中断框架（被中断的状态信息），而每个线程堆栈只需单个中
断状态的开销。这是因为线程状态被保存在自己的堆栈上，包括导致这个线程被调度的中断的状态信息。这是一个好得多的结局，既然只有这个中断栈需要足够大以
处理潜在的中断服务需求。
eCos允许中断栈完全地可配置。用户可以选择不使用这个独立的中断栈。这需要所有的线程堆栈足够大，但是在中断处理时，这省去了切换栈的开销。如果内存很紧张，每次处理中断时以几个机器周期（cycle）为代价，选择一个独立的中断栈应当是warranted(必要，值得)。
eCos中断模型(3)overrun问题
在mn10300模拟器上，观察到如下与中断有关的问题：当DSR重新enabled了中断，马上就来了下一个中断。既然一个中断被处理完到下一个中断出
现之前，不可能有任何（有意义的）处理，这种现象应当被视为一种中断overrun，系统完全饱和了。产生了问题是因为栈溢出。这是用户栈溢出，因为
DSR是在用户栈上执行的。对这个问题的分析导致重新修改了中断处理方式，尤其是进行中断处理时（ISR和DSR），对独立中断栈的使用。栈溢出依然会发
生，但这回它只限制在中断栈上。如果系统设计者事先知道overrun是有限的，例如以串口设备为例，它可能是一些FIFO的depth，他可以为此做出
相应调整给出适当大的中断栈。任何情况下，overrun必须避免，但使用中断栈使得这种failure可以很简单地检测出来。