0
\$\begingroup\$

I have read this answer.

My understanding is, there are actually 2 lines logically:

  • clock/gating line

  • event/interrupt line

And the clock/gating line can make the circuit take event input at an instant (edge triggering) or during a period (level-triggering).

So what if an event happens but the edge hasn't arrived yet.

Will that event be missed? Is that by intention?

ADD 1 - 12:21 PM 11/4/2022

I think my confusion lies in the 2 different meanings of triggering:

Meaning 1: Triggering a circuit. Like in the edge-triggered D flip-flop.

enter image description here

Meaning 2: An indication of the occurrence of an interrupt. Such indication can be in the form of a transient edge or by a long-lasting level.

There are 2 paradigms to indicate an interrupt event.

Paradigm 1: Indicated via an edge. The interrupt event signal is first latched. The latch is part of the microcontroller. The latch is necessary to avoid missing the transient interrupt event.

Paradigm 2: Indicated via a level. The latch is not necessary because the level is long-lasting. And the interrupt handler should service until the interrupt level disappears and then re-arm the interrupt, as @steve-mathwig said in his reply.

Btw, the 2 paradigms are the two very natural classification. And I think these are the only two paradigms.

Being edge-triggered interrupt doesn't necessarily mean the interrupt flag is cleared automatically. It can also require manual clearance. Depending on the hardware design.

But being level-triggered interrupt requires the service handler to service until the interrupt pin returns to the inactive level. And this implies "checking if there is more work to do before exit" and "re-arming the interrupt to be told when there is more work to do" as @simon-richter said.

Edge-triggered interrupt doesn't have a chance to withdraw its request. Because once it is latched by the microcontroller, the interrupt source can no longer control it.

Level-triggered interrupt can withdraw its request as long as it is not serviced yet. Such as when the microcontroller is busy processing a previous interrupt and disabled the interrupt. Such withdrawn interrupt will be silently missed. I think this must be the "blind-spot" as @simon-richter commented to his reply.

If another level-triggered interrupt happens just as the interrupt handler finished the handling and checks the interrupt pin for inactive-level, this may cause the "false positive" as @simon-richter commented. And I think this will cause the interrupt handler to repeat its handling.

If the handler for level-triggered interrupt doesn't service until the inactive-level appears, the handler will be invoked immediately after exiting. That's why the handler must ensure an inactive-level before exiting. Though it is not 100% accurate.

The edge-triggered interrupt may also have the blind-spot issue because the latch can only record one event even if there are multiple interrupt events happening while the handler is still busy executing or interrupt mechanism is disabled.

So the next natural question is, how to choose between edge-triggering or level-triggering paradigm for an interrupt?

I remember someone told me that edge-triggering is more vulnerable to the glitches while level-triggering is much more robust.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ When the interrupt is cleared to trigger again in software, what do you want to happen? \$\endgroup\$
    – DKNguyen
    Nov 1, 2022 at 14:47
  • 1
    \$\begingroup\$ there are actually 2 lines ... are you certain ... interrupt pins are usually not in pairs ... are you confusing an interrupt pin with a data pin? \$\endgroup\$
    – jsotola
    Nov 1, 2022 at 15:12

4 Answers 4

3
\$\begingroup\$

You don't need another gating clock. When the interrupt goes active, it gets latched internally by the microprocessor as an interrupt request. The microprocessor will then (based upon its own clock) process the interrupt if interrupts are enabled and is the highest priority interrupt pending. Some microprocessors automatically clear the interrupt request on entry to the interrupt handler, while others require the interrupt handler to explicitly clear the interrupt request. You will need to consult the documentation of your microprocessor (or, in some cases the documentation of an external interrupt controller) to determine what is required.

Take care if using level triggered interrupts, as they constantly generate an interrupt request until an inactive level is seen at the interrupt pin. Generally, the interrupt handler has to service the interrupting device to get the interrupt to its inactive level, then clear the interrupt request in order to prevent another interrupt from immediately occurring.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for your reply. Could you help check my ADD 1? \$\endgroup\$ Nov 4, 2022 at 7:23
  • 1
    \$\begingroup\$ I think you understand it now. I will only add that I prefer edge triggered interrupts over level triggered. A well-designed system doesn't suffer from "glitches". \$\endgroup\$ Nov 7, 2022 at 14:35
