STM32步进电机蓝牙控制：PWM脉冲、加减速与串口解帧实战

简介：本资源是一份面向嵌入式初学者与进阶开发者的STM32步进电机控制实战工程，围绕串口蓝牙通讯、定时器脉冲输出与电机驱动三条主线展开，解决手机APP远程控制步进电机正反转、调速与精确步进的落地问题，适用于智能家居、自动化设备的入门练手与课程设计参考。压缩包共479个文件、约71.95MB，以c源码与h头文件各80个为主体，另含78个o编译中间文件、80个crf浏览索引，以及Keil工程文件uvproj、sct分散加载与axf、map等构建产物，并附chm手册与少量说明文本，构成可直接打开的完整工程。已有841人学习下载。资源代码按主函数、蓝牙通信、步进电机驱动、定时器配置与命令解析等模块拆分，读者可据此理清APP指令到电机脉冲的完整链路，掌握PWM频率调节、串口协议栈配置与中断服务编写，并借助map与lst文件分析编译结果、排查常见驱动问题。

1. 一个脉冲决定一格精度：这套 STM32 步进电机蓝牙控制例程能解决什么

有个做小型滑台的开发者跟我吐槽：电机能转，但让它走 10 毫米，它走 12 毫米；手机点了停止，它还往前溜一段。问题从来不是「步进电机动不起来」，而是「动得准、停得干脆、指令不丢」。这套基于 STM32 的步进电机串口蓝牙控制例程，就是围绕这个最小闭环搭起来的：STM32 用定时器输出脉冲驱动步进电机，手机 APP 通过蓝牙串口下发方向、步数、速度指令，MCU 收帧解析后按梯形曲线把脉冲一个个吐出去。它适合手上有 C 语言底子、摸过 STM32 的开发者拿去做小型运动平台、云台、推杆机构或者课程设计原型；不适合想直接抄一套工业伺服方案的人。下面按「链路怎么搭、代码怎么写、坑在哪、怎么改成自己的」四步拆开。

2. 系统拆解：从手机屏幕到电机相线的四层链路

这套东西看着是「手机控制电机」，实际断成四段，任何一段没对齐，现象都是「电机不动」，但病因完全不同。先把链路画在地上，再谈代码。

2.1 四层链路与器件清单

从上往下数：第一层是手机端的 APP，负责把「走 2000 步、正转、速度 800Hz」翻译成一串字节；第二层是蓝牙串口透传模块，它不关心你发的是什么，只负责把蓝牙包原样倒进串口，本质就是一根无线替换的杜邦线；第三层是 STM32 的 USART 加定时器，是整个系统的大脑，负责解帧、维护当前位置、产生脉冲；第四层是细分驱动器和电机，把 3.3V 的逻辑脉冲放大成能推动线圈的电流。

选型上有几个我自己的习惯。驱动器优先选带光耦隔离输入的细分模块，STM32 的 IO 直连驱动器 STEP/DIR 时，一定要确认驱动器输入电流需求，必要时串 220Ω 限流电阻，别把 IO 口当功率口用。蓝牙模块选带 STATE 引脚的，上电后 MCU 能读到「已连接」状态，做联调时能省掉一半「到底是谁没发数据」的怀疑。电源务必两路分开：电机一路（12V 或 24V），MCU 和蓝牙一路（5V/3.3V），只在地线上单点汇合。

提示：蓝牙模块的 VCC 大多标 5V，但它的 RX 引脚是 3.3V 电平。如果你的 STM32 是 3.3V 供电，TX 直连没问题，但模块 VCC 接 5V 时，串个分压或电平转换更稳，别问我怎么知道的。

2.2 工程目录与源码组织

例程的目录结构基本是 CubeMX 生成加手写业务层，把「芯片相关」和「业务相关」切开，后面改起来才不痛苦。

