Timer STM32 HAL_延迟定时器微控制器

HAL_延迟函数和空for循环之间的区别是什么？定时器应创建中断并关闭LED。 如果我在中断功能中使用HAL_延迟，结果是LED永远熄灭：

void TIM6_DAC_IRQHandler() {
     HAL_TIM_IRQHandler(&htim6);
     HAL_GPIO_WritePin(LED1_GPIO_Port, LED1_Pin, GPIO_PIN_RESET);
     HAL_Delay(125);        
 }

但如果我使用：

void  TIM6_DAC_IRQHandler() {
     HAL_TIM_IRQHandler(&htim6); 
     HAL_GPIO_WritePin(LED1_GPIO_Port, LED1_Pin, GPIO_PIN_RESET);
     for (int i=0; i<1000000; i++);
}

然后，在主文件中始终处于打开状态的LED1会被短暂地设置，然后如我所期望的那样打开。 那么，为什么带有HAL_延迟的代码不起作用呢

经验法则：永远不要在中断处理程序中使用延迟。 HAL_Delay使用SysTick中断，如果SysTick的优先级低于调用该处理程序的中断的优先级，则将进入死循环，因为SysTick处理程序将永远不会被调用

空循环： 我个人建议使用其他形式的循环：

for(volatile count = 0; count < 1000; count++);

或

---

空for循环可以得到优化，并且如果您知道如何防止延迟的持续时间不像以前在PIC上那样严格。即使您对其进行了调优，更改循环的对齐方式也可以通过在之前或附近添加其他代码来更改时间，并且无论您如何解决优化问题，都会使其易受攻击。硬件定时器有其自身的库开销精度问题，不能延迟很小的周期，但通常是更好的路径。HAL_延迟可能取决于系统定时器和SysTick中断。是否启用了SysTick中断？相对于TIM6中断，SysTick中断的优先级是多少？如果TIM6中断的优先级较高，则在TIM6中断执行期间，SysTick中断将不会执行，因此HAL_延迟将无法正常工作。即使SysTick中断具有更高的优先级，也应该避免中断处理程序中的延迟，因此您应该重新考虑您的设计。

for(count = 0; count < 1000; count++) asm("");