企业官网建设流程全解析

做工业仪表、变送器、现场总线相关开发的朋友，HART协议就像水电一样四平八稳地存在很多年，绕不开也躲不掉。传统的4-20mA模拟信号只能传一个物理量，设备要配置、要诊断、要读多变量，靠一根两线制供电回路根本抓瞎。HART就是在这根回路上叠加数字通信，老布线不动、供电不换，模拟信号照传，数字信息也能跑。这篇文章我把实际调通的方案完整拆开：主控用STM32L496，HART物理层调制解调交给ADI的AD5700-1，软件用标准HAL库手工撸了一套主机端通信流程。整个过程从协议原理讲到硬件连接、HAL配置、帧结构、校验算法、收发时序，最后附上我在调试中真实踩过的几个坑。适合正在做智能变送器、阀门定位器、HART手持器或者想快速验证HART通信原型的朋友，直接照着搭就能跑通命令0这类基础帧。

1. 先搞清楚HART协议在工业现场扮演什么角色

很多初学者一上来就翻数据手册找寄存器，结果被帧格式、分界符、校验位这些概念绕晕。其实HART的底层逻辑非常直白，本质上就是在传统模拟电流环上玩“叠加态”。

1.1 Bell 202 FSK：怎么在4-20mA电流环里塞数字信号

HART全称是Highway Addressable Remote Transducer，翻译过来就是“可寻址远程传感器高速通道”。它的物理层基于Bell 202通信标准，用的是频移键控（FSK）调制。所谓FSK，就是用两个不同频率代表数字逻辑：1200Hz代表逻辑“1”，2200Hz代表逻辑“0”，数据传输速率只有1200bps。

可以这样理解：现场仪表原本靠4-20mA电流传输压力、温度这些模拟值，这条电流回路好比一条公路，模拟信号是路上的主线车流。HART做的事情，是在同一段线路上叠加一个幅度很小的高频正弦波，1200Hz和2200Hz分别代表二进制1和0。这个叠加信号的幅度业内要求是0.5mA峰峰值左右，相对于4-20mA的主信号来说非常小，所以不会明显干扰模拟传输。反过来，接收端通过带通滤波把FSK分量提取出来，就能还原数字帧。

因为FSK信号叠加在电流上、又不会挤占原有模拟通道，所以HART才能做到“一根两线制电缆，既走模拟量，又走数字量”。实际项目里，这对接线方式极其友好——现场旧设备升级成智能仪表，电缆和端子都不用换，DCS侧加一个HART调制解调器就行。

1.2 HART的“一问一答”：帧结构与命令模型

HART协议的使用场景通常是主从问答模式。一个HART网络中有一个主站（比如DCS、手持器或我们的STM32板子），一个或多个从站（变送器、执行器）。主站发出命令帧，从站收到后执行动作并回复响应帧。网络里同一时刻只允许一方发言，也就是半双工。

既然要“对话”，就得有约定的台词格式。HART帧的基本构成如下：

• 前导码（Preamble）：连续若干个0xFF，用于接收端时钟同步和电平稳定，常见5个到20个。
• 分界符（Delimiter）：1字节，告诉接收端这是一帧开始，并标明帧类型和方向。短帧主站请求通常是0x06，从站响应是0x16；长帧主站请求是0x86，从站响应是0x96。
• 地址（Address）：短帧模式下一般1字节，包含轮询地址和突发标志；长帧模式下是5字节，携带设备唯一标识。
• 命令号（Command）：1字节，HART命令编号，比如命令0读取设备唯一标识，命令1读取主变量。
• 字节数（Byte Count）：1字节，表示后面数据字段的长度。
• 数据（Data）：长度可变，有时为0。
• 校验和（Checksum）：1字节，LRC算法，从分界符开始到数据段末尾逐字节异或。

我用生活例子打个比方：主站先喊“各单位注意（前导码），这是一条寻呼（分界符），呼叫地址3的传感器（地址），请报告你的设备信息（命令0），完毕（校验）”。从站听到后回应“收到，我是某某厂家的压力变送器，序列号是……”。

