Hi, I have a peripheral that has an active high interrupt output that is asserted when it needs attention. The driver for this peripheral when servicing this peripheral needs to clear the interrupt in the peripheral and in turn the peripheral deasserts the interrupt line. It seems like for this situation I could configure the interrupt controller in my SoC to detect this interrupt as either a rising edge triggered interrupt or an active high level triggered interrupt. Is that true or am I missing something here? Also, what is the difference between an edge triggered interrupt and a pulse interrupt? Thanks.
Interrupt type: edge, pulse, level
Started by ●November 16, 2015
Reply by ●November 16, 20152015-11-16
On 16.11.15 12:15, JLocke wrote:> Hi, > > I have a peripheral that has an active high interrupt output that is asserted when it needs attention. The driver for this peripheral when servicing this peripheral needs to clear the interrupt in the peripheral and in turn the peripheral deasserts the interrupt line. It seems like for this situation I could configure the interrupt controller in my SoC to detect this interrupt as either a rising edge triggered interrupt or an active high level triggered interrupt. Is that true or am I missing something here? > > Also, what is the difference between an edge triggered interrupt and a pulse interrupt? > > Thanks.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 by ●November 16, 20152015-11-16
On 11/16/15 6:27 AM, Tauno Voipio wrote:> On 16.11.15 12:15, JLocke wrote: >> Hi, >> >> I have a peripheral that has an active high interrupt output that is >> asserted when it needs attention. The driver for this peripheral when >> servicing this peripheral needs to clear the interrupt in the >> peripheral and in turn the peripheral deasserts the interrupt line. It >> seems like for this situation I could configure the interrupt >> controller in my SoC to detect this interrupt as either a rising edge >> triggered interrupt or an active high level triggered interrupt. Is >> that true or am I missing something here? >> >> Also, what is the difference between an edge triggered interrupt and a >> pulse interrupt? >> >> Thanks. > > > 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. >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 by ●November 16, 20152015-11-16
Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote: (snip)> 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.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 by ●November 16, 20152015-11-16
On Monday, November 16, 2015 at 3:27:48 AM UTC-8, Tauno Voipio wrote:> On 16.11.15 12:15, JLocke wrote: > > Hi, > > > > I have a peripheral that has an active high interrupt output that is asserted when it needs attention. The driver for this peripheral when servicing this peripheral needs to clear the interrupt in the peripheral and in turn the peripheral deasserts the interrupt line. It seems like for this situation I could configure the interrupt controller in my SoC to detect this interrupt as either a rising edge triggered interrupt or an active high level triggered interrupt. Is that true or am I missing something here? > > > > Also, what is the difference between an edge triggered interrupt and a pulse interrupt? > > > > Thanks. > > > For proper two-line handshake, configure the interrupt > level-sensitive. The interrupt will stay active until > the software resets it in the handler.What do you mean by 'two-line handshake'? Also, regardless of whether I configure the interrupt controller to treat this interrupt as rising-edge triggered or level triggered the interrupt will still stay active until my interrupt handler clears the interrupt in the device generating the interrupt, right? The device I'm dealing with doesn't deassert the interrupt line until I write to a register in the device to clear it. <snip> Thanks.
Reply by ●November 16, 20152015-11-16
On Monday, November 16, 2015 at 5:45:11 AM UTC-8, Richard Damon wrote:> On 11/16/15 6:27 AM, Tauno Voipio wrote: > > On 16.11.15 12:15, JLocke wrote: > >> Hi, > >> > >> I have a peripheral that has an active high interrupt output that is > >> asserted when it needs attention. The driver for this peripheral when > >> servicing this peripheral needs to clear the interrupt in the > >> peripheral and in turn the peripheral deasserts the interrupt line. It > >> seems like for this situation I could configure the interrupt > >> controller in my SoC to detect this interrupt as either a rising edge > >> triggered interrupt or an active high level triggered interrupt. Is > >> that true or am I missing something here? > >> > >> Also, what is the difference between an edge triggered interrupt and a > >> pulse interrupt? > >> > >> Thanks. > > > > > > 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. > > > > 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).Is the pulse or edge nature of the interrupt dependent on the device generating the interrupt, i.e. whether it asserts the interrupt line and then deasserts 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 generating device achieve?
Reply by ●November 16, 20152015-11-16
On 16.11.15 20:00, jlockefree@gmail.com wrote:> On Monday, November 16, 2015 at 3:27:48 AM UTC-8, Tauno Voipio wrote: >> On 16.11.15 12:15, JLocke wrote: >>> Hi, >>> >>> I have a peripheral that has an active high interrupt output that is asserted when it needs attention. The driver for this peripheral when servicing this peripheral needs to clear the interrupt in the peripheral and in turn the peripheral deasserts the interrupt line. It seems like for this situation I could configure the interrupt controller in my SoC to detect this interrupt as either a rising edge triggered interrupt or an active high level triggered interrupt. Is that true or am I missing something here? >>> >>> Also, what is the difference between an edge triggered interrupt and a pulse interrupt? >>> >>> Thanks. >> >> >> For proper two-line handshake, configure the interrupt >> level-sensitive. The interrupt will stay active until >> the software resets it in the handler. > > What do you mean by 'two-line handshake'? Also, regardless of whether I configure the interrupt controller to treat this interrupt as rising-edge triggered or level triggered the interrupt will still stay active until my interrupt handler clears the interrupt in the device generating the interrupt, right? The device I'm dealing with doesn't deassert the interrupt line until I write to a register in the device to clear it. > > <snip> > > Thanks.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 4. The printer catches the data 5. The printer activates the busy line 6. The computer deactivates the strobe line 7. 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 by ●November 16, 20152015-11-16
On 16.11.2015 г. 20:05, jlockefree@gmail.com wrote:> On Monday, November 16, 2015 at 5:45:11 AM UTC-8, Richard Damon wrote: >> On 11/16/15 6:27 AM, Tauno Voipio wrote: >>> On 16.11.15 12:15, JLocke wrote: >>>> Hi, >>>> >>>> I have a peripheral that has an active high interrupt output that is >>>> asserted when it needs attention. The driver for this peripheral when >>>> servicing this peripheral needs to clear the interrupt in the >>>> peripheral and in turn the peripheral deasserts the interrupt line. It >>>> seems like for this situation I could configure the interrupt >>>> controller in my SoC to detect this interrupt as either a rising edge >>>> triggered interrupt or an active high level triggered interrupt. Is >>>> that true or am I missing something here? >>>> >>>> Also, what is the difference between an edge triggered interrupt and a >>>> pulse interrupt? >>>> >>>> Thanks. >>> >>> >>> 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. >>> >> >> 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). > > Is the pulse or edge nature of the interrupt dependent on the device > generating the interrupt, i.e. whether it asserts the interrupt line and > then deasserts 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 generating device achieve?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 http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●November 16, 20152015-11-16
On Mon, 16 Nov 2015 10:00:45 -0800, jlockefree wrote:> On Monday, November 16, 2015 at 3:27:48 AM UTC-8, Tauno Voipio wrote: >> On 16.11.15 12:15, JLocke wrote: >> > Hi, >> > >> > I have a peripheral that has an active high interrupt output that is >> > asserted when it needs attention. The driver for this peripheral when >> > servicing this peripheral needs to clear the interrupt in the >> > peripheral and in turn the peripheral deasserts the interrupt line. >> > It seems like for this situation I could configure the interrupt >> > controller in my SoC to detect this interrupt as either a rising edge >> > triggered interrupt or an active high level triggered interrupt. Is >> > that true or am I missing something here? >> > >> > Also, what is the difference between an edge triggered interrupt and >> > a pulse interrupt? >> > >> > Thanks. >> >> >> For proper two-line handshake, configure the interrupt level-sensitive. >> The interrupt will stay active until the software resets it in the >> handler. > > What do you mean by 'two-line handshake'? Also, regardless of whether I > configure the interrupt controller to treat this interrupt as > rising-edge triggered or level triggered the interrupt will still stay > active until my interrupt handler clears the interrupt in the device > generating the interrupt, right? The device I'm dealing with doesn't > deassert the interrupt line until I write to a register in the device to > clear it.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 http://www.wescottdesign.com
Reply by ●November 16, 20152015-11-16
On Mon, 16 Nov 2015 02:15:59 -0800, JLocke wrote:> Hi, > > I have a peripheral that has an active high interrupt output that is > asserted when it needs attention. The driver for this peripheral when > servicing this peripheral needs to clear the interrupt in the peripheral > and in turn the peripheral deasserts the interrupt line. It seems like > for this situation I could configure the interrupt controller in my SoC > to detect this interrupt as either a rising edge triggered interrupt or > an active high level triggered interrupt. Is that true or am I missing > something here? > > Also, what is the difference between an edge triggered interrupt and a > pulse interrupt?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 http://www.wescottdesign.com
