2
\$\begingroup\$

I am coming from 8-bit world to 32-bit world specifically stm32f103.

At present I am only doing study and discussion with my fellows to know the major differences in the two worlds and also to select the IDE/compiler for myself.

  1. Some fellows told me that stm32 have single interrupt handler routine. For example if there are 8 timers then there will be 1 ISR and once I am inside that ISR then I will check each timer to figure out which timer has triggered the interrupt.

  2. Some fellows told me that it is IDE/compiler dependent. If I use Keil then i can use individual ISR for each Timer while if I use Truestudio/Cubemx then there will be 1 ISR as in case-1 above.

Can anyone clarify this?

\$\endgroup\$
3
\$\begingroup\$

Some fellows told me that stm32 have single interrupt handler routine.

Definitely false. Look up the Interrupts and Events chapter in the Reference Manual, there are about 60 interrupt handlers.

There are a few instances where more peripherals share a single interrupt handler, but these are rather the exception than the rule.

There are ARM microcontrollers with a single interrupt handler (or rather 2, IRQ and FIQ), but the Cortex-M family has lots of them.

For example if there are 8 timers then there will be 1 ISR and once I am inside that ISR then I will check each timer to figure out which timer has triggered the interrupt.

Each timer has its own handler, the advanced timers TIM1 and TIM8 have some more for various event types. There is a tiny grain of truth however, as timers have a common interrupt vector for all (up to 4) of their channels, so the reading of a single status register can be necessary.

If I use Keil then i can use individual ISR for each Timer while if I use Truestudio/Cubemx then there will be 1 ISR as in case-1 above.

Interrupt handling does not depend on the compiler. You don't even have to declare the interrupt handler as such, they can be ordinary C functions taking no parameters and returning nothing (void), as the necessary register saving and restoring is handled by the hardware.

The source of the confusion might be HAL library shipped with CubeMX, which has common handler and callback functions for each peripheral type, passing around so-called handles with state information. You don't have to use HAL, you'd get by fine with the descriptions of using each peripheral in the Reference Manual.

\$\endgroup\$
  • \$\begingroup\$ Just in case if i use HAL for convenience, then it means that there will be only 1 handle for all timers? \$\endgroup\$ – alt-rose May 27 at 9:59
  • \$\begingroup\$ Does NVIC has anything to do with the fact that we have individual ISR? \$\endgroup\$ – alt-rose May 27 at 10:19
  • \$\begingroup\$ @alt-rose IMHO you should read through the manual and develop two applications one with the HAL package and one without to get familiar with the environment and see which method is going to work best for you. \$\endgroup\$ – Tyler May 27 at 11:05
  • \$\begingroup\$ There are timers which share an interrupt vector. Like timer 1 and timer 10 on the F401. Just nitpicking. \$\endgroup\$ – Arsenal May 27 at 11:18
  • \$\begingroup\$ @alt-rose there will be only 1 handle for all timers? Worse than that. When using HAL, you'd have to populate (or have the CubeMX code generator do it) all timer interrupt handlers with calls to the common HAL_TIM_IRQHandler(TIM_HandleTypeDef *). It would then sort out what happened on which timer, handle it, and call an (optional) user supplied callback function. Which has to examine the parameter structure passed to it to find out once more which timer has triggered the event. Not exactly my idea of "convenience". \$\endgroup\$ – berendi May 27 at 12:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.