0

I know that this topic was debated a long time ago (link: Difference between interrupt and event ), even though, I don't consider the answer adequate. The reason is the next: when one talks about events versus interruptions, the term events signifies something about hardware and not software. Moreover, according to that explanation, an event is predictable, not something which comes across suddenly, but, in the case of a wake-up event, this cannot be true, because this event is not "expected", it is something spontaneously. For instance, one may look at the stm32 datasheet and notice that there is a so-called wake-up event enable register. This "event" involves neither a specific piece of code to be executed nor something related to software stuff.

pauk
  • 350
  • 4
  • 15
  • I think the original question asked today would be closed as a matter of opinion, so off-topic. The answer, or at least your interpretation of it reported here certainly seems inadequate, and IMO incorrect. An _event_ is something that happens in the real-world/environment in which a system exists. How such an event might be detected includes, but is not exclusive to interrupts. Pressing a button might be an event, the event may cause an interrupt or it might be polled for example. – Clifford Apr 21 '21 at 06:56
  • Then why stm32 has enable registers for the <> and not for the wake-up interrupt, even if other enable registers are dedicated for interrupts, and not for wake-up ? – pauk Apr 23 '21 at 05:35
  • The term "event" has generic meaning. If you are concerned about a specific context, you should specify that context in the question. Moreover, the wake-up signal is not in any case an interrupt. It wakes the processor up and the processor restarts as if a reset had occurred. – Clifford Apr 23 '21 at 08:24

1 Answers1

1

Events is a higher abstraction layer concept, usually found in system or application programming. They are not necessarily based on hardware, but could be purely triggered by software. There is no single definition of the term, it's pretty broad.

Interrupts on the other hand are always triggered by hardware, on the lowest level. Yet another term is hardware exceptions, upper-tier cores and microcontrollers often separate those as something thrown by the core or supervising hardware when some abnormal condition occurs (invalid instruction, divide by zero, memory access errors etc). Whereas interrupt sources could either be expected hardware behavior or some error condition.

Interrupts and hardware exceptions require the handler function to be registered in a hardware look-up table often called interrupt vector table. The hardware will go to this table when the interrupt occur to find the address of the function to call - such functions are named interrupt service routines (ISR). There will be a special calling convention for interrupts, where certain registers are stacked by the hardware before the ISR is called, and special return instructions from are used to restore the registers when the ISR is finished.

Events however use software callback functions, typically by the application passing on a function pointer upon event creation. That's typically how they are used in application programming and Rapid Application Development (RAD) tools. In embedded systems one might create something similar by letting the application register a number of callbacks for certain things that occur inside a driver, then let the driver call the callback. But even though a driver is the lowest-level code on top of the hardware, it is still software and performing a call designed by software.

But since "event" is such a broad term, in some cases events are objects that can be used together with broader API functions. And then they don't necessarily have a callback function - they are essentially just flags. In the Windows OS for example, the application programmer can create an event to signal something to a running thread, after which the thread can utilize a CPU effective sleep function and wait until the event is received. This is one of the normal ways to properly stop a thread by letting it finish up gracefully by itself.

What interrupts and events have in common is that they both lead to effective but non-deterministic execution. The program can do other things when the interrupt/event hasn't fired and it doesn't need to use polling of some flag, which is the alternative to interrupts. But when it fires, it aborts the current execution and disrupts it by executing something else. Also, it pushes some extra call on the stack in addition to the present call stack, so if it happens when the program is at its deepest call level, you can get very subtle errors like intermittent stack overflow.

Another issue with interrupts and possibly with events too is that they most often act as separate threads, with all the thread safety issues that come with them. You'll need to protect variables shared with the ISR/callback from race condition bugs, either by semaphores or by guaranteeing atomic access. Failing to do so is I'd say by far the all time most common error in embedded systems. This too creates incredibly subtle bugs.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • ``They are not necessarily based on hardware, but could be purely triggered by software.`` Interruptions could be software-based either. – pauk Apr 23 '21 at 05:15
  • ``Interrupts on the other hand are always triggered by hardware, on the lowest level.`` That's what I've said before. – pauk Apr 23 '21 at 05:16
  • ``Interrupts and hardware exceptions require the handler function to be registered in a hardware lookup table often called interrupt vector table.`` Is there another name for the so-called <>? – pauk Apr 23 '21 at 05:18
  • ``Events however use software callback functions, typically by the application passing on a function pointer upon event creation. ... But even though a driver is the lowest-level code on top of the hardware, it is still software and performing a call designed by software.`` Well, here I could mention the wake-up event, which requires neither instructions to be executed nor software involvement. – pauk Apr 23 '21 at 05:22
  • ``But since "event" is such a broad term, in some cases events are objects that can be used together with broader API functions.`` These are another sort of events. I was talking about hardware events. – pauk Apr 23 '21 at 05:31
  • ``What interrupts and events have in common is that they both lead to effective but non-deterministic execution. The program can do other things when the interrupt/event hasn't fired and it doesn't need to use polling of some flag, which is the alternative to interrupts. `` I agree with you, that's why it is very difficult to notice the difference between these two terms. – pauk Apr 23 '21 at 05:32