企业官网建设流程全解析

一块 32 位单片机 + 一个温度传感器模块，怎么把“本地”和“远程”两套测温需求一起做完

做嵌入式温度监测的人，迟早会遇到同一个问题：本地要用 ADC 实时采集、驱动显示，远程又要通过总线把温度送上去，两边还要求尽量少加硬件。我最近在整理一套 HVAC 控制器方案时，用的就是标题里的两个器件——温度采集前端 PJ85718DM，和主控 PIC32MX534F064H。整套方案核心就一句话：本地温度靠传感器直连 MCU 的 ADC，远程温度靠串口/RS-485 总线转发，中间用一套统一的标定和滤波逻辑把两类数据打通。

这套方案不挑行业，嵌入式和暖通空调都能直接套用。它的好处是：PIC32MX534F064H 的 12 位 ADC 精度足够，主频 80MHz 跑数据滤波和协议栈都不吃力；PJ85718DM 作为经过校准的温度采集前端，直接省掉了自己搭桥式放大器和冷端补偿的麻烦。适合正在做控制器开发、网关采集、楼宇自控或环境监测的工程师参考，也适合那些想把单个设备温度“既显示又上报”的嵌入式新手。

1. 项目到底要做什么：先拆题目，再定方案

1.1 两个核心器件分别扮演什么角色

PIC32MX534F064H 是 32 位 MIPS 内核的 MCU，带 512KB Flash、64KB RAM，属于 PIC32MX5xx 系列的中坚型号。这类芯片在工业控制里很常见，不是因为性能多极致，而是外设齐全：多路 12 位 ADC、多个 UART、SPI、I2C、定时器、比较器、DMA 都有，跑 80MHz 主频对温度采集这种任务绰绰有余。

PJ85718DM 从型号命名和工程定位来看，是一个集成了信号调理和线性化处理的温度采集前端模块。它把敏感元件（常见方案里是 NTC 热敏电阻或铂电阻）的电阻/电压变化，转换成 MCU 方便直接采样的输出信号。实际使用中最省事的设法定为“模拟电压输出型”，即量程 0~100℃，对应输出电压 0~3.0V 或 4~20mA 电流环。后续所有换算逻辑都基于这种线性输出。

选用这类模块化前端，而不是自己用分压电阻加运放搭采样电路，主要原因有两个。第一，温度传感器本身的非线性（尤其是 NTC）需要做多项式校正，模块出厂前已经校准过，代码里只需要做简单的比例换算，省掉了一大段标定逻辑。第二，HVAC 现场经常有长导线、变频器干扰、地电位差，模块本身的滤波和驱动能力比裸传感器强得多。

1.2 嵌入式与 HVAC 场景的差异决定了设计方向

很多人以为“测温度”哪儿都一样，实际差别很大。嵌入式场景往往是设备内部测温，比如电源模块过热保护、电机绕组温度监测，线缆短、环境相对干净，但要求响应快、采样频率高，并且温度数据要参与实时控制逻辑。HVAC 场景则相反，测的是水管温度、风管温度、室内外环境温度，线缆长、现场干扰大，更看重长期稳定性和通信可靠性，对响应速度要求反而不高。

这套方案的设计方向，是让同一个 MCU 同时服务两类场景：PJ85718DM 的本地模拟输出直接进 ADC，用于快速闭环控制；同时通过 UART 转 RS-485 总线，把温度数据打包成 Modbus RTU 帧发给远程上位机或网关。本地和远程的数据源指向同一个传感器，只是面向不同消费者。这种“一端采集，双路输出”的架构，是 HVAC 控制器里最实用的结构，因为现场运维人员要看本地数码管或触摸屏，中控室又要看远程监控画面，两边数据必须一致。

1.3 方案选型时为什么不用更便宜的 8 位单片机

这是我在方案评审时被问得最多的问题。8 位单片机的 ADC 通常只有 10 位，做 0.1℃级别的显示够用，但做 0.05℃级别的温差判断就很吃力。更关键的是，HVAC 项目通常不止一路温度，可能同时采集供水温度、回水温度、室外温度三路，8 位机的多通道扫描加数字滤波加 Modbus 协议栈，跑起来比较紧张。

