Difference between events and interruptions

Question

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.

Answer 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.