思考:如果中断函数HAL_IncTick中的uwTick一直增加导致溢出会不会导致延时不准?
下面展示一些 STM32的官方库文件stm32f1xx_hal.c部分摘录
。
__weak void HAL_IncTick(void)
{
uwTick += uwTickFreq;
}
__weak uint32_t HAL_GetTick(void)
{
return uwTick;
}
__weak void HAL_Delay(uint32_t Delay)
{
uint32_t tickstart = HAL_GetTick();
uint32_t wait = Delay;
/* Add a freq to guarantee minimum wait */
if (wait < HAL_MAX_DELAY)
{
wait += (uint32_t)(uwTickFreq);
}
while((HAL_GetTick() - tickstart) < wait)
{
}
}
1.问题:
系统Tick频率设置为1毫秒中断一次,每1ms产生一次Tick中断,
在Tick中断中uwTick++; 那么当自增到0xFFFFFFFF后就会溢出,再从0开始自增 。
0xFFFFFFFF毫秒大约为49.71天,也就是49天以后会产生第一次溢出
如果恰巧在延时时有溢出会导致不准吗?
2.分析:
每1ms产生一次Tick中断,在Tick中断中uwTick++;
uint32_t HAL_GetTick()函数返回的是当前uwTick的值。
假设uwTick已经计数到65530,调用HAL_Delay(10);
tickstart = 65530,但是wait是11,那么当uwTick=65535+1,就会溢出uwTick= 0,
执行while((HAL_GetTick() - tickstart) < wait){}
当HAL_GetTick()返回0时的情况:(HAL_GetTick() - tickstart) =(0-65530)
可能认为这是个负数,此时会导致((HAL_GetTick() - tickstart) < Delay) = ((0 - 65530) < 10)=FALSE
事实并非如此,因为HAL_GetTick()的返回值、tickstart和Delay都是uint32_t 型数据,这样HAL_GetTick() - tickstart的结果不可能是负数!(重点)
此时计算uwTick-tickstart=0-65530=-65530:二进制表示0000 0000 0000 0110,无符号十进制=6,
那么当uwTick=5(0000 0000 0000 0101)时,
uwTick-tickstart=5-65530=-65525,二进制表示0000 0000 0000 1011,
延时还是11ms(0000 0000 0000 1011),所以无符号的uwTick溢出并不会导致延迟错乱,此处差值不存在负数,要考虑好无符号数的计算方法。
这个问题的主要依据是使用了计算机的原码,反码,补码的知识。可以参考如下链接,写的非常好
链接: https://www.cnblogs.com/zhangziqiu/archive/2011/03/30/ComputerCode.html
反转
后来我看到有人评论uint32_t是32位,最大数位4294967295,就突然觉得上面举例不成立了,后来仔细想了想,其实原理都一样,只不过是到4294967295才会溢出,上面举的例子把65530改为4294967290就合理了。
uwTick-tickstart=5-4294967290=-4294967285,十六进制表示FFFF 0000 000B,
延时还是11ms(0000 000B),文章来源:https://www.toymoban.com/news/detail-842065.html
3.拓展
编码器计算速度
使用定时器编码器模式计数编码器的脉冲,当计数值达最大溢出时,相减仍然可以得到差值,用来计算速度。文章来源地址https://www.toymoban.com/news/detail-842065.html
到了这里,关于关于STM32的hal库中滴答定时器uwTick溢出的思考和分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!