问题：STM32中屏蔽中断为何影响SysTick定时精度？

Question

**问题描述：** 在STM32开发中，当使用`__disable_irq()`或在中断服务程序中屏蔽全局中断时，常发现SysTick定时器的精度下降，出现延时不准或计时漂移现象。SysTick作为系统节拍源广泛用于RTOS或裸机延时，其依赖中断来触发定时事件。中断屏蔽期间，SysTick中断被延迟响应，导致计数器更新滞后，进而影响定时精度。理解中断屏蔽对SysTick机制的影响，是确保系统时间基准稳定的关键。

Answer 1

一、SysTick定时器基础与中断屏蔽机制

SysTick定时器是ARM Cortex-M系列内核中内置的一个24位递减计数器，常用于操作系统节拍源（RTOS tick）或裸机系统中的延时函数。其工作原理是：当计数器递减至0时，会触发一次SysTick中断，并自动重载初始值，继续下一轮计数。

在STM32开发中，开发者常使用__disable_irq()或在中断服务程序中临时关闭全局中断（如使用__set_PRIMASK(1)），以保护临界区代码。但这种操作会屏蔽所有中断，包括SysTick中断，从而导致其无法及时响应，造成计数器更新滞后。

二、中断屏蔽对SysTick精度的影响分析

当SysTick中断被屏蔽时，即使计数器到达0，也不会触发中断处理程序，直到中断被重新使能。此时，SysTick的中断响应被延迟，可能导致以下问题：

• 延时函数（如HAL_Delay()）计时不准确
• RTOS时间片调度出现偏差
• 系统时间基准漂移，影响定时任务执行

例如，若SysTick配置为每1ms触发一次中断，而某段代码中关闭中断持续了3ms，则在这3ms期间，SysTick将错过3次中断触发机会，导致时间累计误差。

三、实际测试与误差量化

为了验证中断屏蔽对SysTick的影响，我们进行如下测试：

中断屏蔽时间（ms）	期望延时（ms）	实际延时（ms）	误差（ms）
1	10	11	1
3	10	13	3
5	10	15	5
10	10	20	10

四、解决方案与优化策略

为减少中断屏蔽对SysTick的影响，可以采用以下几种方法：

1. 尽量减少中断屏蔽时间：仅在必须保护临界区时才使用中断屏蔽，且代码执行时间尽量短。
2. 使用优先级屏蔽替代全局中断关闭：通过配置NVIC优先级，使得SysTick中断不被屏蔽，例如使用__set_BASEPRI()而非__disable_irq()。
3. 手动补偿SysTick中断：在中断恢复后，手动检测SysTick是否在屏蔽期间已经触发，进行时间补偿。
4. 使用硬件定时器作为系统节拍源：某些STM32芯片支持将RTOS节拍源切换为通用定时器（TIMx），避免SysTick受中断屏蔽影响。

五、代码示例：手动补偿SysTick中断

void SysTick_Handler(void)
{
    HAL_IncTick();  // 增加系统节拍计数
}

void my_delay_ms(uint32_t ms)
{
    uint32_t start = HAL_GetTick();
    __disable_irq();  // 模拟长时间临界区
    // 假设此处执行了一些耗时操作
    for(volatile int i = 0; i < 100000; i++);
    __enable_irq();

    // 手动补偿SysTick中断
    while ((HAL_GetTick() - start) < ms);
}
    

六、流程图：SysTick中断屏蔽影响与处理流程

            graph TD
                A[开始执行代码] --> B{是否进入临界区?}
                B -- 是 --> C[关闭全局中断]
                C --> D[执行临界区代码]
                D --> E{SysTick中断是否触发?}
                E -- 是 --> F[中断被屏蔽，未响应]
                F --> G[重新开启中断]
                G --> H[检查是否错过中断]
                H -- 是 --> I[手动补偿节拍]
                H -- 否 --> J[继续执行]
                B -- 否 --> K[正常执行]