STM32 HAL库实战：PWM输出在写Flash时如何避免舵机抖动？一个真实案例的两种解法
在嵌入式开发中，PWM信号控制舵机是常见应用场景。但当系统需要执行Flash写入操作时，往往会遇到一个棘手问题：PWM波形异常导致舵机抖动。本文将深入分析问题根源，并提供两种经过验证的解决方案。
1. 问题现象与根源分析
最近在一个机器人控制项目中，我们使用STM32的TIM14定时器生成PWM信号驱动舵机。系统正常运行良好，但当按下按键触发Flash写入操作时，舵机会出现明显抖动。
通过逻辑分析仪捕获的波形显示，在Flash写入期间，PWM信号变成了20ms高电平和20ms低电平交替的异常波形。这种异常信号会导致舵机在目标位置附近不断抖动，严重影响系统稳定性。
问题根源在于：
- Flash写入操作通常需要关闭中断以保证数据完整性
- PWM的比较值更新是在定时器中断中完成的
- 中断关闭导致比较值无法更新，PWM波形"冻结"在当前状态
- 舵机将这种异常波形解读为无效指令，产生抖动
2. 解决方案一：轮询锁定低电平
第一种方法的核心思想是在关闭中断前，确保PWM输出锁定在低电平状态。这种方法适用于必须关闭中断的Flash操作场景。
2.1 实现步骤
- 等待低电平到来：通过轮询方式检测PWM引脚状态
- 设置比较值：当检测到低电平时，立即设置比较值为周期最大值
- 执行Flash操作：在保持低电平状态下安全地写入Flash
关键代码如下：
// 等待PWM输出变为低电平 while(HAL_GPIO_ReadPin(TIMCH_Buff[i].GPIOx, TIMCH_Buff[i].GPIO_Pin) != GPIO_PIN_RESET){} // 设置比较值为周期最大值，保持低电平 __HAL_TIM_SET_COMPARE(&TIMCH_Buff[i].htim, TIMCH_Buff[i].channel, 64000); // 关闭中断并执行Flash写入 __disable_irq(); Write_Flash_Buf(FLASH_RF_PIN_MODE_ADR,(uint8_t *) modebuff, sizeof(modebuff)); Write_Flash_Buf(FLASH_RF_PIN_DATA_ADR, Slave_re_Pindata_temp, sizeof(Slave_re_Pindata_temp)); __enable_irq();2.2 定时器中断处理优化
为了配合这种方法，需要在定时器中断处理中添加特殊逻辑：
if(HAL_GPIO_ReadPin(timch->GPIOx, timch->GPIO_Pin) == GPIO_PIN_SET) { // 高电平状态：正常更新比较值 timch->count =__HAL_TIM_GET_COMPARE(&timch->htim, timch->channel) + (4864+Buf[rps[timch->rpspin].mode]-2048); timch->count = (timch->count>TIM_PERIOD) ? (timch->count-TIM_PERIOD) : timch->count; __HAL_TIM_SET_COMPARE(&timch->htim, timch->channel, timch->count); } else { // 低电平状态：设置比较值为周期最大值 __HAL_TIM_SET_COMPARE(&timch->htim, timch->channel, 64000); }提示：这种方法需要精确计算等待低电平的超时时间，避免系统死锁。
3. 解决方案二：定时器启停控制
第二种方法不需要关闭中断，而是通过控制定时器的启停来保证PWM输出稳定性。这种方法更适合对中断响应要求不高的场景。
3.1 实现步骤
- 等待低电平到来：同样通过轮询检测PWM引脚状态
- 停止定时器输出：在低电平时停止PWM输出
- 执行Flash操作：此时PWM引脚将保持最后状态(低电平)
- 恢复定时器输出：操作完成后重新启动PWM
关键代码如下：
// 等待PWM输出变为低电平 while(HAL_GPIO_ReadPin(TIMCH_Buff[i].GPIOx, TIMCH_Buff[i].GPIO_Pin) != GPIO_PIN_RESET){} // 停止定时器输出(保持当前低电平) HAL_TIM_OC_Stop_IT(&TIMCH_Buff[i].htim, TIMCH_Buff[i].channel); // 执行Flash写入(无需关闭中断) Write_Flash_Buf(FLASH_RF_PIN_MODE_ADR,(uint8_t *) modebuff, sizeof(modebuff)); Write_Flash_Buf(FLASH_RF_PIN_DATA_ADR, Slave_re_Pindata_temp, sizeof(Slave_re_Pindata_temp)); // 重新启动定时器输出 HAL_TIM_OC_Start_IT(&TIMCH_Buff[i].htim, TIMCH_Buff[i].channel);3.2 方案优势对比
| 特性 | 方案一(轮询锁定) | 方案二(定时器启停) |
|---|---|---|
| 中断状态 | 需要关闭中断 | 保持中断开启 |
| 系统响应性 | 较差(中断关闭期间) | 较好 |
| 实现复杂度 | 中等(需修改中断处理) | 简单 |
| 适用场景 | 必须关闭中断的Flash操作 | 常规Flash操作 |
| 资源占用 | 需要轮询等待 | 只需一次启停操作 |
4. 工程实践建议
在实际项目中选择解决方案时，需要考虑以下因素：
系统实时性要求：
- 如果系统对中断响应要求高，优先考虑方案二
- 如果Flash操作必须关闭中断，则选择方案一
PWM信号特性：
- 对于高频PWM信号，轮询等待低电平可能耗时较长
- 低频信号(如舵机控制)更适合方案一
代码可维护性：
- 方案二实现更简洁，后期维护成本低
- 方案一需要对定时器中断有更深入的理解
异常处理：
- 为轮询等待添加超时机制，避免死锁
- 在定时器启停前后添加状态检查
5. 深入理解：STM32定时器工作机制
要彻底解决这个问题，需要理解STM32定时器的几个关键机制：
输出比较模式：
- TIM_OCMODE_TOGGLE模式下，当计数器值与比较值匹配时，输出引脚电平翻转
- 比较值更新通常发生在定时器中断中
自动重装载预加载：
- TIM_AUTORELOAD_PRELOAD_ENABLE可以确保周期值更改无毛刺
- 但对比较值的即时更新没有同样效果
中断与DMA：
- 定时器更新事件可以触发中断或DMA请求
- Flash操作期间中断关闭会影响这些机制
理解这些底层机制，有助于我们在类似问题上快速找到解决方案。
