HAL_TIM_IRQHandler optimization bug

[Nicolae Mihalache]

Posted on March 06, 2017 at 22:49

There are no 'else' statement in between the mutual exclusive 'if' cases in HAL_TIM_IRQHandler. This wastes precious processor cycles in real time (like PID) loops

[...]

}

 

/* Capture compare 2 event */

 

if

( 

[...]

Compare to the better written HAL_DMA_IRQHandler where there are always 'else' statements 

[...]

}

  

 

/* Transfer Complete Interrupt management ***********************************/

 

else if

( 

[...]

#hal_tim_irqhandler

[Imen.D]

Posted on March 07, 2017 at 15:42

Hi Nicolae,

 To have more insight the issue you are facing, please precise in which firmware version are you facing this bug.

Imen

[Tesla DeLorean]

Posted on March 07, 2017 at 16:03

Interrupt handlers can enter with multiple sources asserting.

[Nicolae Mihalache]

Posted on March 07, 2017 at 16:37

 ,

 ,

Imen, Clive, thank you for your replies. I use the last version of Cube 4.19.0.

Clive, great info!

If you allow some further questions / suggestions, I think the situation can be improved, with no extra actions from the user [of Cube]. But quite probably with considerable effort from your team. However, if I am correct, this could get HAL much closer to the ideal of great ease of use (it is almost the case, maybe except the documentation) and program size and speed close to custom built bare bones software. By reading the HAL code, I have the feeling that was one of the goals of the project and it is largely achieved, thank you!

Here are the concrete suggestions for routines like ,

HAL_TIM_IRQHandler and ,HAL_DMA_IRQHandler. Cube already knows what peripherals are used and could generate ♯ define statements accordingly, e.g. IC_USED. If the IRQ functions would be written the with specific ♯ ifdef [...] ♯ endif for each if statement, then:

1. unused parts of code would not be carried intro the flash memory of STM32

2. in general, ,fewer ,if statements would be checked each time an IRQ is called

Further improvement, with probably even more engineering resources needed, could be achieved by reordering the if statements in decreasing order of the priority given to IRQs by the Cube user. I agree, here the gains may be marginal and not justify the means. But the goal of having the absolute best platform [possible] must be motivating, especially that it seems you are not so far off!

Best regards.

[e d]

Posted on May 31, 2017 at 20:04

Sorry to bring this thread back up again but I ran into similar issue. My timer 3 ISR took too long due to the command:

HAL_TIM_IRQHandler(&htim3); taking roughly 4uS to run, which is quite unacceptable.

Since then I have replaced it with:

htim3.Instance->SR = ~TIM_IT_UPDATE;

and the system still runs without issue so far. Anyone sees anything wrong with this?