STM32软件PWM呼吸灯：定时器中断实现非阻塞亮度控制

1. 定时器软件PWM呼吸灯：从延时阻塞到精准时序控制的工程演进

在嵌入式系统开发中，“呼吸灯”常被用作入门级外设控制实验。但其背后隐藏着一个核心工程命题：如何在资源受限的MCU上，以最小的系统开销实现高精度、非阻塞的周期性信号生成。早期基于HAL_Delay()或裸机循环延时的实现方式，虽逻辑直观，却在实际项目中暴露出致命缺陷——主程序陷入“死等”状态，导致实时任务无法响应、传感器采样丢失、按键事件漏判。本节将完整剖析一种基于STM32 HAL库定时器中断的软件PWM方案，它不依赖特定硬件PWM通道，仅通过通用GPIO与精确计时，构建出100级平滑亮度调节的呼吸效果。该方案的本质，是将时间维度解耦为两个正交控制环：底层由定时器中断驱动的微秒级时间轴分割，上层由主循环调度的毫秒级亮度状态迁移。这种分层设计思想，正是嵌入式实时系统架构的基石。

1.1 延时呼吸灯的工程瓶颈与重构必要性

回顾上一节基于HAL_Delay()的简易呼吸灯实现，其代码结构通常如下：

while (1) { for (uint8_t brightness = 0; brightness <= 100; brightness++) { set_led_brightness(brightness); HAL_Delay(10); // 阻塞式延时 } for (uint8_t brightness = 100; brightness >= 0; brightness--) { set_led_brightness(brightness); HAL_Delay(10); } }

此方案存在三个不可忽视的工程缺陷：

第一，主循环完全丧失实时响应能力。HAL_Delay(10)本质是调用HAL_GetTick()轮询等待，期间CPU持续执行空循环或进入低功耗模式。若系统需同时处理UART接收、ADC采样或外部中断（如按键），这些事件将在10ms内被完全屏蔽。例如，当呼吸灯处于最亮状态时，用户按下按键，该电平变化将因主循环阻塞而无法被及时捕获，造成交互失灵。

第二，亮度分辨率与刷新平滑度受制于延时精度下限。STM32F103系列的SysTick默认配置为1ms中断，HAL_Delay()最小分辨率为1ms。若要实现100级亮度调节，单次呼吸周期需耗时2000ms（100级×2方向），每级停留20ms。此时人眼已能感知明显的亮度阶跃感，呈现“卡顿”而非“呼吸”。若强行缩短延时至5ms，则总周期压缩为1000ms，但100级×5ms=500ms的单向时间过短，呼吸节奏失去自然感。

第三，系统扩展性差，难以融入复杂任务框架。在引入FreeRTOS或多任务调度后，HAL_Delay()会将当前任务挂起，但呼吸灯逻辑仍需与其他任务（如网络通信、数据处理）共享CPU资源。阻塞式延时破坏了任务调度的公平性，且无法实现呼吸灯亮度与传感器读数的同步更新。

因此，必须将呼吸灯控制逻辑从主循环中剥离，交由独立的时间基准驱动。定时器中断天然具备这一特性：它在后台以固定周期触发，不占用主循环CPU时间，且精度可达微秒级。本方案选用TIM2作为基准时钟源，通过中断服务程序（ISR）维护一个全局时间计数器，为主循环提供高精度、非阻塞的事件触发信号。

1.2 硬件资源配置与时钟树分析

本实验采用STM32F103C8T6核心板，LED连接于PC13引脚。需明确以下硬件约束：

• GPIO配置：PC13为开漏输出（OD），内部无上拉电阻，故需外接10kΩ上拉电阻至3.3V。LED阴极接PC13，阳极经限流电阻（220Ω）接3.3V，构成低电平有效驱动方式。这意味着HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET)熄灭LED，GPIO_PIN_RESET点亮LED。

• 定时器选型：TIM2为APB1总线外设，最大计数频率为72MHz/2=36MHz（APB1预分频为2）。本方案要求生成10μs精度的中断，即中断频率为100kHz。计算预分频值（PSC）与自动重装载值（ARR）：

• 系统时钟SYSCLK=72MHz，APB1时钟PCLK1=36MHz。
• 定时器时钟频率 = PCLK1 × (PSC + 1) = 36MHz × (PSC + 1)
• 目标中断周期 = 10μs → 中断频率 = 100kHz
• 因此：36MHz × (PSC + 1) / (ARR + 1) = 100kHz
• 选取PSC = 35，使定时器时钟 = 36MHz / 36 = 1MHz
• 则ARR = (1MHz / 100kHz) - 1 = 9

此配置下，TIM2每10μs产生一次更新事件（UEV），触发中断。该精度远超人眼可分辨的临界值（约16ms），为100级亮度平滑过渡奠定基础。

• 中断优先级分组：使用NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_2)，即2位抢占优先级+2位子优先级。将TIM2中断设为抢占优先级2（高于SysTick的默认优先级），确保其响应延迟稳定在数十纳秒量级，避免被其他中断长时间阻塞。