PIC32MX534F064H 的 12 位 ADC 配合 DMA，可以做到连续扫描多通道而几乎不占用 CPU。Modbus RTU 协议栈、CRC 校验、超时重传这些逻辑，在 80MHz 主频下完全是小菜一碟。再加上这款芯片的引脚兼容性，后续如果想升级到带以太网 MAC 的型号（比如同系列的其它型号），硬件改动很小，这给产品迭代留了余地。一句话总结：不是杀鸡用牛刀，而是为后续可能增加的传感器路数和通信协议提前留余量。

2. 硬件设计的关键选择：从传感器接线到 MCU 外设分配

2.1 PJ85718DM 的接线方式与信号调理

PJ85718DM 在实际项目里常见有三种接法，取决于模块输出类型。第一，如果是电压输出型（0~3.0V），三根线分别是电源、地、信号，直接接 MCU 的 ADC 通道。第二，如果是 4~20mA 电流环型，需要在 MCU 侧并联一个 250Ω 精密电阻，把电流变成 1~5V 电压再进 ADC。第三种是数字输出型（比如单总线协议），可以直接接 MCU 的数字 I/O，代码走时序读取。

我推荐 HVAC 场景优先选 4~20mA 电流环版本，因为电流环在长距离传输时不会像电压信号那样受线阻影响。100 米导线下，电压信号会因为导线电阻产生明显压降，而电流环只要供电电压足够，末端采集到的电流几乎不变。嵌入式近距离场景则选电压输出型更划算，省掉取样电阻和隔离成本。

供电方面要注意一点：PJ85718DM 模块内部有基准源和调理电路，对电源质量比较敏感。电源纹波直接耦合进输出信号，会导致 ADC 读数抖动。我的做法是用一颗低压差线性稳压器单独给传感器供电，不要跟电机驱动、继电器驱动共用同一路电源。HVAC 控制器里继电器吸合的瞬间电流冲击很大，如果没有单独供电，温度读数会周期性跳动。

2.2 MCU 外设分配的具体规划

PIC32MX534F064H 的引脚资源很充足，做温度监测项目时外设分配要提前规划好，避免后期改板。我常用的分配方案是：

• ADC 通道 0：接 PJ85718DM 本地温度（电压型）
• ADC 通道 1：预留第二路温度输入（比如回水温度）
• UART1：RS-485 远程通信，接 Modbus RTU
• UART2：调试串口，接 PC 看日志
• 定时器 1：1ms 系统节拍，用于软件定时和传感器供电控制
• 定时器 2：Modbus 通信超时定时
• 看门狗：独立看门狗，防止固件跑飞导致温度失控

这里特别强调 RS-485 收发器的方向控制引脚。很多新手会把 DE/RE 引脚固定拉高或拉低，导致只能收或只能发。正确做法是用一个 GPIO 控制方向，发送前置高，发送完成拉低自动切回接收。方向切换的时机要掐准，我习惯在最后一个发送字节的发送完成中断里拉低方向引脚，这样不会截断最后一个字节，也不会过早接收导致回环误判。

2.3 ADC 基准源的选择思路

PIC32MX534F064H 的 ADC 支持内部基准和外部基准。对温度采集这种需要长期稳定性的应用，我强烈建议用外部基准，而不是内部基准。内部基准的温漂可能达到几十 ppm/℃，当机箱内温度从 25℃ 升到 60℃ 时，ADC 的满量程电压在漂，读数的绝对值自然会跟着漂。

外部基准我常用 2.5V 或 3.0V 的精密基准芯片，温漂选 5ppm/℃ 以内。PJ85718DM 输出电压范围是 0~3.0V，如果基准用 2.5V，0~100℃ 量程会有一部分超出量程，这时候要么改传感器量程，要么分压。稳妥的做法是把传感器量程配到 0~2.5V 对应 0~100℃，这样 ADC 满量程利用率高，每 1℃ 对应的 ADC 码位约为 10000 左右，做到 0.01℃ 分辨率的理论值。

