做嵌入式和暖通空调HVAC项目做多了以后有个矛盾特别常见控制器自己盯着的温度和系统真正需要关心的温度往往不在一块儿。控制箱里38℃可风道送风口的温度已经掉到15℃以下了——如果只盯着板子附近的测点整个控制逻辑都会跑偏。这也是我为什么特别看好PJ85718DM与TM4C123GH6PZ这种组合一颗专门负责温度感知一颗专门负责采集、换算、通信和控制。这篇文章就围绕用 TM4C123GH6PZ 主控、配合 PJ85718DM 传感器在嵌入式以及 HVAC 场景里同时监测本地温度与远程温度来展开。文章里除了整体架构、电路要点和固件代码还会把画板、调总线、标定数据时容易踩的坑一起写出来。适合正在做暖通控制箱、楼宇自控、机房环境监控或者想用一个 MCU 统一管理分散测点的开发者参考。1. 从 HVAC 现场需求说起为什么本地和远程温度都得管1.1 一套暖通系统里温度测点到底要布多少先看实际场景。一套典型的小型 HVAC 控制器测点从来不止一个。回风温度从室内回到机组的空气温度是判断制冷/制热负荷的重要输入。送风温度处理完之后的空气温度直接关系到出风舒适度和盘管防冻。盘管/水管温度冬天水侧温度过低有冻裂风险夏天水温过高影响换热效率。箱内温度控制器内部或电控箱的环境温度用来评估电子器件自身的热负荷。室外环境温度热泵机组判断制热效率、除霜启动条件的关键参考量。这些测点有的就在控制器旁边有的要拉到几十米外的风道里、水管壁上。于是本地温度和远程温度的概念就自然分出来了。所谓本地就是主控板 PCB 上或控制箱内距离 MCU 很近、走线不超过十几厘米的测点所谓远程则是通过总线把传感器或不完整的数据链路延伸到机组其他地方。1.2 本地与远程的分界线到底划在哪里很多新手容易把远程温度理解成只要导线够长就行于是直接拉一根一米多的 I2C 线把传感器挂在主控上。这在实验室可能没问题到了工地现场往往翻车导线长了I2C 总线电容变大信号沿变钝连续读几十次就会出现一次错误帧现场又有变频器、接触器、电磁阀传导和辐射干扰一起上来读数跳得你怀疑人生。所以实际设计时要划一道清晰的分界线PCB 板内或控制箱内这种短距离、低噪声环境归本地采集超过一米、需要穿过强电区域或者要经过端子排的归远程采集。远程采集要么走差分信号总线要么用串行异步通信加可靠的协议层而不是简单地把传感器接口拉长。PJ85718DM 作为传感器端TM4C123GH6PZ 作为主控端两边正好可以把这条分界线落到工程实现上。2. 主控与传感器选型TM4C123GH6PZ 和 PJ85718DM 能扛住什么活儿2.1 TM4C123GH6PZ 的能力边界TM4C123GH6PZ 是 Cortex-M4F 内核带硬件浮点单元FPU主频可以跑到 80MHz。这个内核放在温度监测项目里意味着什么意味着你可以放心地做浮点滤波、做线性化校正、做温湿度补偿而不必去抠定点运算的精度和性能。温度换算本身并不重但 HVAC 控制器往往不止采温度它还要跑风机启停逻辑、读压差开关、驱动继电器或接触器、和触摸屏或上位机通信、甚至处理几路模拟量输入。TM4C123GH6PZ 的 256KB Flash 和 32KB SRAM 在这种组合负载下很从容。更关键的是它的外设资源——12 位 ADC 可以解决本地模拟量采集多个 I2C/SPI/UART 接口可以同时挂数字温度传感器和远程通信模块部分型号还带 CAN 控制器想升级成现场总线方案也留得余地。工作温度范围方面TM4C123GH6PZ 的工业级版本能覆盖 -40℃ 到 85℃。HVAC 设备现场环境往往没有机房那么友好控制箱在夏天暴晒后内部温度可以轻松超过 50℃冬天冷库场景又会到零下十几度宽温范围是必须的不是加分项。2.2 PJ85718DM 在温度监测里的角色PJ85718DM 常见的设计形态是数字化温度感知器件输出接口以 I2C 兼容接口为主有些批次的型号也支持模拟电压输出具体以手上器件的数据手册为准。它和 DS18B20 这类一线式传感器相比最大的不同在于地址管理PJ85718DM 的从机地址通常可以通过引脚配置出几个不同的地址这让它在一条 I2C 总线上挂多个测点时省去不少麻烦。我在这套方案里把它用在两个地方一个做本地板载测温直接放在 MCU 附近读回风温度另一个做成远程采集小板通过 RS-485 总线和主控连接去测送风温度和盘管温度。这样同一个器件在本地和远程两条路径上都得到了使用物料统一采购和备件都省心。2.3 为什么这个组合适合 HVAC 场景选 PJ85718DM 和 TM4C123GH6PZ不是因为它俩是参数最顶的器件而是因为匹配度。供电简单PJ85718DM 工作电压范围宽常见版本能在 2.7V 到 5.5V 下运行3.3V 供电直接和 TM4C123GH6PZ 的 IO 电平匹配不用做电平转换。精度够用暖通测控的精度要求通常没有工业仪表那么苛刻典型 ±0.5℃ 的精度已经足够支撑舒适度控制、防冻保护和能效统计。资源配对主控自带多种串行接口可以同时把 I2C本地传感器、UARTRS-485 远程总线、调试串口这三条通路跑起来外设不够不用改方案。这种够用但留有余量的组合比一味追求高分辨率传感器的方案在量产阶段更可控成本也更低。3. 系统架构本地采集与远程总线怎么搭最省心3.1 整体拓扑的规划思路这套方案的架构不复杂分为三级第一级是传感器节点。本地传感器直接挂在主控的 I2C 总线上远程传感器则做成独立的小节点板每个节点板上有一片 PJ85718DM 和一个 RS-485 收发器用一根双绞线串起来接到主控的 RS-485 接口上。第二级是主控板。TM4C123GH6PZ 在这里做三件事周期性读取本地 I2C 总线上的温度通过 UART 转 RS-485 轮询远程节点的温度把本地和远程数据做滤波、标定、越限判断然后通过另一个 UART 口上报给触摸屏或者上位机。第三级是数据输出。上报协议用 Modbus RTU 或者自定义的简单帧格式看项目要求。如果是楼宇自控集成走 Modbus RTU 会省很多对接成本如果只是自己控制逻辑内部用自定义协议更灵活。为什么不直接让远程节点也用 I2C 拉长线前面已经说了I2C 不适合远距离。HVAC 现场通常有强电设备I2C 的抗干扰能力撑不住。RS-485 是差分信号两根线上传的是相反电平共模干扰会被接收器抵消掉配合屏蔽双绞线和正确的接地策略长度几十米完全可行。3.2 远程节点的硬件构成每个远程温度节点板体积都很小核心就三样东西PJ85718DM 温度传感器、RS-485 收发器、一颗小的稳压器或者直接从 24V 总线取电降压下来。节点板与主控之间用四根线连接两根电源24V 或 12V视现场供电条件、两根 RS-485 信号线A、B。这种布线方式在 HVAC 设备里非常常见因为现场工人熟悉端子接线比让他们去压接屏蔽 I2C 线缆要靠谱得多。地址分配上主控这边通过拨码开关或者软件配置给每个节点分配地址。软件配置听起来高级但初次上电时要处理未配置地址的状态反而复杂。我习惯用两个拨码位组成 0 到 3 的地址一条总线上带三四个远程节点足够用了调试时掰开关就能换地址还能省掉专门的配置指令。3.3 主控板侧的资源分配TM4C123GH6PZ 的 I2C 模块和 UART 模块很多但别一上来就乱接。我在样板设计时把资源固定下来I2C0本地板载温度传感器。UART1RS-485 主站轮询远程节点。UART2数据上报 / 调试输出。GPIO节点地址读取、RS-485 收发方向控制、状态 LED。这样的分配逻辑很清晰I2C 专门负责短距离、多从机的读取UART 专门负责长距离、双向的通信。两者互不干扰调试时也容易定位问题。4. 画板子时那些让温度读数漂移的细节去耦、走线与屏蔽4.1 传感器供电与去耦传感器读数漂移很多时候不是传感器本身的问题而是供电没伺候好。PJ85718DM 这类传感器内部有测量电路对电源纹波比较敏感。如果直接用 MCU 板上的 3.3V 数字电源供电而这路电源已经给继电器、蜂鸣器之类的东西共用了温度读数就会周期性跳动。我的做法是在传感器的电源引脚附近加一个 0.1μF 陶瓷电容放在离引脚不超过 5mm 的位置如果传感器周围的干扰源多再串一个 10Ω 到 100Ω 的电阻配合电容组成 RC 滤波隔离高频噪声。数字信号线SCL、SDA上的上拉电阻也别忘了4.7kΩ 上拉到 3.3V 是稳妥的起步值I2C 总线上挂的器件多或者走线长可以降到 2.2kΩ但别低于 1kΩ否则下拉能力不够会导致通信异常。供电去耦这种细节原理上只是几个小元件但实际效果比在固件里写十层数字滤波都明显。4.2 传感器布局自热效应和热阻路径板载温度传感器有一个天然的问题自热。传感器工作时自身会消耗一点功率产生温升如果旁边还靠着 LDO 或者功率电阻那读数就更不准了。我建议 PJ85718DM 如果做板载测温不要贴着 MCU 放也不要放在板边铜箔面积特别大的位置。MCU 运行起来功耗不小板内会有几摄氏度的温升传感器离得太近会把芯片温度当成环境温度读出来。正确做法是让传感器和主发热源保持至少 1cm 的间距且传感器下方的 PCB 铜箔不要大面积铺地减少热传导通道。远程节点板就没这个问题因为节点本身就是个小板远离主要热源。反倒是现场安装位置要留意别把传感器贴在阳光直射的管道壁上也别贴在有保温层包裹的水管外层——保温层会把真实温度挡住测出来的其实是保温层表面的温度。4.3 远程 485 总线的终端匹配与偏置RS-485 总线的两个经典问题终端电阻不匹配、空闲电平不确定。一条总线上如果就一主一从两个节点距离又短几米以内终端电阻可以不加。但只要总线长度超过十米或者节点数超过两个我建议在总线最远端的两个节点上各加一个 120Ω 终端电阻匹配双绞线的特性阻抗减小反射。主控侧如果正好在总线一端那 120Ω 电阻也可以直接焊在主控板上终端接线端子附近。空闲电平的问题更隐蔽。RS-485 收发器在总线上没有设备驱动时A、B 之间的电平差可能落在接收器的阈值窗口里导致收到随机数据。解决办法是给总线加偏置A 线上拉到 3.3V通过 10kΩ 电阻B 线下拉到 GND通过 10kΩ 电阻让空闲时 A 比 B 高总线处于确定性的空闲高电平状态。这个偏置电阻放在主控这一端就够了因为主控是唯一持续上电的节点。5. 固件三件套读寄存器、滤掉毛刺、把码值校成摄氏温度5.1 I2C 读取流程与异常处理PJ85718DM 的数字读取流程很常规发送从机地址加写位写入温度寄存器地址然后发送从机地址加读位依次读回两个字节的温度数据。下面是一段示意代码寄存器地址和字节顺序以手上器件的规格书为准uint8_t temp_read_reg(uint8_t slave_addr, uint8_t reg_addr) { uint8_t buf[2] {0}; // 设置寄存器指针 i2c_start(); i2c_write_byte((slave_addr 1) | 0x00); i2c_write_byte(reg_addr); i2c_stop(); // 读取温度数据 i2c_start(); i2c_write_byte((slave_addr 1) | 0x01); buf[0] i2c_read_byte(ACK); buf[1] i2c_read_byte(NACK); i2c_stop(); // 组合成原始值并转换 int16_t raw (buf[0] 8) | buf[1]; return raw; }真正麻烦的是 I2C 通信出错时的处理。HVAC 现场总有莫名其妙的上电时序问题传感器还没就绪主控已经开始读数据了或者总线被某个节点短暂拉低后续操作全部失败。我读温度时从来不会只读一次就给结果至少做三次尝试第一次失败就把总线状态复位可以把 SCL 多翻转几次恢复总线等待几毫秒再试三次都失败就返回一个明确的错误码并把上一次有效值保留下来用数据陈旧标志告诉上层逻辑。宁可使用五分钟前的正确温度也不能用一个错的离谱的新温度去做防冻保护决策。5.2 一阶低通滤波让温度曲线变平滑温度本身是慢变量但 ADC 采样和传感器寄存器读取时难免混入突发干扰。HVAC 控制逻辑对快速跳变非常敏感——回风温度从 25℃ 瞬间跳到 3℃ 又跳回来控制器会以为发生了异常可能触发不必要的停机报警。我用的滤波很简单一阶低通滤波公式为y_n y_{n-1} alpha * (x_n - y_{n-1})其中 x_n 是本次采样值y_n 是滤波后的输出值alpha 是一个 0 到 1 之间的系数。alpha 越小滤波越重响应越慢。工程上 alpha 和时间常数 tau 的关系是alpha T / (T tau)T 是采样周期比如每秒采一次T1stau 是期望的滤波时间常数比如希望 30 秒稳定下来tau30s。那么 alpha 1/31 ≈ 0.032。这样算出来的滤波结果不会滞后太多又足够平滑。由于 TM4C123GH6PZ 带 FPU这种浮点运算是免费的性能完全不是瓶颈。但不建议直接用 float 打印到日志里整型化处理放大 100 倍存整数能避免后面做显示和越限比较时的精度怪问题。5.3 两点标定把原始值变成可信的温度值无论 PJ85718DM 出厂标称精度多好批量物料之间总存在个体偏差再加上传感器安装位置的导热条件差异实际系统最好做一次标定。最实用的方法是两点标定。先让传感器处于 0℃ 环境冰水混合物是比较容易实现的 0℃ 参考记下原始读数 raw0对应标准温度 T00再让传感器处于 50℃ 环境恒温水浴或者使用经校准的干井炉记下 raw1 和 T150。然后做线性校正T_calibrated T0 (T1 - T0) * (raw_value - raw0) / (raw1 - raw0)如果你的传感器输出是线性度很好的数字量这个两点校正就够了。如果传感器对应关系明显非线性那就得多取几个点做成查表加线性插值。查表分段越多效果越好但现场标定成本也越高。HVAC 应用做到两点校正已经很体面室内舒适度控制对温度误差的容忍度通常在一两摄氏度以内。6. 远程节点轮询报文格式、超时重试与断线识别6.1 简化的请求/响应帧格式远程节点用 UART 通过 RS-485 和主控通信。我在小型 HVAC 项目里不追求复杂的 Modbus 协议栈直接用一套精简的请求/响应帧帧头0xAA 0x55地址1 字节0x01~0x03命令1 字节0x01 表示读温度数据长度1 字节数据N 字节CRC81 字节覆盖地址到数据段主控发读温度请求远程节点返回 2 字节温度原始值加上 CRC。整个协议占用的代码量很小调试时用串口助手就能抓到完整报文非常直观。6.2 超时重试与断线判断485 总线是半双工的主控发完请求必须切换收发器为接收状态。这个切换时机如果不处理好会产生两个问题一是发完立刻切接收最后一个停止位被自己收发器的延迟吃掉二是数据还没收完就切到发送把对端回复截断。我的做法是发送完请求帧之后延时至少两个字符时间波特率 9600 时大约是 2ms再拉低收发器的方向控制引脚切到接收。接收时开一个超时定时器10ms 内收不到完整帧就算超时。连续超时三次就把这个节点标记为离线不再继续无效轮询而是每隔 30 秒再试探一次。以 9600 波特率轮询三个节点每个周期也就几十毫秒。HVAC 温度不需要毫秒级刷新这个速度绰绰有余。6.3 地址分配与节点枚举的现场经验远程节点的地址分配方式决定后面调试会不会骂人。拨码开关虽然土但在现场是最可靠的。地址冲突的时候工人拔掉一个节点的 485 线看主机那边少了哪一路数据就能定位是哪块板子。还有一个小技巧远程节点上电后不要立刻响应主控的任何请求先初始化传感器并完成首次自检再拉高一个状态 GPIO 点上 LED。主控侧发现某个地址离线时如果节点侧 LED 亮着说明软件问题如果 LED 不亮直接怀疑硬件或者供电。这个手段避免了现场带着万用表盲猜。7. 环境箱里跑出来的数据误差分析、总线故障与修正手段7.1 测试方法和工装硬件做完固件烧进去接下来是验证。我把主控板和远程节点一起放进环境试验箱温度从 -20℃ 一路升到 70℃每档稳定 30 分钟再用标准铂电阻温度计做参照记录三组数据标准温度、本地传感器读数、远程节点读数。测试时有个容易忽略的坑环境箱的鼓风机会产生强烈气流把传感器局部加热或冷却。传感器不要直接放在出风口下方给传感器加一个小的防辐射罩避免箱壁辐射热影响读数。测出来的数据才更有参考意义。7.2 实测数据与误差分析下面是一组典型的实测记录数值已做脱敏处理用来展示这边的分析思路标准温度 (℃)本地读取 (℃)本地误差 (℃)远程读取 (℃)远程误差 (℃)-20.0-19.70.3-20.3-0.30.00.20.2-0.1-0.125.025.30.324.8-0.250.050.60.649.8-0.270.070.80.869.6-0.4看这组数据正温区本地误差有变大的趋势而且都是正向偏大。这种情况通常不是传感器本身的非线性而是传感器自热和主控板发热导致的。前面说的布局建议在这里就起作用了把传感器移远一点或者把传感器供电电压降下来一些误差曲线会整体回落。远程节点反而很稳定因为节点板独立功耗小又没有主芯片在旁边烤。7.3 总线上最麻烦的几个毛病第一是总线卡死。现象是某个节点插上后整个总线的轮询全部超时。排查发现是该节点板上 485 收发器的 A、B 接反了导致总线一直处于驱动状态。用万用表量 A-B 电压正常空闲时应该在 0.2V 到 0.5V 左右如果接近 0V 或者负电压基本可以确定有节点反接或收发器损坏。第二是地电位漂移导致通信不稳定。主控板和远程节点如果从不同的开关电源取电两边的 GND 可能不是等电位的。RS-485 标准允许一定范围的共模电压但超过收发器允许范围就会丢包。把主控板和远程节点的 485 信号地GND用一根细线连起来问题通常立刻消失。第三是温度读数偶发跳变。用的是一根屏蔽双绞线屏蔽层只在主控侧单端接地结果还是出现偶发错误。后来查出来是现场有变频器变频器启动瞬间产生很强的共模噪声耦合到总线上。虽然 485 本身是差分传输但共模电压超过 -7V 到 12V 的规定范围还是会出错。在收发器前面加共模电感、把总线通信速率从 9600 降到 4800之后再没出现过跳变。8. 从静态监测走向控温闭环的顺带收益做完这套本地与远程温度监测以后控制的想象力一下子就打开了。原来主控只有一块板上温度作为控制依据风机启停、盘管防冻都只能靠设定值和经验判断。现在有了远端风道温度和水管温度控制器可以把这些值直接纳入控制逻辑送风温度低于设定阀值时加大加热比例盘管水温低于防冻阈值时自动进入防冻保护模式开关冷冻水泵回风温度和设定值之间的偏差作为 PID 控制器的输入输出直接驱动电动阀的开度。TM4C123GH6PZ 在这种闭环里跑得很轻松。80MHz 主频加 FPU跑三个 PID 回路外加滤波、标定、通信轮询CPU 占用率能压在 20% 以下。剩下的算力还可以用来做数据记录、运行时长统计、或者给触摸屏生成趋势曲线。如果你手头的项目已经能把温度稳定地采集上来下一批功能大概率就是往这个方向扩展把测点温度做成控制依据让本地与远程温度的差值变成系统诊断的手段。比如回风温度和送风温度差过大说明换热器效率下降室内温度和送风温度差长期偏大可能是风道阻力异常。这些判断不需要额外硬件固件里多几个比较逻辑就行。最后说一句实际体会一套系统测温链路是最基础也最容易被低估的部分。把传感器选型、布局、供电、滤波、通信这几环都做扎实了后面的控制算法才有可信的输入。如果一开始就只想着堆算法回头被一个漂移的温度值牵着鼻子走那调试周期会被拉得很长。这套 PJ85718DM 加 TM4C123GH6PZ 的最小系统我觉得是 HVAC 和嵌入式温度采集里非常适合作为样板复现的一套值得把它沉淀下来。 
长河君 · 2026/10/22 12:11:13 · 阅读 1.2k TM4C123GH6PZ与PJ85718DM实现HVAC本地/远程温度监测方案
做嵌入式和暖通空调HVAC项目做多了以后有个矛盾特别常见控制器自己盯着的温度和系统真正需要关心的温度往往不在一块儿。控制箱里38℃可风道送风口的温度已经掉到15℃以下了——如果只盯着板子附近的测点整个控制逻辑都会跑偏。这也是我为什么特别看好PJ85718DM与TM4C123GH6PZ这种组合一颗专门负责温度感知一颗专门负责采集、换算、通信和控制。这篇文章就围绕用 TM4C123GH6PZ 主控、配合 PJ85718DM 传感器在嵌入式以及 HVAC 场景里同时监测本地温度与远程温度来展开。文章里除了整体架构、电路要点和固件代码还会把画板、调总线、标定数据时容易踩的坑一起写出来。适合正在做暖通控制箱、楼宇自控、机房环境监控或者想用一个 MCU 统一管理分散测点的开发者参考。1. 从 HVAC 现场需求说起为什么本地和远程温度都得管1.1 一套暖通系统里温度测点到底要布多少先看实际场景。一套典型的小型 HVAC 控制器测点从来不止一个。回风温度从室内回到机组的空气温度是判断制冷/制热负荷的重要输入。送风温度处理完之后的空气温度直接关系到出风舒适度和盘管防冻。盘管/水管温度冬天水侧温度过低有冻裂风险夏天水温过高影响换热效率。箱内温度控制器内部或电控箱的环境温度用来评估电子器件自身的热负荷。室外环境温度热泵机组判断制热效率、除霜启动条件的关键参考量。这些测点有的就在控制器旁边有的要拉到几十米外的风道里、水管壁上。于是本地温度和远程温度的概念就自然分出来了。所谓本地就是主控板 PCB 上或控制箱内距离 MCU 很近、走线不超过十几厘米的测点所谓远程则是通过总线把传感器或不完整的数据链路延伸到机组其他地方。1.2 本地与远程的分界线到底划在哪里很多新手容易把远程温度理解成只要导线够长就行于是直接拉一根一米多的 I2C 线把传感器挂在主控上。这在实验室可能没问题到了工地现场往往翻车导线长了I2C 总线电容变大信号沿变钝连续读几十次就会出现一次错误帧现场又有变频器、接触器、电磁阀传导和辐射干扰一起上来读数跳得你怀疑人生。所以实际设计时要划一道清晰的分界线PCB 板内或控制箱内这种短距离、低噪声环境归本地采集超过一米、需要穿过强电区域或者要经过端子排的归远程采集。远程采集要么走差分信号总线要么用串行异步通信加可靠的协议层而不是简单地把传感器接口拉长。PJ85718DM 作为传感器端TM4C123GH6PZ 作为主控端两边正好可以把这条分界线落到工程实现上。2. 主控与传感器选型TM4C123GH6PZ 和 PJ85718DM 能扛住什么活儿2.1 TM4C123GH6PZ 的能力边界TM4C123GH6PZ 是 Cortex-M4F 内核带硬件浮点单元FPU主频可以跑到 80MHz。这个内核放在温度监测项目里意味着什么意味着你可以放心地做浮点滤波、做线性化校正、做温湿度补偿而不必去抠定点运算的精度和性能。温度换算本身并不重但 HVAC 控制器往往不止采温度它还要跑风机启停逻辑、读压差开关、驱动继电器或接触器、和触摸屏或上位机通信、甚至处理几路模拟量输入。TM4C123GH6PZ 的 256KB Flash 和 32KB SRAM 在这种组合负载下很从容。更关键的是它的外设资源——12 位 ADC 可以解决本地模拟量采集多个 I2C/SPI/UART 接口可以同时挂数字温度传感器和远程通信模块部分型号还带 CAN 控制器想升级成现场总线方案也留得余地。工作温度范围方面TM4C123GH6PZ 的工业级版本能覆盖 -40℃ 到 85℃。HVAC 设备现场环境往往没有机房那么友好控制箱在夏天暴晒后内部温度可以轻松超过 50℃冬天冷库场景又会到零下十几度宽温范围是必须的不是加分项。2.2 PJ85718DM 在温度监测里的角色PJ85718DM 常见的设计形态是数字化温度感知器件输出接口以 I2C 兼容接口为主有些批次的型号也支持模拟电压输出具体以手上器件的数据手册为准。它和 DS18B20 这类一线式传感器相比最大的不同在于地址管理PJ85718DM 的从机地址通常可以通过引脚配置出几个不同的地址这让它在一条 I2C 总线上挂多个测点时省去不少麻烦。我在这套方案里把它用在两个地方一个做本地板载测温直接放在 MCU 附近读回风温度另一个做成远程采集小板通过 RS-485 总线和主控连接去测送风温度和盘管温度。这样同一个器件在本地和远程两条路径上都得到了使用物料统一采购和备件都省心。2.3 为什么这个组合适合 HVAC 场景选 PJ85718DM 和 TM4C123GH6PZ不是因为它俩是参数最顶的器件而是因为匹配度。供电简单PJ85718DM 工作电压范围宽常见版本能在 2.7V 到 5.5V 下运行3.3V 供电直接和 TM4C123GH6PZ 的 IO 电平匹配不用做电平转换。精度够用暖通测控的精度要求通常没有工业仪表那么苛刻典型 ±0.5℃ 的精度已经足够支撑舒适度控制、防冻保护和能效统计。资源配对主控自带多种串行接口可以同时把 I2C本地传感器、UARTRS-485 远程总线、调试串口这三条通路跑起来外设不够不用改方案。这种够用但留有余量的组合比一味追求高分辨率传感器的方案在量产阶段更可控成本也更低。3. 系统架构本地采集与远程总线怎么搭最省心3.1 整体拓扑的规划思路这套方案的架构不复杂分为三级第一级是传感器节点。本地传感器直接挂在主控的 I2C 总线上远程传感器则做成独立的小节点板每个节点板上有一片 PJ85718DM 和一个 RS-485 收发器用一根双绞线串起来接到主控的 RS-485 接口上。第二级是主控板。TM4C123GH6PZ 在这里做三件事周期性读取本地 I2C 总线上的温度通过 UART 转 RS-485 轮询远程节点的温度把本地和远程数据做滤波、标定、越限判断然后通过另一个 UART 口上报给触摸屏或者上位机。第三级是数据输出。上报协议用 Modbus RTU 或者自定义的简单帧格式看项目要求。如果是楼宇自控集成走 Modbus RTU 会省很多对接成本如果只是自己控制逻辑内部用自定义协议更灵活。为什么不直接让远程节点也用 I2C 拉长线前面已经说了I2C 不适合远距离。HVAC 现场通常有强电设备I2C 的抗干扰能力撑不住。RS-485 是差分信号两根线上传的是相反电平共模干扰会被接收器抵消掉配合屏蔽双绞线和正确的接地策略长度几十米完全可行。3.2 远程节点的硬件构成每个远程温度节点板体积都很小核心就三样东西PJ85718DM 温度传感器、RS-485 收发器、一颗小的稳压器或者直接从 24V 总线取电降压下来。节点板与主控之间用四根线连接两根电源24V 或 12V视现场供电条件、两根 RS-485 信号线A、B。这种布线方式在 HVAC 设备里非常常见因为现场工人熟悉端子接线比让他们去压接屏蔽 I2C 线缆要靠谱得多。地址分配上主控这边通过拨码开关或者软件配置给每个节点分配地址。软件配置听起来高级但初次上电时要处理未配置地址的状态反而复杂。我习惯用两个拨码位组成 0 到 3 的地址一条总线上带三四个远程节点足够用了调试时掰开关就能换地址还能省掉专门的配置指令。3.3 主控板侧的资源分配TM4C123GH6PZ 的 I2C 模块和 UART 模块很多但别一上来就乱接。我在样板设计时把资源固定下来I2C0本地板载温度传感器。UART1RS-485 主站轮询远程节点。UART2数据上报 / 调试输出。GPIO节点地址读取、RS-485 收发方向控制、状态 LED。这样的分配逻辑很清晰I2C 专门负责短距离、多从机的读取UART 专门负责长距离、双向的通信。两者互不干扰调试时也容易定位问题。4. 画板子时那些让温度读数漂移的细节去耦、走线与屏蔽4.1 传感器供电与去耦传感器读数漂移很多时候不是传感器本身的问题而是供电没伺候好。PJ85718DM 这类传感器内部有测量电路对电源纹波比较敏感。如果直接用 MCU 板上的 3.3V 数字电源供电而这路电源已经给继电器、蜂鸣器之类的东西共用了温度读数就会周期性跳动。我的做法是在传感器的电源引脚附近加一个 0.1μF 陶瓷电容放在离引脚不超过 5mm 的位置如果传感器周围的干扰源多再串一个 10Ω 到 100Ω 的电阻配合电容组成 RC 滤波隔离高频噪声。数字信号线SCL、SDA上的上拉电阻也别忘了4.7kΩ 上拉到 3.3V 是稳妥的起步值I2C 总线上挂的器件多或者走线长可以降到 2.2kΩ但别低于 1kΩ否则下拉能力不够会导致通信异常。供电去耦这种细节原理上只是几个小元件但实际效果比在固件里写十层数字滤波都明显。4.2 传感器布局自热效应和热阻路径板载温度传感器有一个天然的问题自热。传感器工作时自身会消耗一点功率产生温升如果旁边还靠着 LDO 或者功率电阻那读数就更不准了。我建议 PJ85718DM 如果做板载测温不要贴着 MCU 放也不要放在板边铜箔面积特别大的位置。MCU 运行起来功耗不小板内会有几摄氏度的温升传感器离得太近会把芯片温度当成环境温度读出来。正确做法是让传感器和主发热源保持至少 1cm 的间距且传感器下方的 PCB 铜箔不要大面积铺地减少热传导通道。远程节点板就没这个问题因为节点本身就是个小板远离主要热源。反倒是现场安装位置要留意别把传感器贴在阳光直射的管道壁上也别贴在有保温层包裹的水管外层——保温层会把真实温度挡住测出来的其实是保温层表面的温度。4.3 远程 485 总线的终端匹配与偏置RS-485 总线的两个经典问题终端电阻不匹配、空闲电平不确定。一条总线上如果就一主一从两个节点距离又短几米以内终端电阻可以不加。但只要总线长度超过十米或者节点数超过两个我建议在总线最远端的两个节点上各加一个 120Ω 终端电阻匹配双绞线的特性阻抗减小反射。主控侧如果正好在总线一端那 120Ω 电阻也可以直接焊在主控板上终端接线端子附近。空闲电平的问题更隐蔽。RS-485 收发器在总线上没有设备驱动时A、B 之间的电平差可能落在接收器的阈值窗口里导致收到随机数据。解决办法是给总线加偏置A 线上拉到 3.3V通过 10kΩ 电阻B 线下拉到 GND通过 10kΩ 电阻让空闲时 A 比 B 高总线处于确定性的空闲高电平状态。这个偏置电阻放在主控这一端就够了因为主控是唯一持续上电的节点。5. 固件三件套读寄存器、滤掉毛刺、把码值校成摄氏温度5.1 I2C 读取流程与异常处理PJ85718DM 的数字读取流程很常规发送从机地址加写位写入温度寄存器地址然后发送从机地址加读位依次读回两个字节的温度数据。下面是一段示意代码寄存器地址和字节顺序以手上器件的规格书为准uint8_t temp_read_reg(uint8_t slave_addr, uint8_t reg_addr) { uint8_t buf[2] {0}; // 设置寄存器指针 i2c_start(); i2c_write_byte((slave_addr 1) | 0x00); i2c_write_byte(reg_addr); i2c_stop(); // 读取温度数据 i2c_start(); i2c_write_byte((slave_addr 1) | 0x01); buf[0] i2c_read_byte(ACK); buf[1] i2c_read_byte(NACK); i2c_stop(); // 组合成原始值并转换 int16_t raw (buf[0] 8) | buf[1]; return raw; }真正麻烦的是 I2C 通信出错时的处理。HVAC 现场总有莫名其妙的上电时序问题传感器还没就绪主控已经开始读数据了或者总线被某个节点短暂拉低后续操作全部失败。我读温度时从来不会只读一次就给结果至少做三次尝试第一次失败就把总线状态复位可以把 SCL 多翻转几次恢复总线等待几毫秒再试三次都失败就返回一个明确的错误码并把上一次有效值保留下来用数据陈旧标志告诉上层逻辑。宁可使用五分钟前的正确温度也不能用一个错的离谱的新温度去做防冻保护决策。5.2 一阶低通滤波让温度曲线变平滑温度本身是慢变量但 ADC 采样和传感器寄存器读取时难免混入突发干扰。HVAC 控制逻辑对快速跳变非常敏感——回风温度从 25℃ 瞬间跳到 3℃ 又跳回来控制器会以为发生了异常可能触发不必要的停机报警。我用的滤波很简单一阶低通滤波公式为y_n y_{n-1} alpha * (x_n - y_{n-1})其中 x_n 是本次采样值y_n 是滤波后的输出值alpha 是一个 0 到 1 之间的系数。alpha 越小滤波越重响应越慢。工程上 alpha 和时间常数 tau 的关系是alpha T / (T tau)T 是采样周期比如每秒采一次T1stau 是期望的滤波时间常数比如希望 30 秒稳定下来tau30s。那么 alpha 1/31 ≈ 0.032。这样算出来的滤波结果不会滞后太多又足够平滑。由于 TM4C123GH6PZ 带 FPU这种浮点运算是免费的性能完全不是瓶颈。但不建议直接用 float 打印到日志里整型化处理放大 100 倍存整数能避免后面做显示和越限比较时的精度怪问题。5.3 两点标定把原始值变成可信的温度值无论 PJ85718DM 出厂标称精度多好批量物料之间总存在个体偏差再加上传感器安装位置的导热条件差异实际系统最好做一次标定。最实用的方法是两点标定。先让传感器处于 0℃ 环境冰水混合物是比较容易实现的 0℃ 参考记下原始读数 raw0对应标准温度 T00再让传感器处于 50℃ 环境恒温水浴或者使用经校准的干井炉记下 raw1 和 T150。然后做线性校正T_calibrated T0 (T1 - T0) * (raw_value - raw0) / (raw1 - raw0)如果你的传感器输出是线性度很好的数字量这个两点校正就够了。如果传感器对应关系明显非线性那就得多取几个点做成查表加线性插值。查表分段越多效果越好但现场标定成本也越高。HVAC 应用做到两点校正已经很体面室内舒适度控制对温度误差的容忍度通常在一两摄氏度以内。6. 远程节点轮询报文格式、超时重试与断线识别6.1 简化的请求/响应帧格式远程节点用 UART 通过 RS-485 和主控通信。我在小型 HVAC 项目里不追求复杂的 Modbus 协议栈直接用一套精简的请求/响应帧帧头0xAA 0x55地址1 字节0x01~0x03命令1 字节0x01 表示读温度数据长度1 字节数据N 字节CRC81 字节覆盖地址到数据段主控发读温度请求远程节点返回 2 字节温度原始值加上 CRC。整个协议占用的代码量很小调试时用串口助手就能抓到完整报文非常直观。6.2 超时重试与断线判断485 总线是半双工的主控发完请求必须切换收发器为接收状态。这个切换时机如果不处理好会产生两个问题一是发完立刻切接收最后一个停止位被自己收发器的延迟吃掉二是数据还没收完就切到发送把对端回复截断。我的做法是发送完请求帧之后延时至少两个字符时间波特率 9600 时大约是 2ms再拉低收发器的方向控制引脚切到接收。接收时开一个超时定时器10ms 内收不到完整帧就算超时。连续超时三次就把这个节点标记为离线不再继续无效轮询而是每隔 30 秒再试探一次。以 9600 波特率轮询三个节点每个周期也就几十毫秒。HVAC 温度不需要毫秒级刷新这个速度绰绰有余。6.3 地址分配与节点枚举的现场经验远程节点的地址分配方式决定后面调试会不会骂人。拨码开关虽然土但在现场是最可靠的。地址冲突的时候工人拔掉一个节点的 485 线看主机那边少了哪一路数据就能定位是哪块板子。还有一个小技巧远程节点上电后不要立刻响应主控的任何请求先初始化传感器并完成首次自检再拉高一个状态 GPIO 点上 LED。主控侧发现某个地址离线时如果节点侧 LED 亮着说明软件问题如果 LED 不亮直接怀疑硬件或者供电。这个手段避免了现场带着万用表盲猜。7. 环境箱里跑出来的数据误差分析、总线故障与修正手段7.1 测试方法和工装硬件做完固件烧进去接下来是验证。我把主控板和远程节点一起放进环境试验箱温度从 -20℃ 一路升到 70℃每档稳定 30 分钟再用标准铂电阻温度计做参照记录三组数据标准温度、本地传感器读数、远程节点读数。测试时有个容易忽略的坑环境箱的鼓风机会产生强烈气流把传感器局部加热或冷却。传感器不要直接放在出风口下方给传感器加一个小的防辐射罩避免箱壁辐射热影响读数。测出来的数据才更有参考意义。7.2 实测数据与误差分析下面是一组典型的实测记录数值已做脱敏处理用来展示这边的分析思路标准温度 (℃)本地读取 (℃)本地误差 (℃)远程读取 (℃)远程误差 (℃)-20.0-19.70.3-20.3-0.30.00.20.2-0.1-0.125.025.30.324.8-0.250.050.60.649.8-0.270.070.80.869.6-0.4看这组数据正温区本地误差有变大的趋势而且都是正向偏大。这种情况通常不是传感器本身的非线性而是传感器自热和主控板发热导致的。前面说的布局建议在这里就起作用了把传感器移远一点或者把传感器供电电压降下来一些误差曲线会整体回落。远程节点反而很稳定因为节点板独立功耗小又没有主芯片在旁边烤。7.3 总线上最麻烦的几个毛病第一是总线卡死。现象是某个节点插上后整个总线的轮询全部超时。排查发现是该节点板上 485 收发器的 A、B 接反了导致总线一直处于驱动状态。用万用表量 A-B 电压正常空闲时应该在 0.2V 到 0.5V 左右如果接近 0V 或者负电压基本可以确定有节点反接或收发器损坏。第二是地电位漂移导致通信不稳定。主控板和远程节点如果从不同的开关电源取电两边的 GND 可能不是等电位的。RS-485 标准允许一定范围的共模电压但超过收发器允许范围就会丢包。把主控板和远程节点的 485 信号地GND用一根细线连起来问题通常立刻消失。第三是温度读数偶发跳变。用的是一根屏蔽双绞线屏蔽层只在主控侧单端接地结果还是出现偶发错误。后来查出来是现场有变频器变频器启动瞬间产生很强的共模噪声耦合到总线上。虽然 485 本身是差分传输但共模电压超过 -7V 到 12V 的规定范围还是会出错。在收发器前面加共模电感、把总线通信速率从 9600 降到 4800之后再没出现过跳变。8. 从静态监测走向控温闭环的顺带收益做完这套本地与远程温度监测以后控制的想象力一下子就打开了。原来主控只有一块板上温度作为控制依据风机启停、盘管防冻都只能靠设定值和经验判断。现在有了远端风道温度和水管温度控制器可以把这些值直接纳入控制逻辑送风温度低于设定阀值时加大加热比例盘管水温低于防冻阈值时自动进入防冻保护模式开关冷冻水泵回风温度和设定值之间的偏差作为 PID 控制器的输入输出直接驱动电动阀的开度。TM4C123GH6PZ 在这种闭环里跑得很轻松。80MHz 主频加 FPU跑三个 PID 回路外加滤波、标定、通信轮询CPU 占用率能压在 20% 以下。剩下的算力还可以用来做数据记录、运行时长统计、或者给触摸屏生成趋势曲线。如果你手头的项目已经能把温度稳定地采集上来下一批功能大概率就是往这个方向扩展把测点温度做成控制依据让本地与远程温度的差值变成系统诊断的手段。比如回风温度和送风温度差过大说明换热器效率下降室内温度和送风温度差长期偏大可能是风道阻力异常。这些判断不需要额外硬件固件里多几个比较逻辑就行。最后说一句实际体会一套系统测温链路是最基础也最容易被低估的部分。把传感器选型、布局、供电、滤波、通信这几环都做扎实了后面的控制算法才有可信的输入。如果一开始就只想着堆算法回头被一个漂移的温度值牵着鼻子走那调试周期会被拉得很长。这套 PJ85718DM 加 TM4C123GH6PZ 的最小系统我觉得是 HVAC 和嵌入式温度采集里非常适合作为样板复现的一套值得把它沉淀下来。