简介STM32L151平台下的HART协议驱动源码面向工业现场仪表与控制系统开发者解决基于STM32L151实现HART通信的底层协议处理问题。源码共5个文件含4个C源文件与1个头文件压缩包仅9KB结构紧凑。各C文件分工明确覆盖命令解析、主变量读写、底层收发及IO模拟等模块注释中给出了0#读标识码、3#读主变量电流、6#置随选地址、40#电流模式切换、41#自检、42#复位等常用HART命令的调用思路便于理解协议交互流程。适合有一定嵌入式基础、需要快速集成HART功能或学习协议栈实现的开发者按注释可较顺畅移植到其他STM32系列缩短开发调试周期。已有2118人浏览学习对仪表通信类设计具有直接参考价值。 做工业仪表这几年HART协议是一个绕不开的东西。特别是低功耗两线制仪表主控选来选去基本就是 MSP430、STM32L1 系列这类。ST 的 STM32L151 这颗料Cortex-M3 内核主频 32MHzFlash 最大 512KB关键是低功耗表现不错在 4-20mA 两线制变送器里非常常见。最近整理项目资料把 STM32L151 平台上实现 HART 协议从底层驱动到协议栈的完整源代码思路梳理了一遍。这篇东西适合准备入手 HART 仪表开发的工程师或者在学校做相关课题、需要在真实硬件上跑通协议栈的同学参考。1. 先搞清楚HART在物理层到底干了什么HART 全称是 Highway Addressable Remote Transducer本质是在传统的 4-20mA 模拟电流信号上通过频移键控FSK技术叠加数字通信信号。简单说一根两根线既要传模拟电流又要传数字数据两者互不干扰。数字信号用的是 Bell 202 标准逻辑 1 对应 1200Hz逻辑 0 对应 2200Hz波特率固定 1200bps。信号幅度是有要求的一般峰峰值在 0.5V 左右叠加在电流环路上。这个幅度有讲究太小了解调芯片容易误判太大了又会影响模拟信号的精度现场仪表调试的时候经常在这里出问题。从单片机角度看HART 的物理层实现有两条路线外挂调制解调芯片比如 AD5700、HT2015、DS8500 这类MCU 只需要通过 UART 接口跟芯片打交道协议栈只管收发物理层完全交给芯片。用 MCU 内部资源模拟调制解调定时器输出特定频率方波ADC 采样输入信号做解调。这个方法省成本但占用 CPU 资源而且稳定性调试起来比较费劲。我自己的项目用的是 AD5700 这颗芯片这是目前工业仪表里用得最多的方案外围元件少而且自带载波检测功能功耗也低。代码上只需要关注 UART 收发和 RTS/CTS 控制逻辑省去了大量算频率、搞滤波的底层工作。但要注意一点AD5700 这种芯片内部虽然有正弦波整形电路输出波形质量跟电源纹波、参考电压稳定性关系很大。我在调试中发现如果给 AD5700 供电的 LDO 纹波偏大解调出来的波形边沿抖动就很明显误码率直线上升。后面加了 10uF 钽电容和 0.1uF 陶瓷电容组合滤波后波形才稳定下来。这是硬件层面的坑但会直接影响协议栈的稳定性。2. STM32L151与HART通信的硬件搭配STM32L151 的 USART 外设支持到 9 位数据位这在 HART 协议里非常关键。HART 数据帧的每个字节是 11 位——1 位起始位8 位数据位1 位奇偶校验位1 位停止位。如果有第二个停止位那就是 12 位一帧AD5700 的数据手册建议用两个停止位这个细节在后面做帧解析的时候要记在心里。2.1 硬件连接与信号调理AD5700 与 STM32L151 的接口连接相对简单核心信号就几根线UART_TX - AD5700 的 TXD 输入UART_RX - AD5700 的 RXD 输出GPIO - AD5700 的 RTS 引脚用于切换收/发模式GPIO - AD5700 的 CD 载波检测引脚检测总线上是否有其他主机在通信有一点特别重要AD5700 的 RTS 脚逻辑定义跟 RS485 的方向控制类似高电平是接收模式低电平是发送模式。初始化后要把 RTS 拉高否则 AD5700 处于发送模式会一直往 4-20mA 环路上灌信号导致整个回路无法正常工作。我见过好几个同事第一次调板子程序卡在死循环里查不到原因最后发现是 RTS 初始状态不对。USART 配置参数大致如下USART_InitTypeDef USART_InitStructure; USART_InitStructure.USART_BaudRate 1200; USART_InitStructure.USART_WordLength USART_WordLength_8b; USART_InitStructure.USART_StopBits USART_StopBits_2; USART_InitStructure.USART_Parity USART_Parity_Odd; USART_InitStructure.USART_HardwareFlowControl USART_HardwareFlowControl_None; USART_InitStructure.USART_Mode USART_Mode_Rx | USART_Mode_Tx;1200bps 这个波特率是 HART 协议强制的不能随便改。奇校验也是协议规定的。用两个停止位是为了跟 AD5700 的时序匹配协议本身的帧格式里虽然没强制但大多数仪表都是这么配的。USART 的中断优先级建议配到最高档因为 1200bps 下每个字节的时间大约 9.17ms看起来很长但如果系统里有别的中断频繁抢占UART 接收溢出还是会发生。我实际测试过当主循环里有 Flash 擦写操作时如果不把 UART 中断优先级提高偶发性的丢字节问题很难查。2.2 调制解调芯片的选型建议如果项目里不想用 AD5700市面上可选的芯片还有 TI 的 DS8500、国内一些厂商的兼容方案。选型时主要看几个参数工作电压范围、静态电流、载波检测输出的延迟时间。对于两线制仪表整个系统的静态电流预算通常控制在 3.5mA 以内所以调制解调芯片自身的功耗是硬指标。DS8500 的引脚跟 AD5700 不完全兼容外围电路也有差异尤其是时钟电路。AD5700 可以用外部晶体也可以直接输入方波时钟DS8500 的时钟要求又不太一样。不要直接拿 AD5700 的硬件设计套 DS8500看起来功能一样实际用起来坑不少。软件驱动层建议做一层抽象把芯片相关的寄存器操作、时序控制封装成独立的模块。这样即使硬件方案变了协议栈部分完全不用动。下面是我在项目里定义的驱动抽象接口typedef struct { void (*init)(void); void (*set_mode)(HART_OP_MODE mode); // 发送 or 接收 uint8_t (*get_cd)(void); // 获取载波检测状态 void (*reset)(void); } HART_PHY_Driver;这套接口虽然简单但把底层的 GPIO 操作、延时逻辑和上层的协议数据处理隔离得很干净。同事后来把平台换成了 MSP430协议栈代码移植过去只花了半天时间主要就是重写了这个驱动接口。3. HART协议栈的代码架构与核心实现HART 协议栈分三层数据链路层、命令层、应用层。数据链路层负责组帧、拆帧、校验、冲突检测命令层负责处理具体的命令字比如读变量、写量程、读标识、进入/退出突发模式应用层对应具体的业务逻辑比如一个温度变送器应用层就是温度采集和工程量转换。单片机资源有限协议栈不可能做得像 PC 上那么庞大。我的做法是做一个精简但有完整功能的状态机主要覆盖 HART 规范里最常用的部分。3.1 状态机与帧格式解析HART 的主从通信模式很简单主机发命令帧从机回响应帧。从机侧的状态机就几个状态空闲、接收完成、处理命令、发送响应。在突发模式Burst Mode下从机还会周期性自动发送数据。typedef enum { HART_STATE_IDLE, HART_STATE_RX_COMPLETE, HART_STATE_PROCESSING, HART_STATE_TX_DONE } HART_State;HART 帧格式是有标准的。日常调试时最常用的是短帧格式前导码0xFF通常 5 个字节、定界符、地址字节、命令字节、字节计数、数据区、校验和。长帧格式多了一个 5 字节的地址区用于轮询地址寻址。typedef struct { uint8_t preamble[5]; // 前导码0xFF uint8_t delimiter; // 定界符 uint8_t address; // 短帧地址 uint8_t command; // 命令号 uint8_t byte_count; // 数据长度 uint8_t data[32]; // 数据区 uint8_t checksum; // 纵向奇偶校验 LRC } HART_Frame;注意校验和的计算方法是 XOR不是 SUM。这是新手最容易搞错的地方。HART 的校验是把定界符到数据区最后一个字节的所有字节按位异或结果作为校验字节。用累加和去算协议栈永远通不过。命令处理用一个分发表表里放命令号和对应的处理函数指针这样加新命令只需要在表里加一项不用改主逻辑。const HART_CommandEntry hart_cmd_table[] { { 0, CMD_ReadUniqueIdentifier }, { 1, CMD_ReadPrimaryVariable }, { 2, CMD_ReadLoopCurrentAndPercentRange }, { 3, CMD_ReadDynamicVariablesAndLoopCurrent }, { 6, CMD_WritePollingAddress }, { 15, CMD_ReadDeviceInformation }, { 16, CMD_ReadFinalAssemblyNumber }, { 17, CMD_WriteMessage }, { 33, CMD_ReadDeviceVariables }, { 48, CMD_ReadAdditionalDeviceStatus }, };这种表驱动的方式代码量不大但扩展性非常好。现场仪表客户经常要求增加私有命令比如修改阻尼时间、修改小信号切除点直接在表里加一项就完事。3.2 发送与接收的底层驱动UART 收数据用的中断方式。HART 一帧最长不超过 30 个字节在 1200bps 下大约耗时 270ms 左右。如果用状态机查询方式也能做但 MCU 在接收期间被占住没法干别的活了所以我用的是中断 环形缓冲。#define HART_RX_BUF_SIZE 64 volatile uint8_t hart_rx_buf[HART_RX_BUF_SIZE]; volatile uint8_t hart_rx_head 0; volatile uint8_t hart_rx_tail 0; void USART2_IRQHandler(void) { if (USART_GetITStatus(USART2, USART_IT_RXNE) ! RESET) { uint8_t data USART_ReceiveData(USART2); uint8_t next (hart_rx_head 1) % HART_RX_BUF_SIZE; if (next ! hart_rx_tail) { hart_rx_buf[hart_rx_head] data; hart_rx_head next; } USART_ClearITPendingBit(USART2, USART_IT_RXNE); } }发送部分有一个容易被忽略的点HART 发送完最后一个字节后不能立刻把 RTS 切回接收模式要等一个字节的时间让移位寄存器把数据完全送出去。否则最后一个字节会被砍掉一半对端解析直接报错。这个延时不能省我最初调试时就吃过这个亏从逻辑分析仪上看发送波形最后一个脉冲明显短了一截。发送完成标志用 USART_IT_TC 而不是 USART_IT_TXE。因为 TXE 只表示数据已进入移位寄存器但还没发完TC 才是真正发送完成。延迟时间大约 2ms在 1200bps 下刚好是一个字节的时间。切回接收模式后再延时 5ms 左右保证对端响应帧不会在切换瞬间丢失。3.3 命令层实现与报文处理命令层是协议栈里真正干活的模块。以最常用的命令 3读动态变量和回路电流为例从机收到这个命令后需要把当前的过程值、单位、电流百分比和模拟电流值按 HART 浮点数格式填进响应帧。HART 的浮点数不是 IEEE 754 标准。它用的是 32 位浮点数但字节序是高位在前大端模式而且 NaN、Infinity 等特殊值的定义跟 IEEE 754 不完全一样。直接用 C 语言的 memcpy 拷贝 float 数据到发送缓冲区会导致字节序不对对方解析出来完全是乱码。我自己写了一个浮点转换函数void hart_float_to_die(uint8_t *buf, float value) { uint8_t tmp[4]; memcpy(tmp, value, 4); buf[0] tmp[3]; buf[1] tmp[2]; buf[2] tmp[1]; buf[3] tmp[0]; }发送响应帧时处理完命令后把数据填入发送缓冲区计算 XOR 校验启动发送。整个流程要在主循环里按状态机的节奏跑不能在中断里做复杂的浮点运算否则会拖垮实时性。主循环里的核心调度逻辑可以简化成while (1) { // 轮询UART接收状态 if (hart_rx_head ! hart_rx_tail) { uint8_t byte hart_rx_buf[hart_rx_tail]; hart_rx_tail (hart_rx_tail 1) % HART_RX_BUF_SIZE; hart_fsm_process_byte(byte); } // 如果有完整帧进入命令处理 if (hart_state HART_STATE_RX_COMPLETE) { hart_process_command(); } }这样协议栈整体占用的资源非常小RAM 主要就是两个环形缓冲和协议栈上下文结构体。整个协议栈加上驱动Flash 占用大约 6KBRAM 占用不到 1KB对 STM32L151 来说绰绰有余。4. 常见问题与排查技巧实录HART 协议调试的难点不在协议本身而在物理层。协议报文如果解析不对最多是你代码 bug好排查。但物理层信号不对那就是示波器、信号发生器、逻辑分析仪一起上还得跟现场仪表配合查问题比较折腾。4.1 通信完全不通时怎么查第一步先确认硬件有没有工作。用示波器抓 AD5700 的输出引脚在发送模式下应该能看到 1.2V 峰峰值左右的正弦波接收模式用信号发生器注入 1200Hz 或 2200Hz 的正弦波看 CD 引脚有没有拉低。如果 CD 引脚不动作大概率是信号幅度不够。AD5700 的载波检测阈值大概在 80mV 有效值左右。用函数信号发生器输出 1Vpp 正弦波直接耦合进去还是检测不到那就要检查 AD5700 的晶振频率对不对——AD5700 对时钟精度比较敏感晶体必须是 2.4576MHz不能随便换。我见过有人用 4MHz 晶振代用以为 MCU 那边用定时器分频就行结果完全没输出芯片内部锁相环工作不了。第二步检查 MCU 和 AD5700 之间有没有数据。连上调试器在 UART 中断里打一个断点用串口助手往 AD5700 发数据看能不能进中断。如果中断不进检查 GPIO 复用功能是否配置成了 USART。4.2 偶发性误码和帧错误如果通信大部分时间正常偶尔报错先查波形。用示波器看 UART_TX 引脚上的波形重点看起始位有没有明显的抖动。HART 信号是叠加在 4-20mA 回路上的如果回路里有其他设备产生纹波会干扰信号。示波器上如果看到波形边缘有毛刺需要增加滤波电容或者调整 AD5700 的输出幅度配置。还有一个容易踩的坑是 UART 的采样点。HART 波特率 1200bps理论上一个位时间约 833usSTM32L151 的 UART 采样一般在位时间的中点。如果系统时钟偏了或者外部晶振精度不够采样点偏移会导致边缘误判。查这个问题最笨也最有效的方法是发一串 0x55二进制 01010101用示波器观测每一位的宽度然后估算实际波特率跟配置之间的误差。当波特率误差超过 2% 时HART 通信基本就会频繁出错。这个时候要检查 MCU 的系统时钟配置和外部晶振的实际频率。STM32L151 如果用的是内部 RC 振荡器精度通常不够直接驱动 HART 通信建议用外部晶振或者经过校准的 HSI。4.3 与手持器连接时的总线竞争问题HART 总线是半双工可以挂手持器如 Emerson 的 475和多个主机。如果从机程序逻辑有问题在主机发送命令期间从机抢先发送响应就会造成总线冲突。调试时如果发现手持器一连上通信就卡死多半是 RTS 引脚切换时序的问题。从机收到命令帧后应该在确认地址匹配后再启动发送。地址不匹配时绝对不能在总线上有任何动作。另外从机发送完响应后要在 10ms 内释放总线。这个时间窗口如果太长手持器会认为总线繁忙直接报超时错误。一个可靠的策略是void hart_start_response(void) { // 确认当前没有其他主机正在通信 if (PHY_GetCD() 0) { // CD为低表示总线空闲可以发送 PHY_SetMode(HART_MODE_TX); // 发送前延时确保总线切换完成 delay_ms(2); // 填充发送缓冲区和校验 hart_build_response_frame(); UART_SendBuffer(hart_tx_buf, hart_tx_len); } }这里 CD 引脚的配合使用非常关键。AD5700 的 CD 引脚在检测到总线上有 FSK 信号时会拉低表示总线忙。如果忽略这个信号强行发送就会跟主机的命令帧重叠产生冲突。我实测过带 CD 检测的协议栈和去掉 CD 检测的版本在手持器连上去的稳定性差距很明显——去掉 CD 检测的版本大约 5 次命令里就有一次失败。4.4 浮点数据显示异常如果收到的数据能通但读出来的数值不对大概率是浮点格式转换的问题。HART 的浮点数是大端模式STM32 默认是小端。直接在内存里拷贝 float 数组会导致高字节和低字节顺序颠倒。另外 HART 的浮点数还有特殊状态比如 NaN 表示无效数据正无穷表示超量程。如果从机返回的是 NaN手持器屏幕上显示 --看起来像是通信故障但这其实是数据内容的问题不是协议的问题。排查时先发命令 0 读设备标识确认通信正常再发命令 1 读过程变量如果数据仍然不对检查发送端浮点转换函数是否正确。5. 从驱动到产品的落地心得代码写完之后真正让 HART 功能稳定运行还需要做几件容易被忽略的事情。前导码长度问题。HART 规范里从机响应的前导码长度可以配置常见的是 5 个字节。但有些手持器或者上位机软件对前导码长度很挑剔特别是比较老的主机设备要求前导码至少 10 个字节才肯锁频。可以在协议栈里做一个配置项实际交付时根据客户的主机型号调整。还有一个是看门狗的问题。HART 从机在工业现场 7x24 小时运行如果因为外界干扰导致协议栈进入死循环看门狗是最底线的保护。建议把协议栈状态机的喂狗放在几个关键节点如果长时间没有有效通信就重启协议栈而不是整个 MCU。省电策略在低功耗仪表里是绕不开的。两线制变送器总功耗限制在 3.5mA 以内MCU 和 AD5700 的电流预算都要精打细算。我的做法是AD5700 平时处于接收模式CD 引脚的功耗大约是 15uA 左右主控进入低功耗模式。CD 引脚检测到载波时作为外部中断唤醒 MCU这样 MCU 不需要一直运行 UART 接收功耗能降低一个数量级。void EXTI0_IRQHandler(void) { if (EXTI_GetITStatus(EXTI_Line0) ! RESET) { // CD引脚下降沿表示有信号进来 // 唤醒MCU进入接收状态 __disable_irq(); SystemWakeup(); EXTI_ClearITPendingBit(EXTI_Line0); __enable_irq(); } }这个方案实测下来整机待机电流能从 1.2mA 降到 280uA 左右。对于电池供电的仪表来说这个优化非常可观。HART 协议栈的编写真正难的部分不在调制解调芯片驱动也不在协议帧解析——这些都有现成的资料和例程。难的是把协议栈做稳定在没有手持器调试设备的情况下通过逻辑分析和示波器把通信链路一点点调通。我最后分享一个小技巧调试期准备一个 USB-TTL 串口模块并联在 AD5700 的 UART 信号线上用 PC 端的串口调试助手模拟 HART 主机抓取和分析从机的响应数据。这种方式不需要额外的 HART 调制解调器排查协议字节顺序、校验错误之类的逻辑问题非常高效比直接在总线上抓波形直观得多。等项目稳定后再把手持器拿出来做真实环境验证能省下不少调试的时间。本文还有配套的精品资源点击获取