3. 本地温度监测的软件实现：从原始码到稳定温度值

3.1 ADC 采样与数字滤波的工程组合

ADC 原始采出来的数不能直接用。PJ85718DM 输出虽然是线性电压，但现场干扰会让单次采样值上下跳动，尤其附近有变频器时，跳动能达到十几二十个 LSB。所以我用的是“中值滤波 + 滑动平均”的组合：每 10ms 采样一次，攒 5 个原始值，先取中间值去掉突发毛刺，再把中间值送入 16 级 FIFO 做滑动平均。

这个组合对 HVAC 场景很合适。中值滤波处理脉冲干扰（比如电机启停产生的尖峰），滑动平均处理随机噪声。温度本身的惯性很大，16 级滑动平均带来的响应延迟大约 160ms，完全在可接受范围内。写过热的嵌入式场景要注意，如果温度是用于立刻切断电源的过温保护，滤波等级要降低，比如只做 4 级平均，避免温度已经超标但因为滤波而延迟触发保护。

代码里还要注意 ADC 采样时间的设置。PIC32MX534F064H 的 ADC 采样时间可以配置为多个 Tad，采样时间太短会采不准高阻抗源的电压。PJ85718DM 输出阻抗一般不高，但我依然把采样时间设为 2 个 Tad，确保每次采样前采样保持电容充分充电到输入电压。这个细节如果不注意，读数会系统性偏低，而且通道间的读数会互相干扰。

3.2 电压到温度的换算：查表与公式的取舍

PJ85718DM 如果标定为线性输出，换算很简单：温度 = 电压 / 斜率 + 偏移量。这里的斜率通常在出厂说明里给出，比如 0.025V/℃，偏移量是 O℃ 对应的电压 0V。但在实际项目里，模块个体之间会有偏差，说明书上的斜率只能作为设计初值。

我的做法是两点标定：用精密恒温槽或干井炉，分别把传感器放在 0℃ 和 100℃ 两个标准温度点，记录 ADC 原始码。然后线性拟合出该模块的斜率和偏移。两点标定的误差足以覆盖绝大多数 HVAC 应用。如果要求全量程更准，就做三点标定，把中间点放在 50℃，使用分段线性插值。标定数据存在 Flash 里，每次上电读取并修正换算系数。

值得提醒的是，如果 PJ85718DM 内部是 NTC 加线性化电路，那么在量程两端（接近 0℃ 或 100℃）的线性误差会大一些。所以标定必须覆盖实际使用的温度范围，不要只标中间。我之前吃过亏，只标了 25℃ 一个点，结果 5℃ 的读数偏了 0.8℃，后来才发现低温段 NTC 的非线性残余被忽略了。

3.3 传感器自热误差的控制

电流流过温度传感器会自身发热，导致测出来的温度比实际环境高。PJ85718DM 这类模块的激励电流通常已经设计得比较小，但如果在 HVAC 风管里风速很低、空气不流动，自热效应仍然会被放大。

实际处理经验是：控制传感器供电，采用间歇供电策略。只在采样前 200ms 打开传感器电源，采样完成立即关断。这样传感器只有很短的导通时间，平均功耗很低，自热温升被压缩到最小。PIC32MX534F064H 的定时器很容易实现这个逻辑，一个 GPIO 控制传感器电源，采样线程在固定时刻唤醒并操作 GPIO。测静态环境温度时这个技巧特别有效，能把自热误差从 0.3℃ 降到 0.05℃ 以内。

还有一个容易忽略的地方：传感器探头不要跟 MCU 放在同一块 PCB 上太近的位置。PIC32MX534F064H 工作时功耗大约几十毫瓦，发热虽然不算严重，但如果探头紧挨着芯片，环境温度的读数会偏高。我用的是延长线探头方案，传感器通过屏蔽线引出到被测区域，PCB 上的本地温度只作为参考而不是主测量。

4. 远程温度监测的通信方案：数据怎么送出去、送得稳

4.1 为什么首选 RS-485 + Modbus RTU

