stm32的hal库的hal_delay问题

只看该作者 · 2015-1-29 17:41

void HAL_IncTick(void)
{
  uwTick++;
}
中断函数是1ms进来一次，也就是说uwTick+1就代表1ms
void SysTick_Handler(void)
{
  HAL_IncTick();
}
void HAL_Delay(__IO uint32_t Delay)
{
  __IO uint32_t timingdelay;

  timingdelay = uwTick + Delay;
  //while(HAL_GetTick() < timingdelay)
      while(uwTick < timingdelay)
  {;
  }
}
在HAL库里我就没看到哪里对uwTick溢出进行处理，也就是说uwTick=0xffffffff的时候再加1就是uwTick=0了  那这一时刻的延时不就延时不准确了吗？

uint32_t HAL_GetTick(void)
{
  return uwTick;
}
这函数，很多库文件调用，用来timeout 延时
我觉得调用了uint32_t HAL_GetTick(void)函数的延时都是有问题的
不过我算了一下要连接上电46天多才会出现bug （0xffffffff个ms）

只看该作者 · 2015-1-30 16:01

少用延时才是硬道理

只看该作者 · 2015-1-31 15:23

但是这是官方的延时bug 确实根据条件来判断会好过延时

只看该作者 · 2015-1-31 17:23

这个函数最大的问题不是这个，是这个函数需要调用中断函数的结果，如果一个更高级的中断需要调用这个函数，就无法得到延时而是直接一直等，所以最好重新写这个函数！

只看该作者 · 2015-2-2 08:14

如果一个更高优先级的中断打断它，那么根本延时就不准了，需要想办法用systick做延时。

只看该作者 · 2015-2-2 08:15

非中断方式来搞。

只看该作者 · 2015-2-4 09:42

问题是 HAL库很多地方都是用到这uwTick变量来延时
uint32_t HAL_GetTick(void)
{
return uwTick;
}
这函数，很多库文件调用，用来timeout 延时
我觉得调用了uint32_t HAL_GetTick(void)函数的延时都是有问题的
不过我算了一下要连接上电46天多才会出现bug （0xffffffff个ms）

只看该作者 · 2015-5-14 14:38

fuluoce 发表于 2015-2-4 09:42
问题是 HAL库很多地方都是用到这uwTick变量来延时
uint32_t HAL_GetTick(void)
{

好像确实存在这个问题，我觉得可以重写HAL_Delay函数，在每次调用之前或之后清零uwTick，尽量不要让uwtick满，不知道思路对不对？

只看该作者 · 2015-5-14 16:38

这个不算bug，除非你用来延时超过46天
因为用的是无符号整形，不存在出现负数情况
1-0xffffffff=2
不会有问题的

只看该作者 · 2015-5-15 07:52

本帖最后由 yyblike 于 2015-5-15 08:28 编辑

sadfasdfare 发表于 2015-5-14 16:38
这个不算bug，除非你用来延时超过46天
因为用的是无符号整形，不存在出现负数情况
1-0xffffffff=2

看他们都这样说也没有细想，看你这么一说似乎确实没有问题，这个数据类型在这里似乎真没有问题，为了防止意外，我还是计划重写下HAL_InitTick函数为0.1ms中断一次，用4天多的时间运行下看结果。另外以前讨论过一个问题，

复制

unsigned char a = 0;

a = a-1;

if(a == 0xff)

{

printf("aaa");

}

else

{

printf("bbb");

}

结果输出的结果是“bbb”，编译器将a的数据类型提升为了unsigned int类型，结果a-1后的结果是0xffff，不过这里应该不会出现这个问题，32位应该是最大数据宽度了，不存在数据类型提升问题。我在MDK环境下看了下，如你所说。

只看该作者 · 2015-5-16 21:11

yyblike 发表于 2015-5-15 07:52
看他们都这样说也没有细想，看你这么一说似乎确实没有问题，这个数据类型在这里似乎真没有问题，为了防止 ...

我看过u-IP、Linux都是这样用的
没有人去判断过溢出，没必要

就好像计算LRC，有人喜欢弄个32位整数去累计，最后&0x000000ff
我都是直接弄个一个BYTE直接累计，直接就是结果了

只看该作者 · 2015-5-17 09:16

sadfasdfare 发表于 2015-5-16 21:11
我看过u-IP、Linux都是这样用的
没有人去判断过溢出，没必要

嗯，累加是没有任何问题的，但是有减的时候还是需要注意下，但是在这里确实是没有任何问题的。

只看该作者 · 2015-5-27 11:24

sadfasdfare 发表于 2015-5-14 16:38
这个不算bug，除非你用来延时超过46天
因为用的是无符号整形，不存在出现负数情况
1-0xffffffff=2

这里不是一直延时46天会出现，而是每46天就出现溢出的状况！和你需要延时多久是没关系的！
下面的算法可以解决问题
#define TIMER_DIFF(END,BEGIN) ((END - BEGIN + 0xffffffff) % 0xffffffff)//计算时间差
END是当前时间值
BEGIN是记录的时间点
TIMER_DIFF是计算从记录时间点到当前时间的延时

只看该作者 · 2015-5-27 11:31

sadfasdfare 发表于 2015-5-16 21:11
我看过u-IP、Linux都是这样用的
没有人去判断过溢出，没必要

你看到Linux里应该也有算法的，
下面的算法可以解决问题
#define TIMER_DIFF(END,BEGIN) ((END - BEGIN + 0xffffffff) % 0xffffffff)//计算时间差

void HAL_Delay(__IO uint32_t Delay)
{
  __IO uint32_t timingdelay;

  timingdelay = uwTick;
  while(TIMER_DIFF(uwTick ,timingdelay) < Delay)
  {;
  }
}

只看该作者 · 2015-5-27 11:32

下面的算法可以解决问题
#define TIMER_DIFF(END,BEGIN) ((END - BEGIN + 0xffffffff) % 0xffffffff)//计算时间差

void HAL_Delay(__IO uint32_t Delay)
{
  __IO uint32_t timingdelay;

  timingdelay = uwTick;
  while(TIMER_DIFF(uwTick ,timingdelay) < Delay)
  {;
  }
}