IRQ Handler 和 Callback 函数有什么区别?

Tür*_*rım 0 embedded interrupt stm32f4

我们正在使用 STM32F429I 并尝试通过不同的方式使用定时器(TIM2 和 TIM5)。在我们的代码中启用计时器并调用后;

HAL_TIM_Base_Start_IT(&htim5);
Run Code Online (Sandbox Code Playgroud)

我们可以通过调用TIM5_IRQHandler函数来更新变量。我们注意到HAL_TIM_PeriodElapsedCallback函数已完成相同的过程。

那么我们的问题是:这两个函数有什么区别吗?

Cli*_*ord 5

在STM32Cube框架中TIM5_IRQHandler()调用HAL_TIM_IRQHandler()哪个调用HAL_TIM_PeriodElapsedCallback()(以及许多其他事件回调)。

HAL_TIM_PeriodElapsedCallback()具有“弱链接”,这意味着定义了不执行任何操作的默认值,您可以通过定义自己的实现来覆盖它。

以这种方式使用 HAL 的一个缺点是,它会增加中断处理程序的开销,并且因为HAL_TIM_PeriodElapsedCallback()所有定时器都会调用相同的中断处理程序,所以如果要处理多个定时器,则需要额外的代码来确定哪个定时器调用了回调。当此类计时器用于完全不同的目的时,从低耦合/高内聚的角度来看,这可能会导致糟糕的设计。

在绝对确定性行为和最小中断时间至关重要的情况下,您可能希望避免这种“为舒适而构建”的基础设施并直接处理计时器中断。一般来说,这也会带来更好的设计(更低的耦合/更高的内聚)。

如果您广泛使用 STM32Cube 和 CMSIS 框架和中间件,那么规避 HAL 可能会导致使用该代码库时出现问题。

  • @TürkerBerkeYıldırım 这将是一个意见问题,所以偏离主题。我的回答至少是为了使之成为一种知情的意见。我想说,如果您致力于使用 HAL 的解决方案,那么阻力最小的途径就是按照预期的方式使用它。就我个人而言,我认为整个 ST Cube/HAL 是一个设计得可怕、不匹配的臃肿软件集合,旨在将您锁定在 ST 的部件中,并要求您使用比您原本需要的更大、更快、更昂贵的部件。但这只是一个意见。 (2认同)