Interrupt type: edge, pulse, level

Hi,

I have a peripheral that has an active high interrupt output that is assert ed when it needs attention. The driver for this peripheral when servicing t his peripheral needs to clear the interrupt in the peripheral and in turn t he peripheral deasserts the interrupt line. It seems like for this situatio n I could configure the interrupt controller in my SoC to detect this inter rupt as either a rising edge triggered interrupt or an active high level tr iggered interrupt. Is that true or am I missing something here?

Also, what is the difference between an edge triggered interrupt and a puls e interrupt?

Thanks.

Reply to
JLocke
Loading thread data ...

For proper two-line handshake, configure the interrupt level-sensitive. The interrupt will stay active until the software resets it in the handler.

Edge-triggered and pulse are two names for essentially the same way of handling an interrupt only on signal level change.

The original IBM PC had to program the 8259A interrupt controller edge-triggered to prevent looping interrupt requests from the 18 Hz timer, as the hardware designer had saved a latch which could reset the interrupt when seen by the code. This provided plenty of problems for later device and driver designers.

--

-TV
Reply to
Tauno Voipio

What is sometimes the difference between edge and pulse sensitive interrupts is that a pulse sensitive interrupt will be asserted on the edge of the pulse, and continue to be asserted even if the pulse goes away, until it is handled, while some edge sensitive interrupts will deassert themselves if the interrupt line goes away even if the interrupt has not been processed. (Not all interrupts described as edge sensitive will work this way, some will work as I described pulse sensitive, as there is no formal standard for this terminology).

Reply to
Richard Damon

(snip)

I always knew that it used edge triggered, but didn't know why.

Level triggered, with open collector active low drivers, allows for shared interrupts on the bus. After clearing one, the interrupt for the next one will still be there.

-- glen

Reply to
glen herrmannsfeldt

serted when it needs attention. The driver for this peripheral when servici ng this peripheral needs to clear the interrupt in the peripheral and in tu rn the peripheral deasserts the interrupt line. It seems like for this situ ation I could configure the interrupt controller in my SoC to detect this i nterrupt as either a rising edge triggered interrupt or an active high leve l triggered interrupt. Is that true or am I missing something here?

pulse interrupt?

What do you mean by 'two-line handshake'? Also, regardless of whether I con figure the interrupt controller to treat this interrupt as rising-edge trig gered or level triggered the interrupt will still stay active until my inte rrupt handler clears the interrupt in the device generating the interrupt, right? The device I'm dealing with doesn't deassert the interrupt line unti l I write to a register in the device to clear it.

Thanks.

Reply to
jlockefree

Is the pulse or edge nature of the interrupt dependent on the device genera ting the interrupt, i.e. whether it asserts the interrupt line and then dea sserts it immediately or whether it keeps the interrupt line asserted until the software acknowledges/clears it? Or is the pulse or edge nature of the interrupt related to how an interrupt controller treats edges on interrupt lines? Are there devices that actually just send a pulse as an interrupt? If so, what affect would clearing/acknowledging the interrupt in the genera ting device achieve?

Reply to
jlockefree

The original two-line handshake is from decades ago: It is the way a peripheral and a computer can synchronize the data transfer reliably. As an example, a parallel-connected printer has two control (handshake) lines, busy from the printer and strobe from the computer. The handshake goes:

  1. When the computer has new data to send, it checks the busy line and waits until busy is inactive
  2. The computer puts data on the data lines (separate from the handshake lines)
  3. The computer activates the strobe line

  1. The printer catches the data

  2. The printer activates the busy line

  1. The computer deactivates the strobe line

  2. The printer deactivates the busy line when it is ready for the next transfer.

This sequence guarantees that both ends of the transfer always know from the state of handshake lines which of them is supposed to act next.

Here, the interrupt line is one handshake line and the interrupt acknowledge / reset is the other handshake line.

--

-TV
Reply to
Tauno Voipio

Generally yes, edge sensitive is for cases where the device which generates the interrupt is less sophisticated and does not necessarily know it is generating an interrupt (e.g. the output of some counter). MCU-s have their inputs prepared for that as it is often the case; a few decades ago there were peripheral chips which would have the edge sensitive inputs and would interrupt the processor via its level (only) sensitive input(s), expect the processor to clear that interrupt etc, apparently you know how this works. If your device which generates the interrupt is "level IRQ aware", i.e. the processor can access something inside it to clear the IRQ, the correct way to do this would be to use level sensitive IRQ, this is how it seems to be meant to be used.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

If the controller is truly acting as an edge-triggered device it ignores the level of the interrupt line coming in -- so the device that originates the interrupt may be asserting an interrupt, but the controller won't respond until the interrupt is deasserted and reasserted.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Level-triggered interrupt: if the interrupt line into the controller is active, then when you return from the ISR you immediately get another interrupt. The onus is on the ISR to make the interrupting hardware deassert it's interrupt.

Edge-triggered interrupt: if the interrupt line into the controller transitions from inactive to active (which may be low-high or high-low, depending), then the interrupt controller will interrupt as soon as it can, regardless of the state of the interrupt line. If the interrupt line _does not_ go inactive, then the interrupt _will not_ happen again.

Pulse-triggered interrupt: I haven't heard that term so I dunno. I do know that the ARM NVIC calls itself "edge triggered", but will immediately interrupt again if the line is active. Perhaps "pulse triggered" is the better terminology for that behavior -- again, I dunno.

One difficulty with level-triggered interrupt schemes is that you need to be able to tell the interrupt source to turn off. Sometimes the hardware isn't smart enough to do this. Another difficulty with level-triggered interrupt schemes is that if you're in _any_ ISR and the interrupt source deasserts then the controller won't interrupt.

The difficulty with edge-triggered interrupt schemes is that unless the interrupt controller hardware is done correctly and you're careful using it, you can have a race condition that results in the interrupt being -- quite validly -- raised at the source, but ignored by the controller. This generally happens when some event happens when you're in the ISR messing with the controller state -- at best, there's a window of opportunity for a problem that can be closed in software. At worst, the window of opportunity exists in hardware, and can't be closed in software.

Such race conditions are less likely now with fancy-dancy microcontrollers (because the designers want the customer to be successful), but if there's an FPGA or other custom logic in the mix it's a good idea to have lots of design review early surrounding the interrupt mechanisms.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.