初学阶段不用一上来就啃长帧，先用短帧跑通命令0和命令1，整条链路就活了。

1.3 为什么这套方案适合智能变送器这类低功耗设备

STM32L496是ST的L4系列低功耗MCU，Cortex-M4内核，主频80MHz，运行功耗很低，多个低功耗模式支持Stop1、Stop2甚至Standby。放在两线制变送器里，供电是从4-20mA回路里“抠”出来的，电流预算非常紧张，可能整机只能分到3.5mA以内。低功耗主控就是刚需，而L496这种资源级芯片在保证计算力和外设的同时，能把功耗压下来。

AD5700-1这边，它是ADI的专用HART调制解调器单芯片，内部集成了符合Bell 202标准的调制解调器。最省事的是AD5700-1内置RC振荡器，不需要外部晶振，上电就能工作，精度满足1200bps通信要求；如果你用不带-1后缀的AD5700，就得额外配一颗晶振，BOM成本、PCB面积和故障点都多一个。AD5700-1还支持UART和SPI两种数字接口，直接和MCU的串口对接，协议栈完全不用管物理层调制解调细节。

这套组合的本质是“低功耗主控+专用物理层芯片”，把最麻烦的模拟调制解调丢给专用芯片，MCU只处理协议帧和应用逻辑。对比直接用MCU内部DAC+定时器模拟FSK的方案，AD5700-1的调制精度、抗干扰能力、功耗表现都要稳得多。工业产品稳定性优先，能用专用芯片解决的事情，不要用软件硬撑。

2. 硬件怎么搭：STM32L496 + AD5700-1核心电路与引脚分配

硬件设计是HART通信能不能稳定工作的前提。我在第一版做原型的时候，直接把AD5700-1的HART_OUT和HART_IN飞线到两块板子中间的回路里，结果波形乱七八糟，后来按照评估板的思路重新理了一遍耦合网络才算正常。

2.1 芯片选型：为什么是L496而不是F103

如果你只是验证HART协议，F103也完全能跑，但放在实际产品设计里，L496有几个优势非常关键。

首先还是功耗。F103在72MHz主频下正常功耗大约几十毫安，这个数量级对两线制变送器来说是灾难。L496运行模式能做到100uA/MHz级别，加上丰富的低功耗定时器和LPUART，可以在待机时维持极低电流。HART通信不是每时每刻都在跑，平时仪表只输出模拟信号，等主站来询问时再唤醒MCU干活，这种场景L496非常对味。

其次，L496的模拟外设比较齐全，比如DAC、比较器、运算放大器，做变送器时电流环控制、信号采集都能交给芯片内部模块，减少外部器件。另外它的FlexPower模式允许不同域独立供电，对某些传感器供电策略很灵活。

我不是说F103不行，而是你如果要从“实验室跑通”走向“产品化”，L496的功耗余量和外设丰富度会让你少做很多取舍。尤其当HART协议栈需要管理设备诊断、传感器补偿、通信调度这些功能时，L496的资源也不会成为瓶颈。

2.2 AD5700-1：一颗省掉晶振的HART调制解调器

AD5700-1是ADI专门为HART应用设计的单片调制解调器。它把发送路径的FSK调制和接收路径的FSK解调全部集成在内部，对外只暴露模拟信号接口和数字接口。

数字侧最常用的是UART模式，通过MODE引脚拉低选择。在这种模式下，MCU的UART TX直接接AD5700-1的DIN，MCU的UART RX接AD5700-1的DOUT。MCU发0x55这样的字节，AD5700-1会自动把它变成一串1200Hz/2200Hz的FSK波形；反过来，回路上的FSK信号经过AD5700-1内部解调，从DOUT输出串行数据，MCU那边就当成普通UART接收。

