When utilizing the asynchronous api, there is one usage of the interrupt callback handler that worth notice when developing an application: timing sensitive commands are not supposedly to be executed within an interrupt

Let's take a look at this short example here:

The MCU is set to go into sleep mode when executing an asynchronous procedure.

When function sleep() is called, the current clock state is stored before the clock that is currently running is disabled. Then, a wait for interrupt function WFI() is executed to listen for any incoming interrupt requests while the execution of MCU is halted. These interrupts could be receiving data through serial, or a pin is set to high, etc. See the flow char here:

When executing an interrupt handler or event callback function, we say that the kernel is in interrupt context. For example, the processor is put to sleep() until it receives some serial data from UART to light up an led. Lighting up an LED is the serial callback , and is said to be in an interrupt context. It is asynchronous with respect to the current main process. Interrupt context is time critical because the interrupt handler interrupts other code. So, it should be quick and simple. because of its asynchronous nature, there are certain functions that are not supposed to be called within an interrupt context. If the interrupt request triggers some timing sensitive events or executions, the clock needs to be enabled in order for these procedures to continues. However, the program is actually still running within sleep() function and has not yet returned. Any timing sensitive execution should be avoided here. Such timing sensitive commands include but are not limited to: printf("content"), wait(number), serial.getc(),serial.putc().