__weak void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t tickstart = 0U;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }
}
为什么这么严重，明显的Bug一直都在？从未改变！！！！
库里面的所有带timeout的函数都有这样的Bug，从来不敢用！！

fushao 发表于 2018-7-5 11:28
HAL_GetTick（）内部就是一个32位的uwTick，每隔1个tick ++一次，
如果tick设置为1ms，wuTick 49天会溢出。 ...

没有问题的。
你自己试一下吧。

0x00000000 - 0xffffffff = 1

觉得有问题，就自己去验证啊。给uwTick设个临界点的值，在去调用Delay看看，你会发现自己真的是想当然。。

我是熊猫大仙 发表于 2018-7-5 16:41
跟HAL_Delay这样类似的，不需要去判断溢出，直接相减
例子就看jjbboox举的就是 ...

unsigned char a,b,c;
a = 0x00000000;
b = 0xffffffff;
c = a - b;
printf("c=%d\n",c);

以上代码是在X64机器上编译：
gcc b.c -o bb
b.c: 在函数‘main’中:
b.c:7: 警告：大整数隐式截断为无符号类型

这个警告的意义是什么？

这个函数有什么问题？
__weak前缀，你可以自己在main.c或者那里写一个HAL_Delay覆盖就好了，为啥不敢用？

这个函数有什么BUG？
眼拙，没看出啥问题。

jjbboox 发表于 2018-7-5 10:47
这个函数有什么BUG？
眼拙，没看出啥问题。

uint32的问题？

while里没分号？

HAL_GetTick（）内部就是一个32位的uwTick，每隔1个tick ++一次，
如果tick设置为1ms，wuTick 49天会溢出。如果在快要溢出时调用这个函数，就出问题了。
难度st是认为st的mcu不可能连续运行49天，所以才一直不修复这个bug？
库里面的所有timeout函数都是这样

楼主专门注册一个账号来提这个问题，给力！

确实有溢出风险
假如当前TICK已经是U32-10，
此时延时15，应该就会不对了。

没问题的
用uint8_t 做一次就知道了

以前没想过这个问题，乍一看也认为溢出会有问题。
经楼上两位点拨，发现自己还是脑回路太短，太容易被带偏了。

记录一下：
有人认为，HAL_Delay每隔49天左右就会出问题（我一开始也这么以为），原因是uint32每49天会溢出一次，这种观点是错误的。因为即便溢出了，两个unsigned数相减的结果也不会出错，正如11#所言：0x00000000 - 0xffffffff = 1。
HAL_Delay在延时超过49天时才会出错，但没有人会这么干，所以这个函数基本可以认为是没问题的。

我记得曾经也看过有人讨论过这个问题
其实不止是这里，有一些库也用过类似的无符号数相减的特性来优化计算的

我是熊猫大仙 发表于 2018-7-5 14:44
我记得曾经也看过有人讨论过这个问题
其实不止是这里，有一些库也用过类似的无符号数相减的特性来优化计算 ...

无符号数相减是个什么结果 ？？可以利用这个来做什么优化？