AD5700-1有两个控制引脚特别重要：RTS和CD。RTS是发送/接收模式切换，高电平进入调制发送模式，低电平进入解调接收模式。CD是载波检测，一般低电平表示检测到有效FSK信号。我用“一般”这个词是因为不同板卡或厂家模块的极性可能会有反相处理，调试时务必用示波器或逻辑分析仪确认。

AD5700-1的工作电压范围是2.7V到5.5V，数字接口电平兼容3.3V，所以和STM32L496直连完全没问题，不需要电平转换芯片。输出级VREF引脚可以给模拟前端提供偏置，具体用法后面说。

2.3 最小系统接线与引脚分配表

我把自己的工程里用到的引脚整理成一张表，方便你对照参考。STM32这边我用的是UART4，具体引脚大家根据自己板子调整。

这里有一个容易被忽略的问题：DIN和DOUT虽然是TTL电平串口信号，但AD5700-1的DOUT在无载波时输出状态不定。MCU侧如果配置了UART接收中断，可能会收到随机噪声。最稳妥的做法是配合CD引脚做门控，只有CD指示有载波时才处理接收数据。这点在代码章节会细讲。

2.4 耦合网络：把信号送到4-20mA回路的关键

AD5700-1的HART_OUT输出的是内部调制的模拟小信号，不能直接怼到4-20mA回路上，需要经过一个耦合网络。发送路径上，HART_OUT经过隔直电容和串联电阻注入电流回路；接收路径上，从回路耦合采集FSK信号送到HART_IN。

典型电路思路是：HART_OUT串联一个0.1uF到0.22uF的隔直电容，再串一个几百欧姆的电阻，接到电流回路的采样电阻或运算放大器输入节点。这个RC组合既保证FSK信号能叠加进去，又把直流和低频的4-20mA信号隔开，防止数字信号干扰模拟通道。接收路径类似，从回路节点经过电容耦合到HART_IN，同时在HART_IN引脚做一点阻抗匹配和滤波。

这套耦合网络的阻容参数不是随便抄的，它和你变送器的电流环控制结构、回路总阻抗、电缆长度都有关系。有条件的话，用ADI官方的AD5700评估板原理图做参照，然后用网络分析仪或至少示波器看波形来调。没有仪器时，先用官方推荐值，再通过实测通信误码率来迭代。

还有一点很重要：AD5700-1的直流偏置点。官方手册建议HART_IN和HART_OUT直流偏置在合适电平，通常是利用内部偏置或者外部电阻分压。如果你在设计单独的HART模块，这几个电阻电容的值要计算好，避免信号饱和或者幅度不足。

3. STM32CubeMX工程生成与HAL库基础配置

硬件搭好之后，软件工程从STM32CubeMX生成。用图形化配置工具的好处是时钟树、外设初始化代码、引脚复用关系全部自动生成，不容易出现“时钟没开所以外设不动”这种低级问题。我习惯把所有初始化交给CubeMX，协议逻辑自己写在用户文件里。

3.1 工程生成与时钟树设置

创建工程时选择STM32L496系列的具体型号，我这里用的是STM32L496VGT6。时钟源建议选外部高速晶振HSE。HART对串口波特率精度有要求，内部RC振荡器虽然也能凑合，但长期稳定性、温度漂移都差一些，工业环境别冒险。

时钟树配置方面，我习惯让系统主频跑到80MHz，APB1和APB2总线时钟也一并确认好。UART4挂在APB1总线上，后面的UART波特率计算依赖这个总线时钟，不要乱改。CubeMX里把HSE选好，点击“Clock Configuration”标签页，系统会自动分配PLL参数，确保SYSCLK、APB1、APB2没有红色报错即可。

生成的工程可以用STM32CubeIDE直接打开，也可以导出到Keil MDK或者IAR。我用的是STM32CubeIDE，因为免费的且GCC的编译优化比较直观，调试器支持ST-Link即插即用，省去不少配置烦恼。

3.2 UART配置：1200bps怎么设才不出错

在CubeMX里选中UART4，异步模式（Asynchronous）。关键参数如下：

