思考：如果中断函数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=-65525，十六进制表示FFFF 0000 000B,
延时还是11ms（0000 000B），

3.拓展

编码器计算速度
使用定时器编码器模式计数编码器的脉冲，当计数值达最大溢出时，相减仍然可以得到差值，用来计算速度。