Edge vs Level sensitive interrupts

Edge Triggered Vs Level Triggered interrupts

Level triggered: as long as the IRQ line is asserted, you get an interrupt request. When you serve the interrupt and return, if the IRQ line is still asserted, you get the interrupt again immediately.

Edge triggered: You get an interrupt when the line changes from inactive to active state, but only once. To get a new request, the line must go back to inactive and then to active again.

Level triggered interrupt is like a baby. If the baby cries, you have to abandon whatever you are doing and feed the baby. You put her down. If she's still crying, you need to attend her immediately again. As long as she's crying, you serve her needs. You can get back to your work only when she's quiet. If you are in the garden (interrupt disabled) when she starts to cry, then when you get into the house (enable interrupts) the first thing you will do is to see her. However, if she starts crying while you're in the garden but goes back to sleep before you get back to the house, you will not even know about this incident.

Edge trigger is like a baby cry monitor for deaf parents. The monitor has a red light which comes on when the baby starts to cry (i.e. there is sudden increase in the sound level in the room) and remains lit until you press a button on the device. If the baby starts to cry but stops it quicky, you will still see that she cried, even if you were in the garden while that happened. However, if she starts crying, the light comes on (interrupt request), then you press the button (interrupt acknowledge), the light will remain dark even if she keeps crying. The sound level in the room must drop then increase again for the light to come on.

Level triggered interrupt is an indication that a device needs attention. As long as it needs attention, the line is asserted. Edge triggered interrupt is an event notification. When some particular thing happens, the device generates an active edge on the interrupt line.

Good description, Zoltan. Normally you use edge-triggered interrupts to ensure that you get an interrupt when a transitory event occurs and a level-sensitive interrupt when you are detecting a persistent event. The most certain way to avoid missing interrupts is to latch the interrupt request at the source and use level-sensitive interrupts (make sure that you clear the latch in the interrupt handler!). I learned this the hard way writing a windows 98 driver for a PCMCIA card. It turns out that windows 98 can (and sometimes does) "lose" edge-triggered interrupts.

I liked the crying baby illustration so -
level triggered = state
edge triggered = event

One thing frequently overlooked from system design perspective (yes, blame hardware guys ;) is that level type interrupt requires feedback to the interrupt source in order to reset it (I/O line, UART, SPI - you name it) while edge-triggered one doesn't need it. On the other hand less-than-perfect hardware may generate a glitch due to noise or racing conditions that may get edge-triggered interrupt falsely asserted.

level trigger interrupt means the interrupt will be in active mode for the duration of the signal and coming to the edge triggering, it will be activated just like switch(respond at positive or negative edge).

Edge trigger could also be compared to a discrete bell left in front of some desk with a chair on which seat an invisible employee. One tap is enough to see the exhausted employee appear and start helping you. Many angry taps may work if the employee is just chatting with coworker and try to ignore you.
The level triggered interrupt is a brutal way to force somebody to pay attention to your request. It could be compared to a funnel that you fill with water until you get the answer that you want to hear.

Like if life was not hard enough for Embedded software experts to get this LED blink, the level interrupt have tendency to slow the main application to a near dead crawl. The JTAG tools that I used all fails to indicate that an interrupt is triggered again and again, letting only one assembler intruction to be executed between each cycle. Likewise, all JTAG tools that I ever used fail to tell me when the processor RESET either because of watchdog expiration or either the code may perform the RESET.

Brief, do you want bad information, slowly or good information in a blink of a robot eye ?

 With level triggered interrupts, you can have multiple devices all sharing the same line. In HW terms this is traditionally done using "open collector" outputs which can drive a signal low, but requires a pullup resistor to pull the line high.

With level triggered interupts, the interrupt handler has to poll each of the devices which are sharing the interrupt line to determine which device actually caused the interrupt.

With edge triggered interrupts, you normally only have one device per interrupt line, although I remember that the PC had some scheme which allowed sharing, but it required extra HW for each interrupt source.

 I have minor disagreement with Zoltan's explanation. In case of the edge trigger interrupt the red light will be on only if the Interrupt Service Routine will latch the state of the interrupt. In case of both interrupts the system shall drop everything and attend to the condition in ISR, unless the system is busy servicing other interrupt with higher priority. In this case the low priority trigger interrupt can be lost. That was probably the problem in Colin's case of Windows 98. The big difference is what happens after the interrupt is serviced. If level interrupt was not cleared, it will not let go and the system will be sitting in ISR. In level trigger systems it is virtually impossible to lose interrupts, but you need to take care clearing them. The edge trigger is preferable in simpler systems with many short interrupt events, when the ISR is pretty much only registers them with flag or something. In systems with multi-layer priority interrupts with more complex ISRs I prefer level interrupts.

Credit - http://venkateshabbarapu.blogspot.in/2013/03/edge-triggered-vs-level-triggered.html

No comments:

Post a Comment