1.3 软件PWM核心原理：时间轴分割与输出比较

软件PWM并非直接生成方波，而是通过高频定时中断，在每个微小时间片内动态决策GPIO电平。其数学模型可表述为：

在一个PWM周期T内，将时间轴离散化为N个等长片段（T/N），其中前M个片段输出低电平，后(N-M)个片段输出高电平，则占空比D = M/N。

本方案设定：
- PWM周期T = 1ms（即1000μs）
- 时间片长度Δt = 10μs → N = T/Δt = 100
- 亮度等级Light ∈ [0, 100]，对应M = Light

因此，当Light=30时，前30个10μs片段输出低电平（LED点亮），后70个片段输出高电平（LED熄灭），等效占空比30%，LED呈现30%亮度。此即“输出比较”（Output Compare）概念的软件实现——在每个中断中，将当前计数值pwm_counter与目标亮度light_level比较，决定GPIO输出状态。

该模型的关键优势在于：亮度调节与时间基准完全解耦。pwm_counter由10μs中断递增，light_level由主循环按需修改，二者通过简单的整数比较即可完成电平切换，无任何浮点运算或查表开销，符合MCU资源约束。

2. 工程实现：双时间尺度协同架构

本方案采用“双时间尺度”架构：底层10μs中断维护PWM时间轴，上层10ms主循环调度亮度状态迁移。二者通过共享变量与标志位协同，彻底消除阻塞。

2.1 全局变量定义与内存布局

所有跨上下文访问的变量均声明为volatile，防止编译器优化导致读写异常。变量布局遵循“中断安全”原则——仅读取操作可于ISR中进行，写入操作严格限定于主循环。

/* 定义于main.c全局作用域 */ volatile uint8_t pwm_counter = 0; // PWM时间轴计数器，范围[0,99] volatile uint8_t light_level = 10; // 当前亮度等级，范围[0,100] volatile uint8_t direction_flag = 0; // 方向标志：0=暗→亮，1=亮→暗 volatile uint16_t time_10ms_counter = 0; // 10ms计数器，用于亮度更新定时 volatile uint8_t time_10ms_flag = 0; // 10ms定时标志，主循环查询

• pwm_counter：在TIM2中断中递增并清零，主循环只读。因其为8位变量，溢出行为（255→0）与PWM周期100完美匹配，无需额外判断。
• light_level：主循环修改，中断中只读。亮度变化速率由time_10ms_flag控制，确保每次修改间隔≥10ms，避免高频抖动。
• direction_flag：主循环根据light_level边界条件更新，中断中只读。
• time_10ms_counter与time_10ms_flag：构成软件定时器，替代HAL_Delay()。

2.2 TIM2中断服务程序：PWM时间轴引擎

