C#上位机与STM32串口通信：PWM电机控制与红外位置检测完整方案

简介：基于STM32与C#上位机联动的电机控制项目工程包，面向嵌入式初学者和对串口、PWM、红外定位感兴趣的开发者，整体演示了上位机下发指令、下位机解析执行、红外传感器判断位置的完整控制链路。项目包含STM32 UART通信配置、PWM占空比调速、红外线位置检测，以及C#端SerialPort串口程序和相关协议说明。压缩包共624个文件，以c源文件、h头文件、txt说明、s汇编文件、lsl/ld链接脚本为主，另有ewp/uvprojx等工程配置和少量图表素材，整体约20.18MB，目录结构清晰，便于按模块查阅。已有1076人学习/下载。对需要从零搭建电机控制实验环境的读者，可参考串口协议解析、PWM初始化及红外判断逻辑，减少重复调试成本，也可借此了解STM32与PC联调的工程组织方式。

1. 红外线+PWM电机控制：这个项目到底解决什么问题

做设备联调的从业者大概都遇过这种场面：上位机按钮一按，下位机电机该转到位，结果不是过冲就是没反应，谁都不承认是自己的问题。我手里这套东西，本质上就是一条完整的「C#上位机 → STM32 → PWM驱动电机 → 红外线位置反馈」的链路，上位机通过串口发命令字，STM32解析后控制电机启停和转速，再用对射式红外传感器判断机械结构是否真的到位置。适合正在做毕设、小型自动化台架、工装设备，或者第一次要把上位机逻辑和下位机运动控制串起来的人。这套方案的价值在于：协议层、控制层、反馈层各管一段，哪一段出问题都能单独查。

2. C#上位机与通信协议：串口命令帧设计与解析

很多人第一步就栽在通信协议上——直接用serialPort.Write("1")这种方式发数字，下位机if (ch == '1')就转。这在桌面调试时没问题，但线一长、干扰一来，字节错一位就是另一条命令，电机乱转是迟早的事。我一般会先定一套带帧头、长度、命令字、数据和校验的协议帧，哪怕数据量不大，规范也值得做。

2.1 为什么不能裸发字符：命令帧的结构设计

裸发字符最典型的翻车场景是：上位机发"100"表示占空比 100%，但在串口助手或者线缆接触不良时，可能收到"10"或"10?"这类残帧，下位机如果用atoi()直接转，就把残缺数据当成合法命令执行了。更麻烦的是，你没法在协议层面区分「这是新命令」还是「这是上一条命令的尾巴」。

我在这个项目里用的帧结构是：

帧头(2字节) + 长度(1字节) + 命令字(1字节) + 数据区(N字节) + CRC16校验(2字节)

具体的帧定义可以按这个表来：

为什么帧头用两个字节而不是一个？单字节 0xAA 在噪声环境下可能被随机满足，误触发一次就白等了。用 0xAA 0x55 连续两个字节做识别，误触发的概率大幅下降。命令字我定义了四类：

数据区用字节而非 ASCII 字符串，是为了让数据长度固定、便于解析。比如速度 0~100，一个字节就够；目标位置如果是 0~255 的一维滑台，也只需一个字节。等以后要发角度或更精细的位置，再扩到两字节，协议不用推翻。

2.2 SerialPort 初始化与连接管理：参数怎么设

C# 端我用的是System.IO.Ports.SerialPort，这部分代码比较固定，但有几个参数值得单独说：

using System.IO.Ports; SerialPort sp = new SerialPort(); sp.PortName = "COM3"; // 实际端口号可以从设备管理器查 sp.BaudRate = 19200; // 115200 高速易丢帧，9600 太慢，19200 稳妥 sp.DataBits = 8; sp.Parity = Parity.None; sp.StopBits = StopBits.One; sp.Handshake = Handshake.None; // 无硬件流控，避免 DTR/RTS 干扰 sp.ReadTimeout = 500; // 读超时 500ms，防止阻塞 sp.WriteTimeout = 500; sp.Open();

波特率这块我踩过坑：115200 在中短距离 USB 转串口线时没问题，但一旦经过延长线或转接板，高速率的位时序对地线和电源噪声特别敏感，偶发断帧查半天。9600 又太慢——一条 8 字节的帧要传约 4ms，如果上位机要频繁轮询位置状态，这个延迟不可忽略。19200 是我试下来在「速率、稳定性、下位机时钟误差容忍度」之间的平衡点，属于够用且稳的选择。