• 波特率：1200bps
• 数据位：8
• 停止位：1
• 校验位：None
• 流控：无

1200bps是一个非常慢的串口速率，每一帧一个字节大约8.3ms。很多人习惯把串口超时时间设成几十毫秒，在HART这种低速链路上容易出问题，因为完整设备响应帧可能包含几十个字节，全部收完需要两百多毫秒。后面软件设计超时必须按HART的节奏来。

STM32L496的UART波特率发生器是16倍过采样，1200bps下USARTDIV = 80MHz / (16 * 1200) = 4166，整数部分极大，但其实小数部分很少，所以偏差可以忽略。使用HAL库时这些计算自动完成，不需要手工写寄存器。

如果项目对功耗有极致要求，可以考虑使用LPUART，它可以在低功耗模式下工作，但初次调试HART时建议先用标准UART，逻辑更简单。等协议跑通了再移植到LPUART，收益很直接。

3.3 GPIO和外部中断配置

除了串口外，还有两个GPIO需要做初始化：RTS作为普通推挽输出，CD作为外部中断输入。

RTS引脚（PA1）在CubeMX里设为GPIO_Output，初始电平输出低，也就是默认进入接收模式。推挽输出即可，不要开漏，因为AD5700-1的逻辑输入不需要上拉。

CD引脚（PA0）设为外部中断模式。触发方式需要根据AD5700-1的CD实际极性决定，一般可以选“下降沿”触发，也就是检测到载波到达时响应。如果你的板子上CD信号经三极管反相过，就改成上升沿，甚至可以在调试阶段先做成轮询，确认极性后再改成中断。

外部中断初始化后，HAL库会在HAL_GPIO_EXTI_Callback回调函数里通知你。回调里只做置标志位，不要写复杂逻辑，因为中断上下文不适合做耗时操作。

3.4 HAL库代码结构，快速上手不迷路

HAL库的文件结构其实很简单，不需要被一长串文件名吓到：

• stm32l4xx_hal_uart.c：UART驱动，收发函数全在这里
• stm32l4xx_hal_gpio.c：GPIO驱动
• stm32l4xx_hal_cortex.c：NVIC、SysTick相关
• stm32l4xx_hal_rcc.c：时钟控制函数
• stm32l4xx_hal.c：公共初始化、延时函数
• 用户代码一般写在main.c的USER CODE段，或者单独建模块文件

HAL库最大的特点是接口统一，换芯片平台时外设API基本不变，比如HAL_UART_Transmit在F1、F4、L4上长得一模一样。你只需要会查外设句柄结构体和API返回状态，就能快速写出驱动。

需要注意，HAL的发送函数默认是阻塞发送，而接收函数可以配合中断或DMA。在HART这种半双工协议里，我们完全可以靠阻塞发送+外部中断CD信号+中断接收来搞定，不需要DMA的复杂度。

4. HART通信核心代码：从命令帧到响应解析

软件部分我按“构建帧—发送—切换方向—接收—解析”这个流程展开。代码我会贴关键部分，全部逻辑放在hart.c里，结构比较清晰。

4.1 LRC校验：别小看这个异或求和

HART帧的校验方法是LRC，也就是把从分界符开始到数据段最后一个字节的所有字节按位异或，得到一个字节的校验值。这个算法比CRC简单得多，但也容易写错。

出错点主要在于异或的起始位置和结束位置。前导码0xFF不参与校验，分界符参与校验。以主站命令0为例，短帧的组成是：

• 5字节前导码 0xFF
• 1字节分界符 0x06
• 1字节地址 0x00
• 1字节命令号 0x00
• 1字节字节数 0x00
• 1字节校验和

校验和计算范围是分界符0x06开始，到字节数0x00结束，共四个字节：0x06 ^ 0x00 ^ 0x00 ^ 0x00 = 0x06。所以命令0的校验和刚好也是0x06，很多初学者以为“为什么校验和恰好等于分界符”，其实这是巧合。

我写了一个通用函数：

