2023-12-14 03:31 PM - edited 2023-12-15 07:51 AM
I generally prefer the STM Low Level drives and chose that driver family for most peripheral in CubeMX Project Manager->Advanced Settings->Driver Selector. There seem to be one disadvantage: the IRQHandlers are not generated as weak which I think happens with the CubeMX generated HAL IRQHandlers. So with the LL drivers, I have to add a line of code to the CubeMX generated stm32h7xx_it.c file. Like this:
void USART1_IRQHandler(void)
{
/* USER CODE BEGIN USART1_IRQn 0 */
myUSART1_IRQHandler();
/* USER CODE END USART1_IRQn 0 */
/* USER CODE BEGIN USART1_IRQn 1 */
/* USER CODE END USART1_IRQn 1 */
}
Is there a way to tell CubeMX to generate the IRQHandler stubs as weak?
And what does the CubeMX Project Manager->Advanced Settings->Register CallBack disable/enable setting do? I've generated code with this enabled and disabled and don't see any obvious difference.
Thanks
Solved! Go to Solution.
2023-12-15 10:19 AM
Yes, those are effectively your options.
The HAL has its own callbacks for transfer complete, or when a character is received, or whatever. I would implement and use those if you don't need computational speed.
If you do need computational speed, I would add the user code to the IRQ function in stm32_*_it.c directly. Calling your own function in there with user code is also fine, but will be a little slower.
Really up to you, no wrong method.
2023-12-15 08:50 AM
IRQ handlers are never generated as weak--not in HAL or LL.
> Is there a way to tell CubeMX to generate the IRQHandler stubs as weak?
There are weak definitions in startup_*.s file that would conflict with any other weak definitions, so this is not a possibility.
The callback stuff has to deal with how HAL handles callbacks within its machinery, not how IRQ handlers are defined. Not going to help you here.
2023-12-15 09:18 AM
@TDK Thanks for the help. Given that information, it seems like I have 2 options. Keep doing what I'm doing by adding a line of code to every IRQHandler in the stm32H7xx_it.c file that CubeMX generates. Or remove stm32H7xx_it.c from my project and write my own.
A better question is how would you handle this situation?
Thanks again
2023-12-15 10:19 AM
Yes, those are effectively your options.
The HAL has its own callbacks for transfer complete, or when a character is received, or whatever. I would implement and use those if you don't need computational speed.
If you do need computational speed, I would add the user code to the IRQ function in stm32_*_it.c directly. Calling your own function in there with user code is also fine, but will be a little slower.
Really up to you, no wrong method.