Callback versus interrupt handler differences

[jmueckl]

What is the difference between an interrupt handler that is specified with an internal name such as void FLEXCOMM9_IRQHandler(void) and an interrupt that is implemented as a callback?

Two differences I see are the fact that the first type needs to end with SDK_ISR_EXIT_BARRIER.  Do the callback’s embed the ISR exit barrier within it?

The second is that there may be as many as eight (and no more?) callback functions using the array ctimer_callback_t ctimer_callback_table[] = { ctimer_match0_callback, ctimer_match1_callback, NULL, NULL, NULL, NULL, NULL, NULL};

[xiangjun_rong]

Hi,Jerry,

Regarding the difference between interrupt handler and callback functions, as you know that the interrupt handler is an ISR(interrupt service routine) exactly, when an event happens, an interrupt is triggered, the MCU stop the current code execution and jump to ISR with PC/SR register saved in stack automatically.

For the callback function, as the name implies, the callBack function is called by system, the caller which call the callback function is  concealed by system.

For the LPC SDK package, almost all callback function is called by interrupt handler, regarding the multiple callback functions of CTimer, in the interrupt handler of CTimer, the core checks CTimer status register to identify which events trigger the interrupt handle and call corresponding callback functions.

For the exit barrier, just interrupt handler requires to add the exiting barrier code, it is NOT required for the callback function.

Hope it can help you

BR

Xiangjun Rong

[jmueckl]

Rong,

Is there any reason one would choose to use a callback function as opposed to an interrupt handler?  Is one more efficient than the other?

[frank_m]

This question suggests you either did not understand the given answers, or did not read them carefully.

[jmueckl]

I'm looking for application information here.  Which method would you prefer to use, Frank?

[converse · Accepted solution]

Callbacks are normally used by libraries or application frameworks. It means that the library provides the interrupt handler (and therefore performs the necessary interrupt functions, and maybe sets things up like adding data to a queue/fifo/whatever). The interrupt handler will then invoke the callback functions (there may be more than one, depending on the framework) without the user having to edit the provided handler. The application instead 'registers' the callback with the library, which is then called to provide application-specific functionality.

If you are not using a library/framework in your application then you would provide the interrupt handler yourself.

[jmueckl]

Thank you to everyone who answered my post.  This is the first time I encountered Callbacks. Every answer was a piece of the puzzle giving me a full picture to view.  The last post enabled me to put every answer into perspective.  

[frank_m]

An interrupt handler is definitely required. Through the startup code, even the name is usually fixed.

However for the LPC SDK, the interrupt handlers are usually implemented in the drivers section (fsl_*.c).

Unless you want to modify the SDK code or forego it, you need to use the callbacks.

[frank_m]

> ... and an interrupt that is implemented as a callback?

Interrupt handlers are not implemented as callbacks.

A "callback" is a method used by a framework (SDK, protocol stack, OS) to let the user application execute code in the interrupt context. The handler itself is implemented by the framework, and not supposed to be touched by the user. It calls the callback functions instead.

Be aware that this callbacks run in interrupt context, i.e. timing restrictions/issues with other interrupts apply.