uint8_t HART_CalcLRC(const uint8_t *data, uint16_t len) { uint8_t lrc = 0; for (uint16_t i = 0; i < len; i++) { lrc ^= data[i]; } return lrc; }

调用时从分界符所在数组下标开始，长度是“分界符+地址+命令+字节数+数据段”的总长度。千万不要把前导码算进去。

4.2 构建短帧命令并发出

以HART命令0为例，这个命令用来读取从站设备唯一标识，是最常用的“握手”命令。构建帧的代码如下：

#define HART_PREAMBLE_LEN 5 uint8_t HART_BuildCmd0(uint8_t *frame, uint16_t *len) { uint16_t idx = 0; // 前导码 for (uint8_t i = 0; i < HART_PREAMBLE_LEN; i++) { frame[idx++] = 0xFF; } // 分界符：短帧，主站请求 frame[idx++] = 0x06; // 地址：第二主站，轮询地址0 frame[idx++] = 0x00; // 命令号：0 frame[idx++] = 0x00; // 字节数：0 frame[idx++] = 0x00; // 校验：从分界符开始异或 frame[idx] = HART_CalcLRC(&frame[idx - 4], 4); *len = idx + 1; return 0; }

这里地址字节我填0x00。HART短帧地址的低7位是轮询地址，默认从站地址一般是0，所以主站要找默认设备就发0x00。如果一组总线挂了多个从站，每个从站分配了不同轮询地址，那就把对应地址填进去。

构建好帧之后，通过串口发出去。HART链路速率极低，发送前需要做好超时预算。10字节的帧在1200bps下需要约83ms，所以HAL_UART_Transmit的超时参数至少给500ms，避免因超时丢弃。

4.3 RTS与CD时序：收发切换的灵魂

HART是半双工协议，AD5700-1的RTS引脚就是控制这个方向的。发送时拉高RTS让芯片进入调制模式，发送完成后拉低RTS回到接收模式。这里面有一个关键时序：拉高RTS后不能立刻发数据，芯片内部的调制器需要稳定时间，我一般延时5到10ms再开始串口发送，简单粗暴但稳定可靠。

同理，从发送模式切回接收模式后，也不能指望下一秒就能收到从站响应。从站自己要处理命令、准备响应，再加上物理层传输延迟，主机要耐心等待。我用CD引脚来判断从站是否开始回复：当检测到载波，CD从高变低，这时开始接收UART数据。接收过程中持续收，直到一整帧结束。

代码如下：

uint8_t HART_SendCommand(uint8_t *txFrame, uint16_t txLen, uint8_t *rxFrame, uint16_t *rxLen) { // 进入发送模式 HAL_GPIO_WritePin(RTS_GPIO_Port, RTS_Pin, GPIO_PIN_SET); HAL_Delay(5); // 发送命令 HAL_UART_Transmit(&huart4, txFrame, txLen, 500); // 切回接收模式 HAL_GPIO_WritePin(RTS_GPIO_Port, RTS_Pin, GPIO_PIN_RESET); // 等待CD指示载波到来，超时500ms uint32_t start = HAL_GetTick(); while (HAL_GPIO_ReadPin(CD_GPIO_Port, CD_Pin) == GPIO_PIN_SET) { if (HAL_GetTick() - start > 500) { return HART_ERR_TIMEOUT; } } // 接收响应帧 return HART_ReceiveFrame(rxFrame, rxLen); }

这里我默认CD检测到载波时为低电平。如果你的板子反相，把GPIO_PIN_SET和GPIO_PIN_RESET对调即可。

4.4 响应帧解析：状态机才是正确写法

接收HART响应帧比发送命令要难，因为响应帧长度是不固定的，而且前面有一段前导码。不能用固定长度的数组去收，必须做状态机解析，一字节一字节地判断当前处于哪个阶段。

我的做法是先定义一个接收结构体，保存当前状态和帧内索引：

typedef struct { uint8_t state; uint16_t idx; uint16_t dataLen; uint8_t frame[HART_MAX_FRAME_LEN]; } HART_RxParser;

初始化时状态为搜索前导码。收到0xFF就继续，当遇到第一个非0xFF字节时，把它当作分界符存入帧缓冲区，并进入解析头部阶段。之后分别读取地址、命令、字节数，再把后续的数据字节逐字节存入缓冲区，最后收校验字节，做LRC核对。

状态机的核心伪代码如下：

void HART_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == UART4) { HART_ParseChar(rxByte); HAL_UART_Receive_IT(&huart4, &rxByte, 1); } }

