2017-03-06 01:49 PM
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_irqhandler2017-03-07 06:42 AM
Hi Nicolae,
To have more insight the issue you are facing, please precise in which firmware version are you facing this bug.
Imen
2017-03-07 07:03 AM
Interrupt handlers can enter with multiple sources asserting.
2017-03-07 08:37 AM
,
,
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.
2017-05-31 01:04 PM
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?
2017-05-31 01:38 PM
Won't execute the callback function(s)?
2017-05-31 03:06 PM
For incrementing the
uwTick? Do I need to? I run my own time management with timer2 and not systick, if it makes any sense. Anyways, without the callback function my code is running fine with just clearing the status register like the command above. Thanks!