2022-07-17 11:57 PM
Hi,
I have seen that to enable the interrupt for a given peripheral we must enable the correct bit in the peripheral registers (e.g in the DIER register for a timer) and then call the following functions (e.g for peripheral timer3)
NVIC_EnableIRQ(TIM3_IRQn);
NVIC_SetPriority(TIM3_IRQn, 1);
NVIC_ClearPendingIRQ(TIM3_IRQn);
Can you explain what these functions do?
2022-07-18 12:59 AM
The stm32 consists of an arm processor and many peripherals. If you want the arm processor to respond to a particular event inside a peripheral, you need to tell the peripheral to raise its interrupt signal. But you also need to tell the Nested Vector Interrupt Controller to pass that interrupt to the arm processor only if it is higher-priority than any interrupts that the arm processor is currently handling.
It's hard to give an explanation without you understanding the underlying hardware, which is documented in the Reference Manual and Cortex xx Programming Manual.
The Cortex Programming Manual has a chapter on Core Peripherals, one of which is the Nested vectored interrupt controller (NVIC).
With that chapter to hand, look through the source-code for those functions, which might be in core_xx.h
Hope this helps,
Danish
2022-07-18 02:30 PM
> and then call the following functions
Enabling IRQ must be the last action. And clearing the pending status typically is not necessary.
2022-07-19 07:51 AM
Hi @Danish and @Piranha
Thanks for your replies.
Now interrupts are a way clearer for me..however I still have to understand several things. Fo rInstance, when the interrupt is called by the peripheral, is there a maximum time I can spend in the interrupt handler before the code jumps back again ?
2022-07-19 11:50 AM
>>is there a maximum time I can spend in the interrupt handler before the code jumps back again ?
Not really, although performance and functionality may deteriorate.
You can be interrupted by a source at a "higher" preemption level, but not by anything at or below. When you exit your routine the NVIC will either directly enter the next interrupt, or pop context.
One should avoid blocking code in interrupts and callbacks, or using timeouts dependent of software counts coming via other interrupts.