在基于STM32 HAL的项目中,一般需要维护的 “时基” 主要有2个:
而这些 “时基” 该去如何维护,主要分为两种情况考虑:
在这种情况下,需要维护的时间仅有SYS Timebase Source,也就是HAL库中的 uwTick,这是HAL库中维护的一个全局变量,比如在 stm32f1xx_hal.c/stm32f4xx_hal.c 等不同系列的文件中都有如下定义:
__IO uint32_t uwTick;
在 CubeMX 配置界面中关于 SYS Timebase Source 的选择部分,如下图所示:
由此可见,我们可以通过 SysTick(滴答定时器) 或 (TIMx)定时器 的方式来维护 SYS Timebase Source。在裸机运行的情况下,我们一般选择默认的 SysTick(滴答定时器) 方式即可,也就是直接放在 SysTick_Handler() 中断服务函数中来维护。
用CubeMX生成代码之后,会看到 SysTick_Handler() 中断服务函数(省去无关、不重要代码和注释)如下:
void SysTick_Handler(void)
{
HAL_IncTick();
HAL_SYSTICK_IRQHandler();
}
其中的 HAL_SYSTICK_IRQHandler() 其实为空,是留给用户自己实现的,直接忽略即可。所以 SysTick_Handler() 中断服务函数中主要做的就是 HAL_IncTick(),其定义(省去无关、不重要代码和注释)如下:
__weak void HAL_IncTick(void)
{
uwTick++;
}
这就是在裸机运行的情况下,对于 SYS Timebase Source 的维护。
前面提到的 SYS Timebase Source 是STM32的HAL库中的新增部分,主要用于实现 HAL_Delay() 以及作为各种 timeout 的时钟基准。
在使用了OS(操作系统)之后,OS的运行也需要一个时钟基准(简称“时基”),来对任务和时间等进行管理。而OS的这个 时基 一般也都是通过 SysTick(滴答定时器) 来维护的,这时就需要考虑 “HAL的时基” 和 “OS的时基” 是否要共用 SysTick(滴答定时器) 了。
如果使用过CubeMX的话,肯定知道,当我们在CubeMX中选择启用FreeRTOS之后,在生成代码时,CubeMX一定会报如下提示:
上面大致的意思就是:强烈建议用户在使用FreeRTOS的时候,不要使用 SysTick(滴答定时器)作为 “HAL的时基”,因为FreeRTOS要用,最好是要换一个!!!
如果你直接选择“Yes”忽略本条warning的话,代码也是可以正常生成的,最后可以看到生成的 SysTick_Handler() 中断服务函数(省去无关、不重要代码和注释)如下:
void SysTick_Handler(void)
{
HAL_IncTick();
osSystickHandler();
}
由上可见,原来不重要的空函数 HAL_SYSTICK_IRQHandler() 被删掉了,但是加上了一个非常重要的 FreeRTOS的 “滴答处理函数”:osSystickHandler(),感兴趣的话可以去看一下此函数的定义,它其实是被CubeMX封装过的,其本质其实就是FreeRTOS原生的滴答处理函数:xPortSysTickHandler()。
上面这样就实现了 HAL 和 OS 共用 SysTick(滴答定时器) 来维护各自的时基。
由于我自己在实际项目中从来没有这么共用过,所以也不太好妄加猜测这么用到底好不好,会有什么潜在的风险这样等等。但既然CubeMX(代表ST)都建议我们都不要这么用了,并且STM32本就还有很多其他的定时器可以用,我们也没必要这么抠资源了吧。
在CubeMX报出上面的warning之后,我们可以选择“No”,然后去更改 SYS Timebase Source 选项为任意一个定时器,比如选择 TIM7,如下图所示:
然后再生成代码,可以看到:
OS的时基 所用的 SysTick_Handler() 中断服务函数(省去无关、不重要代码和注释)变为了:
void SysTick_Handler(void)
{
osSystickHandler();
}
而 HAL的时基 已经放到了我们选择的 TIM7 的回调函数(省去无关、不重要代码和注释)中来处理了:
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim->Instance == TIM7) {
HAL_IncTick();
}
}
这样将 “HAL的时基” 和 “OS的时基” 完全分开处理,感觉似乎确实要舒服些,哈哈~