还要注意DtrEnable和RtsEnable，很多 USB 转串口模块默认把这两个脚拉高，如果设备那边恰好用到了这些引脚，可能导致意外复位或电平冲突。我一般显式把它们设为false，省得玄学问题。

2.3 命令发送与回显解析：把帧组织出来

发送命令的代码，核心是自己拼帧、算 CRC、写串口。这里我把帧组织单独抽成一个方法，方便后续加命令：

// 数据格式: 0xAA 0x55 | len | cmd | data... | crc_hi | crc_lo byte[] BuildFrame(byte cmd, byte[] data) { int len = 1 + (data?.Length ?? 0); // 命令字 + 数据字节数 byte[] frame = new byte[2 + 1 + len + 2]; frame[0] = 0xAA; frame[1] = 0x55; frame[2] = (byte)len; frame[3] = cmd; if (data != null) data.CopyTo(frame, 4); ushort crc = Crc16(frame, 2, len); // 从长度字段开始算校验 frame[4 + len] = (byte)(crc >> 8); frame[4 + len + 1] = (byte)(crc & 0xFF); return frame; } void SendCmd(byte cmd, byte[] data) { byte[] frame = BuildFrame(cmd, data); sp.Write(frame, 0, frame.Length); }

这段代码有几个点需要解释清楚。len = 1 + data.Length是因为帧结构里长度字段统计的是命令字加数据区，不含帧头也不含校验。CRC 计算我从长度字段开始，是因为帧头固定，没必要参与校验；参与越多，越能覆盖整帧的完整性。CRC16 的生成多项式我用的 Modbus 标准0xA001，查表法实现，网上现成代码多，性能在 19200 波特率下完全够用。

读取回显时，建议在独立线程或DataReceived事件里处理，不要在 UI 线程里ReadExisting()——串口数据到达时机不可控，UI 线程一阻塞界面就卡死。我用的做法是收到一帧就放到队列里，UI 定时器去取：