TIM2中断服务程序（HAL_TIM_PeriodElapsedCallback）是整个系统的脉搏，其执行时间必须严格控制在微秒级，否则将影响PWM精度。

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM2) { // 1. 更新PWM计数器：每10μs加1，满100归零 if (++pwm_counter >= 100) { pwm_counter = 0; } // 2. 执行输出比较：根据当前亮度决定LED电平 // 注意：PC13低电平点亮，故brightness > pwm_counter时输出低电平 if (light_level > pwm_counter) { HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET); // LED ON } else { HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET); // LED OFF } // 3. 10ms软件定时器：每1000次中断（10μs×1000=10ms）触发一次 if (++time_10ms_counter >= 1000) { time_10ms_counter = 0; time_10ms_flag = 1; // 置位标志，通知主循环 } } }

关键设计解析：
-计数器溢出处理：pwm_counter使用前置自增++pwm_counter，避免pwm_counter++在溢出时产生临时变量。比较>=100而非==100，容错边界条件。
-输出比较逻辑：light_level > pwm_counter实现“前M段低电平”，符合低电平点亮LED的硬件连接。此比较为单周期指令，执行时间稳定。
-10ms定时器：复用同一中断源，通过time_10ms_counter累加实现。1000次10μs中断=10ms，精度误差<0.1%，远优于HAL_Delay()的毫秒级误差。

2.3 主循环逻辑：亮度状态机与非阻塞调度

主循环不再包含任何延时，而是以事件驱动方式响应time_10ms_flag，执行亮度更新与方向切换。

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_TIM2_Init(); // 初始化TIM2，开启中断 HAL_TIM_Base_Start_IT(&htim2); // 启动TIM2中断 while (1) { // 1. 检查10ms定时标志 if (time_10ms_flag) { time_10ms_flag = 0; // 清除标志，避免重复执行 // 2. 根据方向标志更新亮度 if (direction_flag == 0) { // 暗→亮 if (light_level < 100) { light_level++; } else { direction_flag = 1; // 达到最亮，切换方向 } } else { // 亮→暗 if (light_level > 0) { light_level--; } else { direction_flag = 0; // 达到最暗，切换方向 } } } // 3. 主循环可在此处插入其他任务 // 例如：传感器读取、UART发送、按键扫描等 // 不受呼吸灯逻辑影响 } }

状态机行为验证：
- 初始light_level=10,direction_flag=0→ 每10mslight_level++，直至light_level=100，此时direction_flag置1。
-direction_flag=1后，每10mslight_level--，直至light_level=0，此时direction_flag置0。
- 单次呼吸周期 = (100-10)/10ms + (100-0)/10ms = 900ms + 1000ms = 1900ms ≈ 2s，符合人眼舒适呼吸节奏。

2.4 CubeMX配置要点与生成代码适配

在STM32CubeMX中配置TIM2需注意以下细节，避免生成代码与手动逻辑冲突：

• 时钟配置：在“Clock Configuration”页，确保APB1 Prescaler设为2（PCLK1=36MHz）。TIM2 Clock设为“Same as APB1”。
• TIM2参数：
• Prescaler = 35 （使定时器时钟=1MHz）
• Counter Period = 9 （1MHz / (35+1) / (9+1) = 100kHz）
• Counter Mode = Up
• Auto-reload Preload = Disable（简化逻辑）
• 中断使能：在“Configuration”页，勾选TIM2 → “Update interrupt”。
• 生成设置：“Project Manager” → “Code Generator” → 勾选“Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral”，避免初始化代码混杂。

生成的MX_TIM2_Init()函数中，需确认htim2.Init.Period = 9且htim2.Init.Prescaler = 35。若CubeMX版本较新，可能默认启用Auto-reload Preload，需手动在生成的tim.c中注释掉相关行，或在MX_TIM2_Init()末尾添加__HAL_TIM_DISABLE_IT(&htim2, TIM_IT_UPDATE);再重新使能，确保中断配置纯净。

3. 性能优化与工程实践技巧

上述基础实现已满足功能需求，但在实际产品开发中，需进一步优化鲁棒性与可维护性。

3.1 中断安全的亮度更新机制

当前方案中，light_level在主循环中被修改，而TIM2中断持续读取。若light_level为16位变量（如uint16_t），在ARM Cortex-M3/M4上，light_level++非原子操作，可能在读取高字节与低字节之间被中断打断，导致短暂的错误值。虽本例uint8_t无此问题，但为养成良好习惯，应采用以下防护：

// 主循环中更新亮度时 __disable_irq(); // 关闭所有中断 light_level = new_value; __enable_irq(); // 恢复中断 // 或更优雅地，仅禁用TIM2中断 HAL_NVIC_DisableIRQ(TIM2_IRQn); light_level = new_value; HAL_NVIC_EnableIRQ(TIM2_IRQn);

此操作耗时仅数纳秒，对10μs中断无实质影响，却杜绝了潜在竞态风险。

3.2 呼吸频率动态调节接口

实际应用中，呼吸频率常需根据环境光或用户偏好调整。可将10ms定时参数抽象为可配置变量：

volatile uint16_t pwm_update_interval_ms = 10; // 默认10ms volatile uint16_t pwm_update_counter_max = 0; // 在TIM2中断中 if (++time_10ms_counter >= pwm_update_counter_max) { time_10ms_counter = 0; time_10ms_flag = 1; } // 主循环中动态修改 void set_breath_frequency(uint16_t ms) { pwm_update_interval_ms = ms; pwm_update_counter_max = (uint32_t)ms * 100; // 10μs中断频率换算 }

调用set_breath_frequency(1000)即可将呼吸周期延长至约4s，无需重新编译固件。

3.3 调试技巧：利用SWO输出PWM波形

在无示波器条件下，可利用STM32的SWO（Serial Wire Output）引脚，将pwm_counter和light_level以ITM（Instrumentation Trace Macrocell）事件形式输出，通过ST-Link Utility或OpenOCD实时观测波形：

// 在TIM2中断中添加 ITM_SendChar('A' + (pwm_counter % 26)); // 映射为字符流 ITM_SendChar('0' + (light_level / 10)); ITM_SendChar('0' + (light_level % 10));

配合串口终端，可直观看到pwm_counter锯齿波与light_level三角波的叠加关系，快速定位占空比异常。

4. 扩展应用：从呼吸灯到电机调速的工程映射

软件PWM的核心思想——通过高频中断精确控制高低电平持续时间——可无缝迁移到更复杂的执行器控制中。以直流电机调速为例，其硬件接口与LED有本质区别：

• 电流驱动需求：MCU GPIO最大灌电流约20mA，而小型直流电机启动电流常达500mA以上。必须通过驱动芯片（如L298N）或MOSFET（如IRF540）放大电流。
• H桥控制：电机正反转需H桥电路，典型控制逻辑为：
• 正转：IN1=1, IN2=0，PWM信号加至EN引脚
• 反转：IN1=0, IN2=1，PWM信号加至EN引脚
• 刹车：IN1=1, IN2=1
• PWM频率选择：电机调速PWM频率需避开人耳可听范围（20Hz-20kHz），通常选用1-20kHz。本方案100kHz PWM周期过短，需调整TIM2参数：PSC=35, ARR=999 → 1kHz；或PSC=359, ARR=99 → 10kHz。

软件实现仅需修改GPIO操作部分：

// 替换LED控制代码 if (motor_speed > pwm_counter) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_SET); // EN=1 } else { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_RESET); // EN=0 } // 同时设置IN1/IN2方向引脚 HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, direction ? GPIO_PIN_SET : GPIO_PIN_RESET); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_2, direction ? GPIO_PIN_RESET : GPIO_PIN_SET);

此扩展证明：掌握软件PWM原理后，开发者可灵活应对各类PWM应用场景，无需受限于MCU硬件通道数量。在资源紧张的低成本项目中，此技术尤为珍贵。

5. 与硬件PWM的对比及选型建议

STM32提供丰富的硬件PWM（TIMx_CHy）资源，为何还要实现软件PWM？二者并非替代关系，而是互补：

选型决策树：
- 若项目仅有1-2个PWM需求，且目标引脚支持硬件PWM（查《STM32F103xx Datasheet》Table 11），优先选用硬件PWM。配置简单，资源占用低。
- 若需控制8个LED亮度，但MCU仅有4个硬件PWM通道，软件PWM是唯一可行方案。
- 若目标引脚（如PC13）无任何定时器复用功能，软件PWM是强制选择。
- 在FreeRTOS环境中，软件PWM的time_10ms_flag可替换为xQueueSendFromISR()向任务发送消息，实现更优雅的任务同步。

我在实际开发一款环境监测节点时，曾遇到类似场景：需要同时驱动4路WS2812B RGB灯（需800kHz PWM）、1路蜂鸣器（2kHz）、2路电机（10kHz）。MCU仅提供6个硬件PWM通道，且WS2812B时序要求严苛，最终采用“硬件PWM+软件模拟”混合方案——电机与蜂鸣器用硬件PWM，WS2812B用DMA+定时器单脉冲模式，呼吸灯则用本文所述软件PWM。这印证了：没有银弹技术，唯有深刻理解原理，方能在约束中找到最优解。