远程温度监测的通信方式有几种：RS-485 总线、CAN 总线、以太网、Wi-Fi。对 HVAC 楼宇自控场景，RS-485 搭配 Modbus RTU 仍然是实际项目中占比最高的方案。原因很简单：楼宇里大量已有的网关、触摸屏、DDC 控制器都支持 Modbus RTU，兼容性最好。而且 RS-485 是差分信号，一对双绞线能传 1200 米，抵抗共模干扰的能力强，这对现场环境很友好。

以太网虽然传输带宽大，但布线成本和交换机成本高，而且 HVAC 现场条件往往达不到标准以太网的布线要求。Wi-Fi 更不适合工业现场，稳定性和漫游问题太多。因此，PIC32MX534F064H 的 UART1 配一个隔离 RS-485 收发器，用 Modbus RTU 从站协议，是目前性价比最高的远程温度上报方案。

需要注意：远程温度数据不必单独走另一路传感器，而是直接复用本地 PJ85718DM 的采集结果。这样本地显示的温度、参与控制的温度、上报给中控室的温度完全一致，不会出现“本地显示 23.5℃，远程看到 24.1℃”这种尴尬的偏差。这也是方案的核心设计——同一份数据，双路分发。

4.2 Modbus RTU 的数据帧设计

Modbus RTU 帧结构很简单：地址码 + 功能码 + 数据 + CRC16。温度监测项目里只用两个功能码就够了：读寄存器（03）和写寄存器（06）。我把温度值放在保持寄存器 0x0000 和 0x0001：寄存器 0 存放本地温度整数（比如 235 表示 23.5℃），寄存器 1 存放远程温度整数。对外统一约定温度值扩大 10 倍传输，这样上位机简单除 10 就能显示。

CRC16 校验必须自己实现，我在 PIC32 上用的是查表法，查表 256 项直接映射两个字节的 CRC 结果，每帧计算时间在微秒级别。这里有个常见坑：接收 Modbus 帧时，不能用“帧间间隔超过 1.5 字节时间”这种方式来判断帧结束就收手。如果配置不当，在 9600 波特率下 1.5 字节时间约为 1.6ms，而发送完成中断和接收中断之间的时序稍有波动就可能判错帧边界。稳妥做法是启用 UART 接收超时中断（有时称 RX Timeout），专门用来标记一帧结束。

从站地址设置我习惯做成写在 Flash 里的参数，通过本地按钮或调试串口配置。HVAC 项目里一栋楼可能有几十个温度节点，如果地址烧死在程序里，后台上位机配置时就得逐个查，非常麻烦。拨码开关或者参数寄存器修改地址，是现场运维最需要的功能之一。

4.3 通信异常后的数据保持策略

远程通信并不是每次都能稳定的，尤其是现场出现电磁干扰或者施工期间接线松动时，Modbus 主站可能连续读取失败。这时候工程上最容易犯的错误是：把失败的通信数据覆盖掉正常采集的温度值，导致中控室画面上温度跳个没完。

我的处理是：温度采集值单独存放在一个“原子变量”里，Modbus 读请求只是从这个变量拷贝数据，拷贝过程不会清除采集值。即使主站 10 分钟不读，温度值照常更新。同时会记录最后一次通信成功的时间，超过 30 分钟没有成功通信，会在寄存器里置一个通信状态位，上位机读到这个状态位就知道“温度数据在更新，但通信链路可能有问题”，而不是一脸茫然地看到温度还在变化却不知道链路状态。

另外，RS-485 总线的终端电阻不能漏。一个总线上哪怕只有两台设备，也必须在总线两端各接一个 120Ω 终端电阻。很多小规模项目为了省事不接，结果是长线上信号反射严重，波特率一高就误码。这是我调试过几十个 RS-485 项目后最深的体会：通信不稳，先查终端电阻和接地，别急着改协议。

5. HVAC 场景下的工程化细节：供电、布线与传感器安装

5.1 供电架构与隔离处理

HVAC 控制器内部往往同时有 24V 交流电源、继电器驱动、开关电源模块以及 MCU 弱电系统。PIC32MX534F064H 工作电压 3.3V，PJ85718DM 的供电可能是 5V 或 3.3V，因此需要做一次隔离或至少做一次干净的分区供电。

