使用HAL_Delay，注意HAL_Delay(0)表示0.xms，HAL_Delay(1)表示1.xms，依次类推

eric2013

默认情况下，我们设置的滴答定时器都是1ms为单位，HAL_Delay也是以这个为时基执行的。

为了保证最小执行时间，HAL库里面直接对这个函数做了+1操作。



由于我们调用HAL_Delay的时刻不定，所以这个函数是无法保证1ms的精度，误差1ms。

HAL_Delay(0)  延迟时间范围0 - 1ms
HAL_Delay(1)  延迟时间范围1 - 2ms
HAL_Delay(2)  延迟时间范围2 - 3ms
。。。。。。。
。。。。。。。

以此类推

caicaptain2

这是个有趣的现象，以前从未想到HAL_Delay()可以设定为数值0。
我今天在任务中调用HAL_Delay()就遇到了。 在FreeRTOS任务函数的同一个位置，调用HAL_Delay(0) 等效于osDelay(1)，延时时间是0.x毫秒。

而且，这个x的数值与它在任务函数中的位置有关系。
如果是在任务函数的刚开始的阶段调用HAL_Delay(0) 或osDelay(1)，延时时间就比较接近于1ms。可以认为刚进入任务函数时，起点时间就是0.0毫秒。
如果是在任务函数的中间调用它们，延时时间就比较随机了。比如任务函数经过一段数值计算后，再调用延时这种情况。但是都处于0~1毫秒之间。因为此时延时的起点时间是个大约随机的0.y毫秒。


另外，由于只是需要延时1ms左右，osDelay(1)的时间也无法给其他任务使用。所以说HAL_Delay(0) 等效于osDelay(1)意义相同。
还有个考虑，HAL_Delay()的计时来自于TIM11（cubemx的配置） ，RTOS的osDelay(1)计时来自于systick。这2个定时器的启动时间有所不同，也可能带来一些区别吧。我这个实验中，HAL的初始化和任务调度器运行之间只有几个外设的初始化，可以认为启动时间在毫秒尺度上几乎一致，才会有开头的结论。