2
\$\begingroup\$

An edge triggered interrupt has a latch inside the CPU. This latch is set by a specific edge on the interrupt line, and reset by a control signal generated inside the CPU, typically automatically generated on entering the interrupt handler, or by poking the interrupt controller.

Also typically, the latch is not reset if the CPU mode disables interrupt processing, which means that an interrupt that was flagged once will be taken as soon as interrupts are reenabled.

In contrast, level triggered interrupts will remain active exactly as long as the peripheral generates them, so if interrupt processing is disabled on the CPU side, and the peripheral then drops the interrupt, the handler is not called when interrupts are reenabled.

This difference is mostly visible in the way acknowledges work -- the interrupt mechanism needs to be re-armed before the interrupt handler exits, so events flagged during handler exit aren't lost.

Both methods are initially asynchronous to the CPU clock, and are synchronized to it before it affects core state.

\$\endgroup\$
4
  • \$\begingroup\$ "events flagged during handler exit aren't lost." --- is it better to change the "during" to "before"? @simon-richter \$\endgroup\$ Nov 3, 2022 at 9:05
  • \$\begingroup\$ So for edge triggered interrupt, it is the latch that record the interrupt event and ensure it is not missed if the interrupt handler is still busy running or the interrupt processing is disabled. The interrupt event itself is always asynchronous to the CPU clock. But the latch makes it possible for cpu to process the event synchronously to its clock. \$\endgroup\$ Nov 3, 2022 at 9:29
  • 1
    \$\begingroup\$ @smwikipedia, the difficult bit is the ordering between "checking if there is more work to do before exit" and "re-arming the interrupt to be told when there is more work to do", and you get either a blind spot, or false positives, with the latter being preferable. \$\endgroup\$ Nov 3, 2022 at 15:12
  • 1
    \$\begingroup\$ @smwikipedia, processing is always synchronous, so there will be a synchronizer chain to get it into the right clock domain for either approach. The main difference is that with edge triggered interrupts, the peripheral cannot take it back and say "nevermind." \$\endgroup\$ Nov 3, 2022 at 15:15
1
\$\begingroup\$

There is no specific context you are referring to, but here is a general answer which can for example be directly applied AVRs.

Interrupts can be level or edge triggered.

Edge triggered means an interrupt is flagged for execution when a certain configurable edge happens, for example a falling edge. But it is only flaggd when a high-to-low transition is detected. It does not keep re-triggering the flag while signal is low, or when there is a low-to-high transition, or while signal is high. The interrupt code is executes once at falling edge and after it has been acknowledged (currently pending interrupt cleared) it will not retrigger an interrupt until the next falling edge.

Level triggered means an interrupt is flagged for execution while the signal is at certain seleced level. The edges don't matter. For example, if a signal goes low, it will keep flagging the interrupt for execution until the signal goes high. No matter how many times the interrupt gets executed, a low signal will retrigger it after interrupt has been executed and acknowledged.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks. "...an interrupt is flagged for execution when a certain configurable edge happens...". What I want to make sure is that the interrupt is flagged on one pin (event) and edge happens on another (clock/gating). Right? That's why I think some event may be missed if it mismatches the clock edge cadence. \$\endgroup\$ Nov 1, 2022 at 23:39
1
\$\begingroup\$

In addition to the good responses that you have already received, I want to add the following.

The question that you referenced was from almost 11 years ago and concerned, specifically, the 8085. There is nothing wrong with that. I believe that the clock/gating line you refer to is the microprocessor clock.

It is probably a good idea that you consider that the complexity of interrupts has grown somewhat from that time (see for example, https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf section 2.3.2 to look at interrupt processing on a more modern chip - RP2040.

It is not that the all of the principles have changed, but they have evolved such that vectored interrupts and priorities, while still there, are more complicated (at least to my brain). For example, GPIO edge-triggered interrupts are commonplace now, but not 'then'.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.