StepperBluetooth/ ├── Core/ │ ├── Inc/ │ │ ├── main.h │ │ ├── motor.h # 电机控制对外接口 │ │ ├── protocol.h # 通信协议帧定义 │ │ └── ringbuf.h # 环形缓冲区 │ └── Src/ │ ├── main.c # 初始化顺序 + 主循环 │ ├── stm32f1xx_it.c # 中断入口，只做转发 │ ├── motor.c # 定时器脉冲、加减速、位置计数 │ ├── protocol.c # 状态机解帧、指令分发 │ └── ringbuf.c # 无锁环形缓冲读写 ├── Drivers/ # HAL 库与 CMSIS └── MDK-ARM/ # 工程文件与下载配置

main.c 里的初始化顺序是有讲究的，顺序错了会出现「上电瞬间电机自己抖一下」这种玄学现象：

int main(void) { HAL_Init(); SystemClock_Config(); // 先定主频，后面所有定时器计算都依赖它 MX_GPIO_Init(); // 先把 STEP/DIR/ENA 拉到确定电平 MX_TIM2_Init(); // 脉冲定时器，先不启动 MX_USART1_UART_Init(); // 串口先能收 Motor_Init(); // 内部会强制 ENA 拉高（禁用），DIR 拉低 Protocol_Init(); HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1); HAL_TIM_Base_Start_IT(&htim2); // 使能更新中断用于计数 HAL_UART_Receive_IT(&huart1, &g_rx_byte, 1); while (1) { Protocol_Poll(); // 主循环解帧，不在中断里做业务 Motor_Task(); // 处理「走完停机」「软限位」等状态 } }

这段顺序的关键在于：GPIO 一定要早于定时器初始化，否则 TIM 通道复用推挽输出生效的瞬间，引脚会有一个不确定电平，驱动器把它当成一个脉冲，电机就动一格。很多人调试时发现「每次上电位置都不一样」，八成就是这里。另外HAL_TIM_Base_Start_IT要在 PWM 启动之后调，避免第一个更新中断在 ARR 还没装载时误触发。

2.3 通信协议帧：为什么不能直接发字符串

新手最容易走的捷径是手机发"F1000"这样的字符串，STM32 用strcmp比对。联调阶段能跑，一旦丢一个字节，后面的整段数据全部错位，而且没法校验。正确做法是定长帧头 + 长度 + 校验。

举例：让电机正转 1000 步，1000 = 0x000003E8，帧就是AA 55 05 01 00 E8 03 00 00 F1，最后那个 F1 是05+01+00+E8+03+00+00 = 0xF1的低 8 位。定长帧的好处是解析端只需要一个 6 状态的状态机，不需要动态内存，也不会因为一个字节错误吃掉后面十帧。累加和虽然弱，但对串口这种误码率极低的链路足够，成本是几乎零 CPU。

3. 定时器输出脉冲：步进电机驱动核心代码逐段拆

电机控制这块是整套例程的重心，也是「能不能走得准」的分水岭。频率算错一点，走位就差一截；加减速没做，电机就啸叫或者堵转。

3.1 两种发脉冲的方式：PWM 硬件输出 vs 定时器中断翻转

第一种是纯软件：定时器开个 50kHz 中断，中断里手动翻转 IO，同时计数。优点是灵活，任意时刻能插自定义逻辑；缺点是高频下 CPU 全被中断吃掉，20kHz 以上基本没法跑业务，而且中断响应抖动会让脉冲不均匀，电机听上去「一顿一顿」。

第二种是硬件 PWM：定时器通道直接输出方波到 STEP 引脚，CPU 只在更新中断里改 ARR 来调频率。脉冲由硬件保证均匀，CPU 占用低，频率能轻松上到 100kHz。代价是「改频率」只能在周期边界生效，加减速要按周期粒度做。

我一般选第二种，因为步进电机的失步大多来自脉冲不均匀，而不是来自「频率改得不够快」。更新中断里只做三件事：累加已发步数、判断是否到减速点、写新的 ARR。

3.2 GPIO 与 TIM 初始化

以 72MHz 主频的常见型号为例，把定时器计数频率降到 1MHz，这样 ARR 的数值直接就是「微秒数减一」，换算频率时心算就能出来。

void MX_TIM2_Init(void) { TIM_ClockConfigTypeDef sClockSourceConfig = {0}; TIM_MasterConfigTypeDef sMasterConfig = {0}; TIM_OC_InitTypeDef sConfigOC = {0}; htim2.Instance = TIM2; htim2.Init.Prescaler = 71; // 72MHz / (71+1) = 1MHz 计数频率 htim2.Init.CounterMode = TIM_COUNTERMODE_UP; htim2.Init.Period = 9999; // 初始 100Hz，上电不会突然快跑 htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim2.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_ENABLE; // ARR 影子寄存器 HAL_TIM_Base_Init(&htim2); sClockSourceConfig.ClockSource = TIM_CLOCKSOURCE_INTERNAL; HAL_TIM_ConfigClockSource(&htim2, &sClockSourceConfig); HAL_TIM_PWM_Init(&htim2); sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET; sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE; HAL_TIMEx_MasterConfigSynchronization(&htim2, &sMasterConfig); sConfigOC.OCMode = TIM_OCMODE_PWM1; sConfigOC.Pulse = 5000; // 占空比 50%，驱动器只认上升沿，占空比不敏感 sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH; sConfigOC.OCFastMode = TIM_OCFAST_DISABLE; HAL_TIM_PWM_ConfigChannel(&htim2, &sConfigOC, TIM_CHANNEL_1); HAL_TIM_MspPostInit(&htim2); // 把 PA0 复用成 TIM2_CH1 }

这里有几个参数值得说清楚。Prescaler 决定计数粒度，71 对应 1MHz，好处是 ARR 直接等于微秒数；如果你的主频不是 72MHz，这一项必须跟着改，很多人抄代码后发现「速度整体慢一倍」，就是主频和预分频没对齐。Period 是自动重装值，PWM 频率 = 1MHz / (Period + 1)，所以 100Hz 对应 9999。AutoReloadPreload 必须开，否则中断里写新 ARR 可能正好撞上计数器溢出，产生一个宽度异常的脉冲，电机听起来会「咔」一下。Pulse 设成周期的一半即可，步进驱动器在上升沿触发，占空比只影响光耦的导通时间，50% 最保险。

写频率的辅助函数我习惯单独抽出来，避免到处除零：

static uint32_t Freq_To_ARR(uint32_t freq_hz) { if (freq_hz < 100) freq_hz = 100; // 下限：太低会听到明显抖动 if (freq_hz > 100000) freq_hz = 100000; // 上限：受驱动器与电机响应限制 return (1000000UL / freq_hz) - 1; }

下限卡 100Hz 是因为再低电机每步之间会明显停顿，低速共振区容易丢步；上限卡 100kHz 是保守值，实际能跑多快取决于驱动器的光耦和电机电感，一般 42 步进电机配细分驱动器，20kHz 到 40kHz 就是极限了。

3.3 加减速：一张表不如一条线性公式

梯形加减速的核心是让频率从起步值平滑爬到最大值，中途不能跳变。有人喜欢预生成一张速度表放 Flash 里，好处是曲线可以做 S 形，坏处是改参数就得重新烧录。我一般用线性插值，代码十行，参数改起来只动两个宏。

typedef struct { uint32_t total; // 本次目标步数 uint32_t done; // 已发脉冲数 uint32_t accel_steps; // 加速段步数 uint32_t decel_steps; // 减速段步数 uint32_t f_start; // 起步频率 Hz uint32_t f_max; // 匀速频率 Hz uint8_t dir; // 0 正转，1 反转 volatile uint8_t busy; // 1 表示运动中 } MotorCtrl_t; static uint32_t Calc_Freq(const MotorCtrl_t *m) { uint32_t f = m->f_max; if (m->done < m->accel_steps) { // 加速段：从 f_start 线性插值到 f_max f = m->f_start + (m->f_max - m->f_start) * m->done / m->accel_steps; } else if (m->done > m->total - m->decel_steps) { // 减速段：从 f_max 线性回落到 f_start uint32_t left = m->total - m->done; f = m->f_start + (m->f_max - m->f_start) * left / m->decel_steps; } return Freq_To_ARR(f); }

这段代码的取值逻辑需要解释一下。accel_steps一般取总步数的十分之一，最少 200 步，太短了加速没意义，还容易在起步瞬间丢步；decel_steps可以和加速段一样长，如果目标是「停得准」，减速段宁可长一点，因为最后几步的定位精度全靠减速段把速度压下来。f_start我习惯设成目标速度的四分之一到三分之一，设太低电机会在共振区磨蹭很久，设太高起步就丢步。注意m->done > m->total - m->decel_steps这个判断有下溢风险，如果total小于decel_steps，结果会是个天文数字，实际工程里要在下发指令时先把decel_steps钳到total/2以内。

3.4 位置计数与「走完 N 步就停」

计数放在更新中断里，这是整套代码唯一允许中断频繁进来的地方。中断服务只做计数和停机判断，绝不做解帧、串口发送这类耗时操作。

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance != TIM2) return; if (!g_motor.busy) return; // 空闲时不动，防止误计数 g_motor.done++; if (g_motor.done >= g_motor.total) { // 到位：先停 PWM，再清 busy，最后回一个应答帧 HAL_TIM_PWM_Stop(&htim2, TIM_CHANNEL_1); g_motor.busy = 0; g_motor.pos_now += (g_motor.dir ? -(int32_t)g_motor.total : (int32_t)g_motor.total); Protocol_SendAck(0x01, 0x00); // 回「走步完成」 return; } __HAL_TIM_SET_AUTORELOAD(&htim2, Calc_Freq(&g_motor)); }

这里的顺序很关键：先停 PWM 再清标志。如果先清busy，主循环可能在 PWM 还没停的瞬间又下发一条新指令，两个动作叠在一起，电机会多走几步。另外pos_now用有符号整型，正反转才能共用一套逻辑，步数为啥要int32_t而不是uint16_t，因为长时间单向运行必然会溢出，溢出之后的所有位置判断全是错的，这种 bug 现场极难复现。

提示：中断里调用了Protocol_SendAck，如果它内部是阻塞式HAL_UART_Transmit，在 9600 波特率下发 8 个字节要 8ms 左右，而 20kHz 的脉冲周期只有 50 微秒。这里的正确做法是把应答塞进发送队列，主循环里再发，别在中断里等串口。

4. 串口蓝牙链路：USART 中断接收与协议状态机

串口这层是最典型的「不写缓冲迟早丢包」。手机 APP 一次发一条指令没问题，一旦做连续点动或者状态回传，就会出现「明明发了，电机没动」的情况，抓包一看，是上一条还没解析完，下一条已经覆盖了接收变量。

4.1 USART 初始化与单字节中断接收

不用 DMA 的原因很简单：帧长不固定，用 DMA 反而要做空闲中断加长度判断，对新手不友好；单字节中断加环形缓冲，代码少、逻辑直白，115200 波特率下 CPU 占用也在可接受范围。

void MX_USART1_UART_Init(void) { huart1.Instance = USART1; huart1.Init.BaudRate = 9600; // 和蓝牙模块出厂默认值保持一致 huart1.Init.WordLength = UART_WORDLENGTH_8B; huart1.Init.StopBits = UART_STOPBITS_1; huart1.Init.Parity = UART_PARITY_NONE; huart1.Init.Mode = UART_MODE_TX_RX; huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart1.Init.OverSampling = UART_OVERSAMPLING_16; HAL_UART_Init(&huart1); }

波特率先用 9600，因为绝大多数蓝牙串口模块出厂就是这个值，等链路调通之后再统一改成 115200 提速。改的时候两边必须同时改：模块的波特率是通过 AT 指令改的，STM32 这边改BaudRate字段，两边不一致的现象就是收到一堆0x00或乱码。

4.2 环形缓冲区：不做这个迟早丢包

环形缓冲的核心是「中断只写、主循环只读」，两个指针各管一头，天然不需要关中断。

#define RX_BUF_SIZE 128 static uint8_t s_buf[RX_BUF_SIZE]; static volatile uint16_t s_head = 0; // 中断写 static volatile uint16_t s_tail = 0; // 主循环读 static uint8_t s_rx_byte; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { uint16_t next = (s_head + 1) % RX_BUF_SIZE; if (next != s_tail) { // 队列未满才写，满了直接丢新字节 s_buf[s_head] = s_rx_byte; s_head = next; } HAL_UART_Receive_IT(&huart1, &s_rx_byte, 1); // 必须重新挂接收 } } int RingBuf_Read(uint8_t *out) { if (s_tail == s_head) return 0; // 空 *out = s_buf[s_tail]; s_tail = (s_tail + 1) % RX_BUF_SIZE; return 1; }

三个细节决定这段代码能不能真的不丢包。第一，s_rx_byte必须是全局静态变量，不能是栈上的局部变量，HAL 库保存的是它的地址，中断回来时变量已经没了。第二，HAL_UART_Receive_IT必须在回调里重新调用，否则只收一个字节就停了，现象是「第一条指令能收到，之后全无反应」。第三，缓冲区大小取 2 的幂会更高效，但 128 对现在的场景足够，一条 9 字节的帧能缓 14 条，手机连点也扛得住。

4.3 状态机解帧与指令分发

解帧用 6 个状态的状态机，任何一步校验失败就回到 HEAD1，保证错一帧不会连累后面。

typedef enum { S_HEAD1, S_HEAD2, S_LEN, S_CMD, S_DATA, S_SUM } ParseState_t; static ParseState_t s_state = S_HEAD1; static uint8_t s_len, s_cmd, s_idx, s_sum; static uint8_t s_data[16]; void Protocol_Poll(void) { uint8_t b; while (RingBuf_Read(&b)) { switch (s_state) { case S_HEAD1: if (b == 0xAA) s_state = S_HEAD2; break; case S_HEAD2: s_state = (b == 0x55) ? S_LEN : S_HEAD1; break; case S_LEN: if (b == 0 || b > sizeof(s_data)) { s_state = S_HEAD1; break; } s_len = b; s_idx = 0; s_sum = b; s_state = S_CMD; break; case S_CMD: s_cmd = b; s_sum += b; s_state = s_len ? S_DATA : S_SUM; break; case S_DATA: s_data[s_idx++] = b; s_sum += b; if (s_idx >= s_len) s_state = S_SUM; break; case S_SUM: if (b == s_sum) Cmd_Dispatch(s_cmd, s_data, s_len); s_state = S_HEAD1; break; } } } static void Cmd_Dispatch(uint8_t cmd, const uint8_t *d, uint8_t len) { switch (cmd) { case 0x01: { // 走步：方向 1 字节 + 步数 4 字节小端 if (len != 5) break; uint32_t steps = d[1] | (d[2] << 8) | (d[3] << 16) | ((uint32_t)d[4] << 24); Motor_Move(d[0], steps); break; } case 0x02: Motor_Stop(); break; case 0x03: Motor_SetSpeed(d[0] | (d[1] << 8)); break; case 0x04: Protocol_ReportStatus(); break; } }

状态机的好处是永远不需要「等整帧到齐再处理」，字节来一个消化一个，中断和主循环解耦。s_sum在 S_LEN 状态就初始化，后面 CMD 和 DATA 一路累加，避免了单独再遍历一遍数据域。len校验里那句b > sizeof(s_data)是防溢出，没有它，一个误码就能让s_idx越界写，把旁边的变量踩坏，这种内存踩踏的现场现象是「跑几分钟后莫名其妙复位」，查起来能耗一整天。

4.4 APP 侧要配合的三件事

STM32 这边的代码写得再稳，APP 不配合照样出问题。第一件是发送节奏：手机端如果做「长按连续点动」，别每 10ms 发一帧，改成按下发「开始连续运动」、松开发「停止」，让 MCU 自己去循环，否则蓝牙链路的缓冲会成为瓶颈。第二件是配对之后延时：模块从连接到串口链路稳定有几十毫秒延迟，APP 上电即发第一条指令经常丢，加 200ms 延时最保险。第三件是回包解析：MCU 回的「走步完成」也不是即时到达，APP 端要有超时重发或者状态轮询，不能发完就假定成功，尤其是做定位展示的时候。

5. 跑通与避坑：接线、编译下载和那几条踩出来的经验

代码写完之后，真正的麻烦才刚开始。前面几章的逻辑都是静态的，接上电、连上蓝牙之后，各种「不对」才会冒出来。这一章按我实际调试的顺序排：先硬件，再软件，最后是那些查了半天发现是个小问题的坑。

5.1 上电前的接线检查

接线顺序比接线本身更重要。先断电，按「电机电源 — 驱动器 — 主控 — 蓝牙」的顺序接完再上电。驱动器一侧接电机四线时务必对照说明书，同一相的两根线必须接到 A+ / A-，接错的现象是电机抖动但不转，或者转起来明显没劲、发烫。三相和五相的不在这个范围，这里只说最常见的两相四线。

STM32 到驱动器只需要三根线：STEP 接定时器通道输出脚，DIR 接普通 GPIO，ENA 接 GPIO（有些驱动器是低电平使能，要看清楚）。这三个信号必须和驱动器共地，很多「脉冲发出来了但电机不动」的根因就是忘了接 GND，两边电平没有共同的参考点，驱动器根本认不出高电平。

蓝牙模块到 STM32 是交叉接：模块 TX 接 MCU RX，模块 RX 接 MCU TX。这一步接反的概率高得惊人，而且现象和「模块坏了」一模一样，都表现为发送后毫无反应。上电前拿万用表量一下模块 VCC 对 GND 的电压，确认在 4.8V 到 5.2V 之间再往下走。

5.2 编译下载与第一次联调的顺序

第一次联调千万别直接上手机 APP，先用电脑串口助手替代它，把变量降到最少。步骤是这样的：烧录后先测「不发任何指令电机是否静止」，静止说明 GPIO 初值正确；然后手动发一条AA 55 05 01 00 E8 03 00 00 F1，观察电机是否正转 1000 步；再发一条反向的，确认 DIR 控制生效。

串口助手要设成十六进制发送，别勾「自动追加回车换行」，那个勾一开，每帧后面多两个字节，状态机收到 0x0D 0x0A 会当成校验失败回到 HEAD1，现象是「偶尔能通一次」，特别迷惑人。接收端打开十六进制显示，看 MCU 回的应答帧是不是和预期一致。

走通了再换手机 APP 重复一遍同样的三条指令。这一步如果失败而上一步成功，问题就锁定在蓝牙链路，不用再回去查定时器代码。这种「分段替换」的排查思路能省掉大量时间。

5.3 常见问题排查：五条现象、原因和解决

电机只抖不转，或者转两下就停。原因通常是脉冲频率超过了电机在当前细分下的响应极限，或者加速段太短。解决方式是把f_start降到 300Hz 以下，accel_steps拉到总步数的五分之一，f_max先砍一半试。如果降低频率后能转但声音很大，多半是细分设得太低，把驱动器拨码往上调一档。

手机连上了，STM32 一个字节都收不到。按顺序查三件事：TX/RX 是否交叉、是否共地、两边波特率是否一致。这三项都对了还不通，就看模块的 STATE 引脚电平，有些模块没进入透传模式，需要用 AT 指令切一次模式，切换指令各家不同，翻模块手册最快。

走 1000 步，实际多走或少走固定的一小段。固定偏差说明不是随机丢步，而是计数和实际脉冲不一致。常见原因是更新中断被更高优先级的中断抢了，导致done少加一次，而 PWM 照常输出。解决方式是把 TIM2 的中断优先级提到较高一档，或者干脆改用主从定时器门控，让硬件自己数脉冲。另一个可能是驱动器细分和你代码里的「步数」假设不一致，比如代码认为一圈 200 步，实际驱动器设了 8 细分，一圈就是 1600 步。

串口收到的全是乱码或者问号。先查 MCU 的主频配置，SystemClock_Config里 HSE 的值填错会让所有外设的时钟整体偏移，波特率跟着偏，表现为「能收到但全是乱码」。再查蓝牙模块的实际波特率，很多模块出厂是 9600，但被上一个人改成 115200 了自己不知道。这两项排完，剩下的可能是充电器干扰，换成电池供电试一次。

一上电电机就自己转，或者静止时发烫。电机自己转，是因为 DIR 或 ENA 引脚在初始化前浮空，驱动器把干扰当成了脉冲，解决办法是在 GPIO 初始化里显式把 ENA 设成禁用态（注意低电平使能的驱动器要反着写）。静止发烫是另一回事，多半是 ENA 没真正关断，线圈一直有电流，这类驱动器即使不转也会持续发热，长时间放着要有散热或者自动降流。

6. 二次开发：把「走 N 步」改成可编排的运动序列

原例程的指令集只有走步、停止、设速、查状态四条，做单次点动够用，一旦要做「前进—停顿—返回—再前进」这种循环动作，手机端就得自己算时序，链路稍有延迟整个节奏就乱。我的改法是把运动编排下沉到 MCU：新增一条 0x05 指令，数据域是一串「动作段」，每段 7 个字节，包括 4 字节步数、1 字节方向、2 字节段间延时（毫秒）。STM32 收到后先存进一个固定大小的段缓冲区（我一般开 16 段，占用 112 字节 RAM，对小容量型号也友好），然后在电机到位的回调里自动加载下一段。

typedef struct { uint32_t steps; uint16_t delay_ms; uint8_t dir; } MoveSeg_t; static MoveSeg_t s_seg[16]; static uint8_t s_seg_cnt = 0, s_seg_idx = 0; // 在「走步完成」处接着调用，代替原来的 Protocol_SendAck static void Seg_Next(void) { if (++s_seg_idx >= s_seg_cnt) { // 全部走完 s_seg_cnt = s_seg_idx = 0; Protocol_SendAck(0x05, 0x00); return; } uint32_t d = s_seg[s_seg_idx].delay_ms; if (d) { s_pending = 1; // 标记待启动 HAL_Delay(d); // 简化写法，正式版用定时器或主循环计时 } Motor_Move(s_seg[s_seg_idx].dir, s_seg[s_seg_idx].steps); }

这里用了HAL_Delay是为了让逻辑一眼看懂，但实际工程里别这么写，因为它在主循环里空转，串口接收靠中断还能撑住，但状态查询的回包会明显延迟。正式做法是记一个tick_next时间戳，主循环里比较HAL_GetTick()决定是否启动下一段，整条链路完全非阻塞。改造完之后验证的方法很直接：写一段「正转 500 步、停 300ms、反转 500 步、停 300ms」循环 4 次，让它跑二十分钟，然后用游标卡尺量每次回到原点的偏差。偏差应该稳定在一个固定值以内，如果逐次累积变大，说明减速段不够或者段间没等电机完全停稳就发了下一条，把延时加长就能看出来。

我在这类项目上翻过一次车：图省事直接在中断里启动下一段运动，结果高频中断里调用了带临界区的函数，程序偶发卡死，重启后又能跑，查了两天才定位到优先级反转。从那以后我每次往中断里加调用都强制问自己一遍「这行会不会等某个资源」，宁可多写一个状态标志丢到主循环里处理。这套「中断只置标志、主循环干活」的习惯，比任何调试技巧都管用。希望帮到你。

本文还有配套的精品资源，点击获取