注意HAL库的中断接收是一次接收一个字节，收到一个字节后会再次调用HAL_UART_Receive_IT挂下一次接收。这种方式在1200bps下毫无压力，每字节间隔8ms，CPU有大量时间处理。

接收完成后，校验分界符是否合法（0x16表示从站短帧响应），再校验LRC，通过后就进入协议层做响应数据解析。命令0的响应数据里有一段设备唯一标识，包含制造商、设备类型、序列号，解析出来可以直接打印验证。

5. 调试实录：我在这个项目里踩过的坑

HART通信的调试过程确实有门槛，很多时候不是代码逻辑错了，而是硬件时序、极性、电平这些小细节在作怪。下面几个坑都是我实际踩过的，每一个都浪费过至少半天时间。

5.1 命令发出后设备没反应，先查这三件事

第一件事是查发送端有没有真正把FSK信号发出来。用示波器探头看AD5700-1的HART_OUT引脚，正常情况下发送命令时可以看到一串1200Hz和2200Hz交替的正弦波。如果没有波形，回查RTS是否成功拉高、串口TX是否真的连到了DIN、DIN电平是否符合芯片要求。

第二件事是查回路电流环是否顺畅。HART_OUT经过耦合网络叠加到4-20mA回路上，如果回路断开了或者模拟前端没有形成通路，信号根本到不了从站。单独调试时可以在回路里串一个250欧姆电阻模拟负载，用示波器看电阻两端是否出现FSK波形。

第三件事是查从站是否真的响应。如果你调试的对象是真实变送器，确保它的HART功能开启、轮询地址正确。很多变送器默认地址是0，但也不排除被改成其他值。如果从站响应了，CD引脚会有明显电平跳变。CD一直没反应，大概率是接收通路有问题，而不是协议问题。

5.2 1200bps波特率误差为什么致命

HART链路对波特率误差要求严格。虽然UART本身允许一定偏差，但HART调制解调器从FSK信号恢复数据时，对位时序敏感，如果MCU串口的波特率和AD5700-1内部标称值偏差太大，字节移位或乱码就会出现。

我遇到过用内部HSI时钟跑UART，室温下能通信，板子稍微发热或环境温度降低就偶发通信失败的情况，后来查下来就是时钟精度不够。换到HSE外部晶振后问题消失。

另外，调试波特率问题时别只看理论计算，直接用示波器测量DIN引脚单个字节的高电平脉宽，比如发0x55（二进制01010101），每个位的宽度应该是约833us。如果测量值偏差超过2%，就需要检查时钟配置或更换晶振。

5.3 CD引脚极性搞反，代码白写一半

CD极性这个坑我印象极深。最初我参考一份资料，写的是“CD低电平表示无载波”，就一直等CD拉高才认为是载波到来，结果通信永远超时。后来用逻辑分析仪抓CD引脚波形，才发现检测到载波时CD是拉低的。

排查这类问题的标准做法是：在从站响应的时候用逻辑分析仪同时抓CD和DOUT两路信号。你会发现CD跳变和DOUT数据输出之间有明确对应关系，极性一眼就看出。

5.4 接收缓冲区越界与脏数据清理

HART响应帧长度不固定，如果代码里写死了缓冲区大小，遇到超长响应就可能越界写坏内存。解决方法是解析状态机里对接收长度做严格上限检查，超过HART_MAX_FRAME_LEN就直接丢弃并重置状态。