我的推荐架构是：整机从外部 24V AC 进来，经过整流和开关电源转成 5V，再用低噪声低压差线性稳压器转成 3.3V 给 MCU；PJ85718DM 的供电单独加一级 LC 滤波（磁珠加电容）后从 5V 接入。这样做的好处是：数字电路的高频开关噪声被磁珠挡住，不会污染传感器模拟信号。

如果是 4~20mA 电流环版本，传感器供电和输出天然具备一定的隔离能力，因为电流环接收端的地可以与发送端的地有电位差，只要不超过芯片共模范围即可。但为了稳妥，我仍会在 RS-485 侧加数字隔离器，把 MCU 的 UART 与总线收发器的电源和地完全隔离。HVAC 现场地电位差常常超过 10V 甚至更高，隔离不是可选方案，而是保命方案。

5.2 传感器安装位置决定测量意义

HVAC 温度监测的误差大头往往不在硬件，而在传感器安装位置。水管温度探头如果直接贴在管道外壁，测到的是管壁温度而不是水温，误差可能达到好几度。正确做法是插入式安装，把探头插到水管内部的水流中心位置，或者使用贴片式传感器加导热硅脂密封在管道表面，但这样也只能作为参考精度。

风管温度测量同样有讲究。探头要尽可能放在风管中心而不是紧贴管壁，并且避免放在加热盘管或冷却盘管的正下方，因为那里的局部气流温度并不代表整个风管截面温度。我在项目里给传感器加了一个简单的风管安装支架，让探头悬空固定在风管中线上，实测读数比贴壁安装稳定得多。

防凝露是另一个被忽视的细节。HVAC 的冷水管表面温度可能低到 5℃ 或更低，空气中的水蒸气会在传感器外壳上结露，甚至渗进 PCB 导致读数严重偏移。给传感器做灌胶密封或者选用带 IP67 防护等级的不锈钢探头外壳，是低成本高收益的方案。千万不要用普通塑壳传感器直接接触冷水管，否则用不了几个月读数就不正常了。

5.3 长期运行的数据记录策略

我通常会在 PIC32MX534F064H 的 Flash 里开辟一小块数据记录区，把本地温度和远程通信状态按照每分钟一条记录存下来，存满 24 小时滚动覆盖。这样做不是给上位机用，而是给现场调试用。当客户说“昨天下午温度波动异常”时，直接把历史数据导出来看，很快就能定位是传感器问题、电源问题还是通信问题。

Flash 写入次数有限制，所以每分钟写一次是合理的下限。写入时用“先写临时扇区，再搬移主扇区”的方式，避免正在写入时掉电导致全部数据损坏。这套数据记录逻辑在老式设备上是标准功能，但在不少注重成本的新项目里却被省掉了，结果出了问题只能靠人守在现场看，非常被动。

6. 实际调试中踩过的典型问题与排查思路

6.1 温度读数跳变和周期性波动

这是温度监测项目里最常见的故障现象。如果是随机跳变，首先看传感器供电电源纹波，用示波器测 PJ85718DM 供电脚，如果纹波超过 50mV，先把示波器探头点在供电端确认，再检查是不是继电器动作瞬间引起的跌落。我遇到过的情况是 24V AC 整流滤波电容太小，继电器一吸合，5V 输出就被拉低 200ms，温度读数跟着跳。

如果是周期性波动，而且波动周期跟压缩机启停或风机的 PWM 频率吻合，基本可以判定是干扰耦合。处理办法有两条：一是把传感器线改成屏蔽双绞线，屏蔽层单端接地；二是在 MCU 侧 ADC 输入端加一阶 RC 低通滤波，截止频率做到 10Hz 左右，只保留温度信号，把高频干扰滤干净。

还有一个隐蔽原因：ADC 通道扫描顺序。如果第 1 路采集的是高阻抗信号、第 2 路是低阻抗信号，高阻抗通道的采样电容没有被完全充电就被切走，下一轮回来采的时候会带上上一轮的残余电荷，表现就是相邻两次读数周期性交替偏高偏低。解决方法是把高阻抗通道的采样时间设为最大值，并增加通道切换完成后的稳定等待时间（例如 10us）。

