简介基于STM32F429的多摩川TS5668N21编码器读取程序完整源码包面向工业自动化、电机控制与精密定位领域的嵌入式软硬件开发者。工程围绕ADM485RS-485半双工通信协议展开涵盖STM32CubeMX引脚分配、时钟树与UART参数配置RTS方向控制位设置以及A/B相正交解码计数、Z相零位重置和霍尔信号检测逻辑代码针对编码器上电初始化时间与多任务环境中的脉冲丢失风险加入了等待稳定与中断锁存机制。压缩包共263个文件以h/c源文件核心驱动与硬件抽象层库代码、s汇编启动文件、o目标文件、axf/hex烧录产物及uvprojx工程配置为主整体大小4.79MB目录结构清晰导入Keil后可直接编译并部署至STM32F429开发板实测。方案采用官方硬件抽象层库编写枚举状态清晰便于二次开发与平台迁移。已有4833人学习浏览适合需要快速复用多摩川编码器读取方案、借鉴ADM485协议在STM32上的UART实现或排查正交解码与脉冲丢失问题的开发者。1. 多摩川编码器读取伺服调试台上那个“绝对位置”终于不丢了在机器人关节模组的调试现场增量编码器最让人头疼的莫过于断电后再上电机械臂的零点位置全部丢失每次都得手动寻零。换上多摩川绝对式编码器后位置信息被存进编码器内部的齿轮组和圈数寄存器掉电不丢数据上电即读即用。这篇笔记讲的就是基于 STM32 读取多摩川 TS5668N21 编码器的完整方案覆盖了硬件接线、串行协议解析、核心代码逐段拆解以及我在实际调试中踩过的三个大坑——位置数据乱跳、多圈计数值归零、CRC 校验失败。适合正在做伺服驱动、关节模组或运动控制平台手里刚好有一颗多摩川编码器想快速跑通读取逻辑的开发者。2. 硬件链路与通信协议TS5668N21 的帧格式和 RS485 收发电路2.1 引脚定义与差分信号接线方案TS5668N21 是典型的绝对式多圈编码器单圈 17 位分辨率多圈 16 位输出接口走 RS485 差分串行协议。它不像增量编码器那样输出 A/Z/B 脉冲而是通过两根差分线DATA 和 DATA-以半双工方式返回绝对位置数据。STM32 的 UART 引脚是单端 TTL 电平没法直接和差分总线对接所以中间必须加一颗 RS485 收发器。我这边用的是 MAX34883.3V 供电最高支持 10Mbps完全覆盖 TS5668N21 的 2.5Mbps 通信速率。接线方式如下DATA 接收发器 A 端非反相输入DATA- 接收发器 B 端反相输入收发器 RO 接到 STM32 的 RX 引脚PA10收发器 DI 接到 STM32 的 TX 引脚PA9收发器 RE/DE 合并后接一个 GPIOPA8用于控制收发方向RS485 是半双工总线同一时刻只能发送或接收。发送命令帧之前要把 DE 拉高命令发完后必须立刻把 DE 拉低不然编码器返回的数据会被自己的发送电路短路掉。这个方向切换的时序如果控制不好轻则丢帧重则引发总线冲突后面避坑章节会专门展开。2.2 串行通信协议帧结构拆解多摩川编码器的串行协议是固定的主从问答模式主机STM32发一帧命令编码器返回一帧数据。命令帧通常是一个字节例如 0x00 代表“读绝对位置”有的型号还支持 0x01 读加速度、0x02 读转速等扩展命令。TS5668N21 的标准响应帧结构是 48 位数据拆开来看位段长度含义单圈位置高 4 位4 bit圈内角度最高有效位单圈位置低 13 位13 bit圈内角度低有效位与高 4 位合并成 17 位多圈计数值16 bit断电不丢失的圈数范围 0~65535校验字节8 bitCRC-8校验前面 40 位数据这里有个容易误读的地方单圈 17 位不是均匀分布在 0~131071 之间前 4 位和后 13 位在字节流里不是连续排列的。接收端要把 40 位完整数据拼成一个 uint64_t再按位段掩码提取。CRC-8 的生成多项式是 0x31x^8 x^5 x^4 1初始值为 0xFF和常见的 CRC-8/MAXIM 不一样实现时不要直接抄网上的表驱动代码多项式算错的话每一帧都会校验失败。2.3 波特率、帧间隔与采样时序TS5668N21 支持两种主流波特率2.5Mbps 和 1Mbps。2.5Mbps 下单帧响应时间大约 20 微秒适合对位置采样频率要求高的场景比如伺服电流环的前馈1Mbps 的兼容性更好很多第三方调试工具默认用这个速率。我实际用 2.5MbpsSTM32F405 的 USART 时钟经过分频后刚好能配出较接近的波特率误差在 0.2% 以内通信很稳。命令帧发送完毕后编码器大约需要 15~20 微秒准备数据这个等待时间在 GPIO 翻转之后要用延时函数卡住不能直接进接收等待。否则会把编码器还在准备数据的空闲电平误判成帧起始位导致整帧移位。具体时序是我拿示波器实测的这在代码注释里有标注。3. 核心代码逐段拆解从 UART 接收中断到单圈角度解析3.1 UART 底层配置DMA 空闲中断接收 6 字节TS5668N21 的响应帧固定 6 个字节40 位数据 8 位 CRC长度不变这是用 DMA 空闲中断接收的理想场景。初始化代码如下void tamagawa_uart_init(void) { // 使能 USART1 时钟和 GPIOA 时钟 __HAL_RCC_USART1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); // PA9 TX, PA10 RX, 复用功能 AF7 GPIO_InitTypeDef gpio {0}; gpio.Pin GPIO_PIN_9 | GPIO_PIN_10; gpio.Mode GPIO_MODE_AF_PP; gpio.Pull GPIO_NOPULL; gpio.Speed GPIO_SPEED_FREQ_VERY_HIGH; gpio.Alternate GPIO_AF7_USART1; HAL_GPIO_Init(GPIOA, gpio); // 2.5Mbps 波特率8 位数据位无校验1 位停止位 UART_HandleTypeDef huart {0}; huart.Instance USART1; huart.Init.BaudRate 2500000; huart.Init.WordLength UART_WORDLENGTH_8B; huart.Init.StopBits UART_STOPBITS_1; huart.Init.Parity UART_PARITY_NONE; huart.Init.Mode UART_MODE_TX_RX; huart.Init.HwFlowCtl UART_HWCONTROL_NONE; HAL_UART_Init(huart); // 配置 DMA 接收USART1_RX 对应 DMA2 通道 7 或 DMA1 通道按芯片型号查表 __HAL_LINKDMA(huart, hdmarx, hdma_uart_rx); HAL_UART_Receive_DMA(huart, rx_buffer, 6); // 使能空闲中断HAL 库需要在底层回调里做 __HAL_UART_ENABLE_IT(huart, UART_IT_IDLE); }代码里最关键的还是波特率计算。2.5Mbps 在 F4 系列上用的是 84MHz 的 APB2 时钟源USARTDIV 84000000 / 4000000 21最终分频得到 2.5Mbps。如果换成 72MHz 主频的 F1 系列2.5Mbps 配出来误差接近 1.4%那就建议改用 1Mbps 档位。这个参数在移植到别的型号开发板时要特别注意。方向控制 GPIO 的初始化很简单就是普通推挽输出初始状态拉低保证默认处于接收态。我习惯了把方向控制放在发送函数里做掉而不是单独暴露出去避免上层调用者漏拉引脚。3.2 帧接收状态机与 CRC 校验实现DMA 接收满 6 字节后触发 DMA 传输完成中断但更稳定的做法是用空闲中断来判断一帧结束。因为编码器响应帧之间有一个明显的总线空闲期即使 DMA 只收到 5 个字节也算作一帧结束方便发现断帧异常。空闲中断的响应逻辑如下void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); HAL_UART_DMAStop(huart1); // 停掉当前 DMA防止数据覆盖 uint8_t len 6 - __HAL_DMA_GET_COUNTER(huart1.hdmarx); // 实际收到的字节数 if (len 6) { frame_complete_flag 1; // 6 字节完整帧交给解析函数处理 memcpy(temp_frame, rx_buffer, 6); } else { error_count; // 断帧计数用于通信质量统计 } HAL_UART_Receive_DMA(huart1, rx_buffer, 6); // 重新挂载 DMA } }这段代码的逻辑说明DMA 计数器在接收启动时是 6每收一个字节减一所以6 - 剩余值就是实际接收长度。如果编码器返回的数据没有填满 6 字节说明帧对齐出了问题此时自增 error_count 用于统计通信丢帧率。要特别注意的是DMA 停止和重新挂载之间不能有被其他中断打断的窗口期否则总线上的下一条命令响应会覆盖未读走的数据。我习惯在这个中断里直接关全局中断 1~2 个周期代价极小换的是稳定性。帧解析函数负责拼接数据并校验 CRCuint8_t tamagawa_parse_frame(uint8_t *frame, uint32_t *single_turn, int32_t *multi_turn) { // 1. 拼出 40 位有效数据 8 位 CRC共 48 位 uint64_t raw 0; for (int i 0; i 6; i) { raw (raw 8) | frame[i]; } // 2. 取出 CRC8和前面的 40 位分开 uint8_t crc raw 0xFF; uint64_t data raw 8; // 高 40 位是有效数据 // 3. CRC 校验多项式 0x31初始值 0xFF uint8_t calc 0xFF; for (int i 0; i 5; i) { calc calc ^ (frame[i]); for (int bit 0; bit 8; bit) { if (calc 0x80) { calc (calc 1) ^ 0x31; } else { calc calc 1; } } } if (calc ! crc) { crc_error_count; return 0; // 校验失败丢弃该帧 } // 4. 按位段提取单圈 17 位和多圈 16 位 // data 高 4 位是单圈的第 13~16 位data 低 13 位是单圈的低位 *single_turn (uint32_t)((data 27) 0x0F) 13; // 高 4 位 *single_turn | (uint32_t)(data 0x1FFF); // 低 13 位 *multi_turn (int32_t)((data 13) 0x7FFF); // 16 位中的低 15 位 if (data (1ULL 28)) { *multi_turn | 0x8000; // 补高位得到完整 16 位注意符号 } return 1; }参数说明single_turn 输出 0~131071 的圈内位置码相当于把一圈 360 度切成了 131072 份multi_turn 输出带符号圈数正数代表正向转过的圈数。这里的位段偏移是我对着数据手册的位序图逐 bit 核对过的不同型号的编码器比如 TS5700 系列位段分布会不一样复用代码前务必再查手册。3.3 单圈位置到机械角度的换算与坐标系归一化拿到 17 位原始码之后如果直接把 raw 值当角度用后续做位置环就很别扭。需要换算成统一的 0~360.0 度浮点数或者换算成以 1/1000 度为单位的整数。换算公式很简单float tamagawa_angle_deg(uint32_t single_turn) { // 17 位分辨率每 LSB 对应的角度 const float lsb_deg 360.0f / 131072.0f; return (float)single_turn * lsb_deg; }浮点计算在 F4 上有 FPU 加速每帧一次换算的开销可以忽略但在 F1 系列上就要考虑用定点算法替代否则会拖慢中断处理时间。实际工程里我更推荐输出整数角度值单位是 0.001 度计算方法为single_turn * 360000 / 131072用 64 位中间变量存一次乘法的中间结果避免 int32 溢出。这一层换算被单独封装成一个函数除了做除法还负责把角度映射到 [0, 360) 区间内消除掉编码器零点与机械零点的固定偏移。偏移量通常在设备出厂标定时写入 EEPROM换算函数里直接减掉就行。4. 调试记录与避坑指南定位“读出来数据乱跳”的三个真凶4.1 现象电机静止位置数据在几个相邻码值之间抖动伺服电机静止时编码器输出理论上应该是恒定的单圈位置码但实际调试时发现数据会在相差几十个 LSB 的范围内来回跳。一开始怀疑是编码器本身精度问题用示波器量了 DATA / DATA- 的差分波形发现信号幅值只有 0.8V 左右明显偏低。原因RS485 总线末端没有接 120 欧姆匹配电阻信号在线上反射导致波特率 2.5Mbps 下数据眼图闭合。解决方式是收发器 A/B 之间并联一颗 120 欧姆电阻同时尽量缩短编码器线缆长度我这边从 12 米减到 5 米后抖动立刻消失。还有一点容易被忽略手拧的接线端子如果接触电阻偏大同样会造成信号衰减最好压接端子或者干脆焊接。4.2 现象掉电再上电多圈计数归零绝对式编码器的卖点就是掉电不丢圈数但我遇到过一次断电重启后 multi_turn 变成 0 的情况而且只发生在快速正反转切换之后。原因排查到最后发现问题不是编码器丢数据而是我的读取时序不对。编码器内部的多圈计数在断电前如果正处于更新窗口的临界点位置数据的多圈段会被读成中间状态。解决方式是在关闭伺服电源前先把编码器的“预置”命令发一遍0x03让内部计数状态机稳定下来再断电就再也没复现过归零问题。这个预置命令本质上是把多圈计数值锁定到当前机械位置对应的寄存器里属于出厂校准的一部分。4.3 现象CRC 校验总是失败换上另一颗同型号编码器后一帧都过不了校验示波器看波形又完全正常。原因出在波特率匹配上。新编码器的固件版本默认为 1Mbps而我这边 STM32 配置的是 2.5Mbps。RS485 的差分电平在两种波特率下波形都正常所以示波器看不出异常但数据位采样率完全不同。解决方式是读编码器铭牌上的速率标识然后用调试工具先发一遍设置波特率的命令0x05把编码器切到 2.5Mbps 后重新上电CRC 校验立刻恢复正常。4.4 排查工具用逻辑分析仪离线解析帧结构如果怀疑协议解析问题最直接的办法是用逻辑分析仪抓 DATA 引脚的单端电平——注意 RS485 是差分信号逻辑分析仪只能接 A 端对 GND 的电压波特率设为 2.5Mbps 就能还原出 UART 帧。拿到原始波形后在解析软件里对照 0x00 命令和返回的 6 字节逐 bit 核对位段分布就能确定是协议理解错误还是代码位掩码写错。5. 工程化拓展多圈计数同步、零位标定与超速保护机制5.1 多圈计数值的软件同步策略TS5668N21 的多圈计数是编码器内部维护的理论上读取出来就是真实值但实际使用中存在一个时序问题如果单圈位置恰好跨过 0 度时读取多圈内部的多圈递增和位置读取是异步的可能读到“位置接近 0 但圈数还没加 1”的组合。解决方式是连续读两帧如果第一帧的单圈值接近 360 度第二帧接近 0 度并且圈数没有递增就手动给 multi_turn 加 1。这个补偿逻辑在高速旋转场景下很重要否则伺服做位置闭环时会有累计误差。代码实现上其实就是一个简单的分支判断if (first_angle 350.0f second_angle 10.0f) { multi_turn_adjust; // 软件同步补偿 }实际项目中我会把这个补偿值写进一个环形缓冲而不是直接修改编码器返回的原始圈数这样出现极端情况时还能回溯排查。5.2 机械零点标定的完整流程设备每次装配后机械零点和编码器零点之间必然有固定偏差。标定流程如下手动转动电机到机械零位通常用治具顶住定位销读取此刻的单圈角度值记为 zero_offset把 zero_offset 写入 STM32 的 EEPROM 或者 Flash 模拟存储区每次上电初始化时读回 zero_offset在角度换算函数里减去这个标定值建议存两份一份放 STM32一份放编码器的 EEPROM 扩展区如果有。单一存储介质失效时另一份还能兜底。我踩过的坑是只存了 STM32 侧结果刷固件时不小心擦了 Flash整个零点丢了又重新装了一轮机械治具。5.3 通信故障保护与看门狗策略编码器通信线在运动设备上属于高风险环节插头松动、线缆折断随时可能发生。我这边加了双重保护第一层是软看门狗每次收到合法帧就清零一个计数器如果 5ms 内没有收到任何合法帧立刻将电机状态切换为报错停不让位置环继续输出第二层是错误帧统计CRC 错误连续超过 10 次就触发报警码 0xE100提示产线检查编码器线缆。看门狗定时器用的是硬件 IWDG超时时间设 50ms。注意 IWDG 一旦启动就不可停止必须在主循环里定期喂狗不能放在中断里喂否则死循环时中断还能继续跑看门狗永远不生效。这个是我早期项目里真实的血泪教训。6. 二次开发思路从单机读取程序改造成带预测滤波的伺服位置前端6.1 提高有效读取频率的关键手段TS5668N21 在 2.5Mbps 下完整响应周期约 150 微秒折算下来每秒最多读 6600 帧理论上完全满足 1kHz 位置环的采样需求。但实际程序如果每帧之间通过阻塞延时等待响应有效频率会掉到 2kHz 以下。优化方向是把发送和接收彻底解耦命令发送用定时器触发的 DMA 完成接收则完全走空闲中断主循环只消费最新的一帧数据。我一般会在主循环里只处理最新帧不追求每一帧都处理。位置环的控制周期是 1ms编码器响应的真实刷新在 0.15ms 到 0.2ms 之间这期间多读的 5~6 帧数据可以用于滤波和预测而不是全丢。6.2 一阶低通滤波与速度前馈预测编码器原始角度值直接进入位置环噪声会通过微分放大表现在电流上就是高频抖动。常见的做法是叠加一阶低通滤波float angle_filtered alpha * angle_new (1.0f - alpha) * angle_old;alpha 系数取 0.2~0.4具体要看机械刚性和负载。刚才提到的高频读取显得特别有价值位置环每次运行前可以先做速度估计再按速度预测出下一拍的角度补偿掉控制周期内的采样延迟。做法是先取最近两帧的角度差除以时间戳差得到角速度再用predicted_angle angle_now speed * control_period做前馈。速度前馈能显著降低跟踪误差。我用这个方案做转台伺服联动的时候1kHz 位置环的追踪误差从 0.3 度降到了 0.05 度以内。6.3 从查询模式升级到中断驱动的事件订阅机制如果项目里不止一个编码器或者同一颗编码器数据要同时供给位置环和速度环那建议升级成事件订阅机制。接收中断解析出新位置后写入一个双缓冲的 ring buffer不同控制环各自读取自己关心的数据切片。核心原则是不要让 UART 接收中断做除了解帧以外的任何计算angle 换算和过滤全放到主循环。这样即使角度换算逻辑改坏了通信链路本身还是稳定的便于定位故障边界。改造到这一步这颗多摩川编码器基本就完全融入伺服系统了。我个人后来每次接新编码器都会强制自己走一遍这套流程先画帧结构图再看逻辑分析仪波形最后才写代码——顺序反了后面大概率要返工换线重查。希望这次拆解能帮你少走几步弯路欢迎下载源码照着跑一遍再改。本文还有配套的精品资源点击获取