private void sp_DataReceived(object sender, SerialDataReceivedEventArgs e) { int n = sp.BytesToRead; if (n <= 0) return; byte[] buf = new byte[n]; sp.Read(buf, 0, n); // 把 buf 追加到接收缓冲区，然后做帧解析 }

注意BytesToRead是当前缓冲区里的字节数，不代表一整帧到齐了，所以上位机端也得做缓冲和帧边界识别。很多人在这一步偷懒，直接ReadLine()按\n切——如果下位机没发换行符，或者一帧被拆成两段到达，就会漏。这块你完全可以复用 2.1 的状态机思路，只是语言换成 C# 而已。

3. STM32端命令解析与PWM调速：状态机与定时器配置

上位机的帧发出去了，接下来就是 STM32 这边的事。STM32 端的核心任务分三块：通过 USART 中断接收数据，用状态机从字节流里把完整帧抠出来，再用定时器输出 PWM 控制电机。这三件事说起来简单，但每一块都有细节，尤其是状态机写得不严谨，帧边界一乱就全线崩溃。

3.1 USART 中断接收与状态机解析

我用串口空闲中断做不定长接收，然后逐字节喂给状态机。状态机的好处是：不需要知道帧有多长，也不怕字节被拆成两批到达，只要帧头、长度、校验能对得上，就能准确切出一帧。

把解析逻辑拆出来看：

typedef enum { ST_IDLE = 0, ST_HEAD1, ST_HEAD2, ST_LEN, ST_DATA, ST_CRC_HI, ST_CRC_LO } FrameState; volatile uint8_t rx_buf[32]; volatile uint8_t rx_len = 0; volatile FrameState state = ST_IDLE; void ParseByte(uint8_t byte) { static uint8_t frame_buf[32]; static uint8_t frame_len = 0; static uint8_t data_cnt = 0; switch (state) { case ST_IDLE: if (byte == 0xAA) state = ST_HEAD1; else state = ST_IDLE; // 没见到帧头就继续等 break; case ST_HEAD1: if (byte == 0x55) state = ST_LEN; else state = ST_IDLE; // 第二个帧头不对，重新等 break; case ST_LEN: frame_len = byte; if (frame_len == 0 || frame_len > 16) { state = ST_IDLE; // 长度异常，复位 } else { data_cnt = 0; frame_buf[0] = frame_len; // 先存长度 state = ST_DATA; } break; case ST_DATA: frame_buf[1 + data_cnt] = byte; data_cnt++; if (data_cnt >= frame_len) state = ST_CRC_HI; break; case ST_CRC_HI: frame_buf[1 + frame_len] = byte; state = ST_CRC_LO; break; case ST_CRC_LO: frame_buf[1 + frame_len + 1] = byte; // 在这里做完整性校验 if (CheckFrame(frame_buf, frame_len)) { HandleCommand(frame_buf); // 校验通过，执行命令 } state = ST_IDLE; break; } }

这里有几个关键点。data_cnt >= frame_len的判断是把「长度字段本身的值」当作「命令字 + 数据的总长度」，所以frame_buf[1 + data_cnt]存取的是紧随长度后的命令字和数据，位置要对齐。frame_len == 0 || > 16的边界保护很重要，因为长度字段如果被干扰成一个很大的数，状态机会一直卡在 ST_DATA 等数据，把所有后续字节都吞掉，再也回不到 IDLE。我吃过这个亏：长度没做上限检查，一帧坏数据之后整个串口就废了，只能重启。现在无论哪条协议，长度上限检查必做。

串口中断里只要调ParseByte(byte)，一个字节进来状态机推进一步，不阻塞主循环，这是它和阻塞式HAL_UART_Receive()最本质的差别。

3.2 TIM PWM 配置：预分频、重装载值与频率选择

PWM 输出用 STM32 的通用定时器，以 TIM2 输出 PWM 控制电机驱动模块的使能信号为例。生成 PWM 的核心配置是预分频系数（PSC）和自动重装载值（ARR），这两个参数共同决定 PWM 频率和分辨率。

我用的是这种配置（以 72MHz 主频的芯片为例）：

// TIM2, 72MHz 时钟 // PWM 输出频率 = 72MHz / (PSC + 1) / (ARR + 1) // 目标是 20kHz，占空比分辨率 100 级 TIM_HandleTypeDef htim2; htim2.Instance = TIM2; htim2.Init.Prescaler = 35; // PSC = 35, 实际分频 = 36 htim2.Init.CounterMode = TIM_COUNTERMODE_UP; htim2.Init.Period = 99; // ARR = 99, 计数值 0~99 共 100 格 htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; HAL_TIM_PWM_Init(&htim2); // 通道1 配置 TIM_OC_InitTypeDef sConfigOC; sConfigOC.OCMode = TIM_OCMODE_PWM1; sConfigOC.Pulse = 0; // 初始占空比 0% sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH; HAL_TIM_PWM_ConfigChannel(&htim2, &sConfigOC, TIM_CHANNEL_1); HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);

PWM 频率为什么取 20kHz？两个原因。一是听觉上，20kHz 刚好在人耳听阈上限，电机不会发出那种让人烦躁的嘶嘶声；二是大多数电机驱动模块的开关频率上限就在 20~25kHz 附近，频率再高，驱动模块的桥臂开关损耗会明显增大，发热严重。如果把频率降到 1kHz，你会听到明显的蜂鸣声，那是线圈在磁场里机械振动的声，不是故障但很烦。

占空比分辨率是 100 级，即__HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 50)就是 50% 占空比。如果觉得 100 级不够细腻，比如低速时电机发抖，可以改 ARR 到 499，但 PWM 频率就会变成72MHz / 36 / 500 = 4kHz，落在人耳敏感区。所以频率和分辨率是权衡关系，我一般保持 20kHz、100 级，低速抖动靠最低占空比阈值处理。

设置占空比的具体代码：

void SetMotorDuty(uint8_t percent) { uint16_t compare; if (percent == 0) { compare = 0; // 完全停止 } else if (percent >= 100) { compare = 99; // 全速 } else { compare = (uint16_t)(percent * 0.99); // 等比例映射到 0~99 } __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, compare); }

为什么要percent * 0.99而不是percent？因为 ARR 是 99，映射到 0~99 时，100 会超出边界。你可以统一按percent * (ARR+1) / 100来算，这里直接乘 0.99 是走捷径，但逻辑要清楚：占空比 100% 时比较值 = ARR，不能多不能少。

3.3 命令到 PWM 映射：速度模式与位置模式

上位机发来的命令有两种使用场景，我在代码里做了区分：速度模式直接由占空比决定转速；位置模式则是「给定目标位置 → 启动电机 → 红外传感器判断到位 → 停止」。这两种模式对 PWM 的处理方式不一样。

速度模式的执行逻辑：

case CMD_SPEED: // data[0] 是目标速度 0~100 speed_target = frame.data[0]; if (speed_target == 0) { SetMotorDuty(0); } else { SetMotorDuty(speed_target); } break;

位置模式的执行逻辑要多一步判断，不能只看占空比：

case CMD_POS: // data[0..1] 是目标位置编号，比如 0 表示左限位，1 表示右限位 pos_target = frame.data[0]; motor_running = 1; // 置运行标志 SetMotorDuty(60); // 统一用 60% 占空比运行 break;

位置模式我统一用 60% 占空比，不走速度调节。原因是：位置控制的本质是「快速且平稳地到达目标」，速度太高过冲严重，速度太低到位太慢。60% 是电机带着轻负载刚好能稳定移动、又不会产生很大惯性过冲的经验值。如果你带的负载重或者导轨阻尼大，可以往上调到 70%~80%，这个要实际测。

电机是否停止，不靠延时——延时是靠不住的，因为负载不同、电压不同，同样的延时走过的距离完全不同。正确做法是把「是否到位」的判断交给红外传感器，这就是下一章的核心内容。

4. 红外线位置检测：传感器选型、去抖与到位判断

如果只有上位机和电机，这套系统的位置信息就是开环的，走到哪全凭「占空比 × 时间」这层纸糊的估算。负载变了、电压波动了，位置就漂了。所以位置检测必须靠物理反馈。我在这套系统里用的是对射式红外传感器，装在滑轨两端当限位用，原理简单、响应快、成本也低。

4.1 对射式还是反射式：为什么我选对射

红外传感器在电机位置检测上有两种主流选择：

这个场景我坚决站对射式。原因很简单：电机带动的是滑台或机械臂，结构运动时会经过精确的机械位置，用一个有固定开口的遮挡片去切光路，信号是陡峭的「有光/无光」二值跳变。反射式在这种场景下有个致命问题——如果被检测的机械结构表面是黑色氧化层或者反光的金属面，反射率不稳定，信号边缘会糊，有时候明明到位了却判成没到。

电路上注意：红外接收管工作在「无光照时导通、有光照时截止」的模式，所以输出逻辑和你想的可能是反的——我当时就因为这个翻了车：传感器输出默认低电平，遮住后变高电平。所以代码里判断到位时，是「读到高电平就是被遮住」，不是「读到低电平才有效」。这个极性问题看传感器模块的原理图就能确认，判断前先查清楚。

对射式传感器模块一般引出三根线：VCC、GND、OUT。OUT 接 STM32 的一个 GPIO，配置为输入模式。我习惯在模块输出和 GPIO 之间串一个 1kΩ 电阻，万一模块输出短路或者接错线，电阻能起到限流保护作用，不会直接烧掉 MCU 引脚。

4.2 GPIO 读取与软件去抖：防止误判

机械结构在运动过程中会有振动，电机启停瞬间尤其明显。振动会导致红外光路在遮与不遮之间快速抖动，这个时候如果直接读 GPIO 电平，会读到一串毛刺。去抖我用了两种方案叠加：

第一种是「多次采样，以同电平连续 N 次为准」，在定时器中断里做：

// 每 5ms 执行一次 void ReadIRSensor_Task(void) { uint8_t level = HAL_GPIO_ReadPin(IR_GPIO_Port, IR_Pin); static uint8_t stable_count = 0; static uint8_t last_level = 0; static uint8_t stable_level = 0; if (level == last_level) { stable_count++; if (stable_count >= 4) { // 连续 4 次一致，认为稳定 stable_level = level; stable_count = 4; // 饱和，避免溢出 } } else { last_level = level; stable_count = 0; } // stable_level 才是可信的挡光状态 }

这段去抖逻辑的关键是「连续」两个字。4 次采样间隔共 15ms，如果电机振动导致光路抖动频率低于 15ms 的脉宽，就能滤掉。注意stable_count必须做饱和处理（最多到 4），否则连续长时间同电平时计数器会溢出，产生不可预期的行为。这个去抖窗口是我根据电机振动频率试出来的，振动厉害的话可以改成连续 6~8 次，代价是响应变慢约 20ms，但位置检测场景完全不在乎这点延迟。

第二种是硬件消抖：在 GPIO 引脚对地并联一个 0.1μF 电容，和软件去抖配合使用。电容能吸收高频毛刺，软件能滤掉低频抖动，双保险。

### 4.3 位置判断的完整联动：从「碰到」到「停稳」 红外到位检测要和电机控制联动起来，需要有一个主状态机管理运行流程。位置模式执行时，流程是这样的： 1. 收到 CMD_POS 命令，记录目标位置，启动电机 2. 持续读取稳定后的 `stable_level`，和当前机械位置的挡光状态对比 3. 一旦检测到满足目标位置的电平，立即将 PWM 占空比置 0，同时清除 `motor_running` 标志 4. 向上位机回传一帧状态，告知已到位 主状态机的判断逻辑： ```c switch (motor_state) { case MOTOR_RUNNING_TO_POS: // 检测到目标位置的红外信号 if (stable_level == TARGET_LEVEL) { SetMotorDuty(0); // 先停电机 motor_running = 0; motor_state = MOTOR_STOPPED; SendStateFrame(pos_target, 1); // 回报已到位 } break; // 其他状态略 }

这里有一个顺序问题值得强调：必须先停 PWM，再回报状态。如果你先回报「已到位」，再停电机，中间的十几毫秒电机还在输出扭矩，机械结构可能往前再挪一点，虽然只有一两毫米，但设备精度要求高就出问题了。

还要考虑一种情况：如果电机没动，红外信号已经处于目标电平（比如上电时机械位置就停在目标位置），这时候不能再次执行位置命令把电机推出去。我一般在收到 CMD_POS 时先判断一次if (stable_level == TARGET_LEVEL)，成立就直接回报到位，不启动电机。上位机的逻辑也要配套：它不应在没收到「到位确认」前连续发相同的位置命令，否则下位机忙循环处理，串口容易堵。

5. 联调避坑：丢帧、抖动与红外误判的排查记录

整机联调时，真正的坑往往不在单点功能上，而在模块交界处。这一章写的五条踩坑记录，都是我在这个项目里实际遇到过的，每一条都花了不少时间才定位到根源，写出来供参考。

5.1 现象：上位机发的命令，STM32 偶尔不执行

设备一接上，第一次联调就发现上位机发送 10 次命令，下位机大概只执行 7 次，剩下的 3 次像被丢了一样没有任何响应。

原因：排查发现是上位机发送间隔太快。C# 里用循环连续sp.Write()发送帧，两条帧之间的间隔只有几毫秒，STM32 那边状态机还没把上一帧的 CRC 算完，下一个字节就到了，状态机在还没有回到 ST_IDLE 的时候就被新帧的帧头打断，整条帧直接作废。

解决：两个层面配合。上位机方面，命令发送改为逐条确认制——发一条命令，必须收到下位机回执帧后才发下一条。下位机方面，把帧解析放在定时器任务里处理而非串口中断里，中断只负责收字节，主循环统一解析，避免解析过程被下一个字节干扰。

从那以后，凡是涉及「命令-执行」的串口通信，我都默认走「发-回执-确认」的机制，单方面猛发就是给自己挖坑。

5.2 现象：红外误触发，机械结构还在半路就报到位

电机转到一半，大概在行程的三分之一处，上位机就收到了「已到位」的回报。

原因：把回传的逻辑做成「检测到红外信号变化就回报」，但电机启动瞬间，电机本身的电磁干扰引发红外接收模块输出抖动，加上机械振动，光路被短暂遮挡了一下，误判到位。当时红外模块的输出线直接从电机驱动模块旁边走过，电缆又没有屏蔽，电磁噪声全耦合进去了。

解决：先做纠偏——把红外信号的连接线改为双绞线，远离电机动力线，拉开 10cm 以上间距。再做软件改造——把之前介绍的去抖采样从 4 次提升到 8 次，并额外加一条「电机运行后至少 300ms 才开始检测红外信号」的门限，也就是给机械启动留出稳定时间。

红外信号受干扰的问题，本质上是要靠「物理隔离 + 时间窗口 + 多次采样」三层加起来才能解决，只靠软件去抖在这一类强干扰环境下是不敢说稳的。

5.3 现象：电机到位停止后，滑台会反弹一小段

电机到位后 PWM 置 0，红外信号也确实被遮住，但机械结构明显往后弹了一下，然后才稳住。

原因：电机是直接驱动负载的，没有加任何减速和刹车机制，运动中的惯性使得机械结构在停止瞬间把电机轴反带了一下。PWM 置 0 只是电机断电，不是刹车。

解决：用「短时反向制动」加「延时零占空比」。到位后先将 PWM 输出反转为 20% 占空比持续 50ms（让电机产生一个反向制动扭矩），再降为 0。这个 20% 的占空比要按负载调，调太大会把已经到位的结构往回推，太小又不够刹住。我当时的负载轻，20% 50ms 刚好。

注意：这里反向制动有风险——如果负载很重或惯性很大，反向扭矩可能损坏机械传动。轻负载设备可以直接做，重负载建议加机械刹或减速电机。我后来换用带减速箱的电机后，这段逻辑就删掉了，惯性本身被减速箱吃掉了。

5.4 现象：CRC 校验明明开了，命令还是被错误执行

有一次调试，CRC 计算逻辑已经写上去了，但用串口助手手动发帧时，个别帧校验算错了却还是被下位机执行了。

原因：检查HandleCommand()的调用位置后发现，我把执行写在了校验之前。代码顺序是先调用ParseByte()做状态推进，但在 ST_CRC_LO 分支里，先调用了HandleCommand(frame_buf)然后再CheckFrame()，于是校验还没做，命令就执行了。

解决：调整代码顺序，把CheckFrame()放在HandleCommand()之前，校验失败直接复位状态机，什么都不执行。这个问题现在看很蠢，但当时在代码里来回看了三遍都没发现，因为两行的顺序视觉上太接近。

写代码时的教训是：帧解析相关的逻辑，我后来统一按「校验通过才置处理标志、主循环统一执行」的路子写，绝不在中断或状态机内部直接执行业务逻辑。这样不仅顺序不会倒，也方便主循环增加其他联动。

5.5 现象：电机启动瞬间，整个板子复位

一给电机上电，单片机就重启，上位机连接中断，程序从头跑。

原因：电机启动瞬间电流很大，电源被拉低，单片机供电电压瞬间掉到复位阈值以下。红外传感器模块和单片机共用一路电源，电机一启动，传感器电压也跟着掉，全部掉到重启。

解决：电源分割——电机单独供电，单片机系统用独立稳压电源，两路电源共地但不共用输出。另外在电机驱动模块的电源端并联一个大容量电解电容（我当时用的 470μF，但这个值要看电机功率，太大会导致上电瞬间充电电流过大，反而更糟）。从这以后，凡是有电机的系统，我都先把电源分割弄清楚再写一行代码，电机的电和逻辑的电必须分开。

6. 参数整定与验证：用日志和示波器把系统调到可交付

到这步，功能和避坑都讲完了，讲讲怎么验证这套系统真的稳定。我的调试验证习惯是三步走：先是串口日志确认协议帧一收一发完全对齐，再上示波器看 PWM 输出波形的频率、占空比是否和预期一致，最后做连续运行测试，记录每一次位置命令的响应时间和到位精度。

串口日志是我排查问题时第一个打开的武器。C# 上位机每发送一帧，就在界面上打印一帧解析后的内容：命令字、数据、CRC 校验结果。STM32 端通过调试串口把收帧和回报的原始字节打出来，两边对着看，帧不匹配一眼就能发现。日志还记录了到位时间——从上位机点击按钮到下位机回报到位的时间间隔，这个值经常用来判断机械系统是否拖沓。

示波器的用处则在 PWM 调试上。占空比 50% 时，示波器应该看到 20kHz、高低电平各占一半的方波；占空比 20% 时，高电平只有 10μs。直接用肉眼从示波器确认占空比，比我在代码里猜值可靠得多。有一次报速度 30% 但电机不转，示波器一看发现实际占空比只有 8%，原因是电机驱动模块的导通阈值需要 15% 以上，代码里乘 0.99 的映射没问题，但 30 映射后为 29.7，再被驱动模块的接通阈值吃掉一部分，所以电机根本不振。这个现象在日志里完全看不出来，只有示波器能看到。

三步骤验证完成以后，我会做一次「连续 100 次位置往返测试」，记录每次是否成功到位、有没有丢帧、有没有误报。如果连续 100 次全部通过，才敢说系统可以交出去。如果中途失败哪怕一次，先记下失败时的环境条件——温度、线缆位置、电池电压（如果是电池供电），很多时候不稳定是供电电压边缘导致的，你多测几次电压临界点就找到了。

我后来的习惯是：任何一次命令执行异常，都先保留现场——把串口日志存文件、拍照示波器波形，然后才动手改代码。因为联调阶段的异常和正常运行的数据一样宝贵，丢了就真的只能靠玄学了。整套系统到今天已经跑了上百轮位置循环，红外检测和协议通信都能保持稳定。这套「上位机协议 + STM32 状态机 + PWM 调速 + 红外到位」的框架，后续无论是换电机类型、加传感器数量还是改成闭环步进，都是把对应模块填进去的事，底层的通信和状态机结构不用重写。

希望这篇拆解帮到正在做同类设备联调的你。

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