6.2 温度读数系统性偏高或偏低

如果读数稳定但数值整体偏移，先做标定检查。用冰水混合物做 0℃ 参考（注意用标准探头验证），记录 ADC 读数。如果 0℃ 点偏差超过预期，要看 PJ85718DM 的输出是否真正是 0V 或对应电流。一个我在现场查到过的案例是：传感器和延长线之间的航空插头接触电阻变大，导致电压输出型传感器在终端测得的电压偏低，温度读数整体偏低。换用电流环版本后问题彻底消失。

另一个常见系统偏差来源，是 MCU 内部 ADC 参考电压不准。PIC32MX534F064H 的内部带隙基准也可能有 ±2% 误差，如果选择内部基准且不做校准，0~100℃ 量程下误差会被放大到 1℃ 以上。解决办法只有一个：外部精密基准或者上电自校准，用内部基准测内部带隙电压来计算实际 VDD，再反推校正系数。

6.3 RS-485 通信不稳定或偶发掉线

通信时好时坏，90% 是物理层问题。我会按以下顺序排查：

1. 检查总线两端是否有 120Ω 终端电阻
2. 检查 A/B 线是否接反
3. 检查总线所有设备的地是否共同连接
4. 检查波特率是否与主站一致
5. 检查线缆是否推荐的双绞屏蔽线
6. 用示波器看 A-B 差分波形，正常空闲状态下 AB 压差应大于 200mV

如果波形正常但通信还是丢帧，就要查软件超时设置。Modbus 主站通常要求从站在 10ms 内响应，如果从站程序里有其它中断长时间关中断，可能导致响应超时。我遇到过一次：一个定时器中断里处理了一小段 Flash 写入操作，耗了几毫秒，但那时恰好主站请求到达，从站没来得及响应。修改方案是 Flash 写入改为异步处理，中断里只置标志位，主循环再执行写入。

另外，RS-485 收发器的 DE/RE 方向切换如果过快，会在总线上产生短时冲突。发送最后一个字节后，要等这字节完全移位出去再拉低 RE，不能一进发送完成中断就立刻拉低。我见过很多人直接操作 GPIO 导致最后一个字节被自己对短，总线上出现 CRC 校验错误。

6.4 传感器长期使用后读数越来越偏

这种漂移故障通常发生在低成本的 NTC 传感器上。NTC 热敏电阻经过长时间冷热循环后，阻值会缓慢漂移，尤其是超过额定温度范围运行时更加明显。PJ85718DM 内部如果用的是高精度敏感元件，漂移会小很多，但也要定期做校准。

工程上最有效的办法是设计“自检周期”：每隔三个月或每年，上位机给设备发一条校准指令，现场用标准温度计同时读数，把新的偏置量写成参数落进 Flash。以上情况在 HVAC 项目里基本可以靠定期巡检解决，如果要求免维护，就得选用带出厂证书的高端探头，并且避免让探头长期工作在包络线边缘。

最后分享一点个人体会

做温度监测做到最后，你会发现真正难的不是把那几个 ADC 采样值算出来，而是让这个温度值在恶劣现场还能保持可信。PJ85718DM 加 PIC32MX534F064H 这套组合的优势，就是把硬件调理、模数转换、远程通信这三件事分得清清楚楚：传感器前端负责把物理量变成电信号，MCU 负责把电信号变成稳定的数值并送出去，通信协议负责把数值可靠地送到远处。

我个人做这类项目时，始终会记住一个原则：现场的第一手温度数据永远只来源于标定好的物理传感器，至于显示、记录、上报，这些全都是数据的搬运工。搬运工可以出错，但源头不能坏。所以我在设计时花最多心血的地方，永远都是传感器电源、接线屏蔽和标定逻辑，而不是花哨的协议栈。希望对正在做嵌入式和 HVAC 温度监测方案的你有帮助，也欢迎分享你在现场遇到的那些怪问题。