还有一个经验是接收前要清空串口接收缓冲。因为链路空闲时DOUT可能有少量随机电平跳变，如果UART中断已经挂上，可能在真正响应帧前收到几个垃圾字节。我每次发送命令前，主动调用一次__HAL_UART_CLEAR_OREFLAG和__HAL_UART_CLEAR_NEFLAG，同时清掉接收状态，确保新帧从头开始解析。

6. 从“能通信”到“协议栈”：后续可以怎么扩展

命令0跑通了，基本等于大门打开。后面要做的事情是把协议栈功能补全，让设备真正可用。

6.1 常用HART命令速查表

我在项目里最常用的HART命令如下，你可以作为开发参考：

命令0和命令1是基础中的基础。命令0能帮助你确认通信链路通不通、对象是不是你想象的那个设备；命令1能直接拿到主变量数值，很多上位机界面只要实现这两条命令就能提供基本价值。

6.2 长帧与广播命令：多站总线的进阶玩法

短帧的优点在于简单，但只适用于轮询地址0到15这样的经典点对点场景。如果一条总线上挂多个HART仪表，就要启用多站模式，这时最好使用长帧。

长帧地址是5字节，包含制造商、设备类型、序列号等唯一标识，可以精确寻址到具体设备。分界符也会变化，主站请求是0x86，从站响应是0x96。长帧的帧结构解析逻辑和短帧基本一样，只是地址字段长度和数据组织不同。

广播命令是另一个实用功能，比如命令0可以广播给所有从站，总线上每个设备都会以短帧响应自己的唯一标识，主机就能据此完成自动搜索和设备盘点。注意广播时地址字段有特殊约定，一般是全0xFF或特定地址，具体看协议栈文档。

6.3 重试机制与超时设计

HART通信的可靠性不仅靠物理层，还要靠协议层重试来兜底。工业现场有电机启停、变频器干扰这些噪声源，偶尔丢一帧很正常，关键是要快速恢复。

我设计的轮询流程是：每次命令最多重试3次，间隔300ms。如果三次都失败，标记该设备离线。注意重试时不能简单重复发送，最好重新构建整个帧，避免残留状态影响。超时时间也不能太长，否则多个设备轮询周期被拉长；但也不能太短，因为从站响应时间可能受其内部传感器采集周期影响，300到500ms是比较均衡的值。

另外，建议在协议栈里维护“最后通信时间”和“连续失败次数”两个计数器。这样既能做设备在线状态监控，又能在总线异常时快速定位是哪条链路出现问题。

6.4 低功耗唤醒：CD引脚+外部中断的经典组合

如果你做的是电池供电或两线制供电的HART仪表，低功耗设计就绕不开。我的做法是：平时MCU进入Stop模式，AD5700-1保持在接收解调状态，CD引脚接到MCU的外部中断唤醒引脚。当主站发起通信且物理层检测到载波时，CD电平跳变把MCU从Stop模式唤醒，MCU再开始接收UART数据并解析命令。响应完成后，MCU重新进入Stop模式。

这套方案的核心优势是MCU不需要定时唤醒轮询，真正做到了“有事才醒”。但要提前确认Stop模式下UART外设是否支持接收，如果不支持，就需要在CD中断里先把MCU恢复到正常运行模式，再重新初始化UART。L496的FlexPower架构允许部分外设在Stop模式下继续工作，用得好功耗可以压到微安级别。

我在实际项目里的体会是：HART协议本身不复杂，难的是把物理层时序、硬件耦合网络、低功耗策略这些周边环节做好。AD5700-1这颗芯片已经把最难的模拟部分解决了，MCU侧的活儿主要是帧处理和业务逻辑。你只要一步步把命令0跑通，再按需扩展其他命令，整个通信链路就会越来越顺手。最后再分享一个小技巧：调试时准备一个USB逻辑分析仪，16MHz采样率以上就够用，把DIN、DOUT、CD、RTS四路信号全部抓下来，通信好不好一眼就看明白，比抱着示波器满地找探头高效得多。