说实话，搞了几年HVAC相关的嵌入式项目，温度监测这块我一直有个体会：本地温度和远程温度，看着都是“读温度”，但做起来完全是两个难度等级。本地测的是设备自己身边的温度，线路短、干扰少、逻辑简单；远程测的是风管深处、回风死角、墙壁另一头的温度，线要拉十几米甚至几十米，环境里全是电机干扰和温度梯度。这次项目用了 PJ85718DM 这颗单总线数字温度传感器，配合 PIC32MZ1024EFF144 做主控，把本地、远程两路温度监测做进了一套系统里，整个过程从选型、画板到写驱动、调通信，最后联调跑通，踩了不少坑，也攒了一些经验。这篇就针对这套方案展开聊聊，适合正在做HVAC控制器、楼宇自控、环境监测类设备的工程师参考。
1. 项目需求拆解与整体方案设计
1.1 HVAC 温度监测的真实需求是什么
很多刚接触这类项目的同学会把需求理解成“把温度测出来，显示在屏幕上”，但实际上HVAC控制器的测温需求要比这复杂得多。拿这套方案面对的场景举例，整个设备有几层要求：
- 需要有一个反映“设备自身环境”的温度，这是本地温度。它用于判断电控箱是否过热、风机是否正常运行、主板周围环境是否在器件工作条件内。这个点位上偏差大，直接影响设备可靠性。
- 需要若干个远端温度，覆盖空调机组送风口、回风口、风管内气流温度、房间内温度等。这些温度是参与控制逻辑的核心输入，用于决定风机转速、冷热水阀开度、除霜判断等。
- 本地和远程温度必须汇聚到同一主控单元，统一处理、统一显示、统一上报。
- 工程上还要求布线不能太复杂、传感器成本可控、现场安装要简单、后期维护方便。
如果把这些需求直接翻译成技术指标，就是：主控要有足够的外设资源和处理能力，传感器要支持远距离多节点组网，数据接口要能同时覆盖本地显示和远程通信。这套方案最终选了PIC32MZ1024EFF144加PJ85718DM的组合，客户端要求是“能在嵌入式和HVAC应用里同时解决本地与远程温度监测”，实际上围绕的就是上面这些点。
1.2 为什么是“本地+远程”双路模式而不是统一走一路
一开始我也考虑过把所有的传感器全挂在同一条总线上，本地和远程都用一个接口，结果发现工程上有问题。本地传感器在电控盒内部，远程传感器在机组现场，两者的供电和走线环境差别很大。如果全部挂同一总线，一旦某个远程分支出问题，本地测温也会被拖累，连基本的设备保护温度都没了。
所以最终的结构是：本地温度用一颗PJ85718DM直接靠近主控板部署，走短走线。远程温度通过另一条总线往下挂，节点数可以到十几个甚至几十个。主控芯片内部跑两个独立的端口控制逻辑，物理上分开，逻辑上汇总。付出的代价是软件里要多写一套驱动，但对系统稳定性来说是值得的。
1.3 系统架构的完整链路
从功能角度看，这套系统的链路大概是这样：PJ85718DM传感器负责温度采集和数字化，数据经单总线传入PIC32MZ1024EFF144；主控跑几层逻辑，包括总线时序控制、点位管理、滤波校准、控制算法；然后数据分三条路出去，一路到本地显示屏用于现场查看，一路到串口/网口用于远程接入，还有一路存到本地存储介质用于断电记录。任何一路出问题都不能影响其他路，这就要求主控的资源规划从一开始就做好。
PIC32MZ1024EFF144在这套方案里其实有点“大材小用”，1MB闪存、512KB RAM，MIPS M5150内核带浮点单元，跑温度采集和PID逻辑非常富余。但正因为资源够，才能把上面的软件架构分层做得干净，调试效率也高。接下来的章节，我会把选型理由展开讲清楚。
2. 核心器件选型逻辑与参数对比
2.1 PJ85718DM 传感器选型思考
温度传感器选型，我第一反应不是看精度，而是看安装拓扑。模拟输出的热敏电阻和电压型传感器，在短距离板级测温里没问题，但一旦线拉长，干扰和压降就来了。数字传感器才是正解。
PJ85718DM是单总线接口的数字温度传感器，带唯一ROM地址，支持多颗并联在同一总线上。这意味着部署远程温度点时，只需要从现场拉一根信号线、一根地线，有条件的话再拉一根电源线，拓扑非常简单。测量范围覆盖-40℃到+125℃这个区间，HVAC大部分测温场景都在这个范围内。精度方面，典型值能做到±0.5℃以内，对HVAC的控制逻辑来说完全是够用的。
单总线协议本身有个好处：传感器内部完成了测温、ADC转换、补偿这些工作，MCU只需要按协议读写寄存器就行。开发层面省掉了信号调理电路设计和线性化校准程序，硬件开销和软件复杂度都降下来了。
2.2 PIC32MZ1024EFF144 主控资源盘点
PIC32MZ1024EFF144属于PIC32MZ EF系列，144引脚封装。我把项目真正用到的资源列了一遍：
- MIPS M5150内核，主频200MHz，带单精度浮点单元。温度控制里跑PID不愁算力，浮点运算不用软件模拟，代码写起来也省事。
- 1024KB闪存、512KB SRAM。程序空间大，可以把LCD驱动、Modbus协议栈、中值滤波、低通滤波全塞进去，还有大量余量做后期功能扩展。
- 外设种类多。UART接RS485、SPI接存储或显示、GPIO模拟单总线时序，这几个需求都能同时满足。
- 自带硬件CRC模块，Modbus RTU的CRC校验可以直接让硬件算，省CPU时间还减少出错概率。
144个引脚对这套系统来说数量是过剩的，但好处是引脚分散，走线容易，各路通信接口之间不容易打架。
2.3 与无线方案和其他总线方案的对比
做方案评审的时候，无线方案也讨论过一轮。远程测温用无线，好处是布线少，但问题也很实际：节点要供电，电池的话几个月就要换，维护成本高；有线供电的话，省掉的信号线意义也不大。温度和开关量这种控制信号，可靠性是第一位的，而无线信道的偶发丢包、入网配置、多节点干扰都是需要考虑的管理成本。所以这套系统坚持用有线方案。
至于为什么用单总线而不是RS485总线来带温度传感器，核心是两个原因：一是RS485需要每个节点有控制器芯片，传感器节点上就要另外加一颗单片机和RS485收发器，单节点成本凭空多出几块钱，点位数一多成本差距就出来了；二是单总线的协议天然就是为“传感器挂总线”设计的，读温度就是一个命令一个数据，别的事情不用管。RS485更适合连接已具备独立控制逻辑的第三方设备，比如变频器、中央空调面板、电表，那个路线是另一套设计。
任何方案都有适用边界，选型的关键是匹配场景。对“主控带一堆温度传感器”这个场景，单总线是性价比最高的选择。
3. 硬件电路设计与关键参数计算
3.1 供电方式选择：三线制比寄生供电稳
PJ85718DM支持两种供电方式：寄生供电和外部供电。寄生供电只走两根线，信号线兼做电源线，传感器靠信号线上的高电平内部蓄能。这设计初衷是为了省线，但我做过几个项目后，还是建议优先选外部供电。
原因很简单，寄生供电在总线上挂的点位多、线路长时，很容易出现“电压被拉垮”的现象。特别是在温度转换这种大电流工作阶段，每颗传感器从信号线上偷电，距离远的点位电压低到一定程度，内部稳压就保不住，转换结果自然不可靠。远程点位多的时候，总线一忙，读回来的温度偶发跳变，查起来头痛。
所以这套系统里远程节点全部采用三线制：VDD、GND加DQ信号线。VDD用5V系统电源统一供电。传感器的DQ输出虽然是开漏结构，但VDD供上去后逻辑电平是跟随供电的，所以接口电平需要注意和主控GPIO的匹配关系。
3.2 上拉电阻的取值计算
单总线空闲时要求DQ为高电平，必须接上拉电阻。但这个电阻取多少，网上说法五花八门，实际要结合总线长度和节点数量来算。
总线寄生电容和节点输入电容会影响边沿时间。电阻取得太大，RC充放电太慢，时序边缘陡度不够；取得太小，总线低电平时负载电流变大，传感器下沉电流不够，电平会被拉不下来。
我用过的经验值是这样分的：
- 板内短距离（1-3米）、1-5个节点：上拉4.7kΩ最稳；
- 3-10米、5-10个节点：上拉降到2.2kΩ；
- 超过10米：总线两端都做上拉，主控端2.2kΩ，远端再加一颗1kΩ-2.2kΩ，具体值以示波器实测边沿为准。
这个不是算完就不动的。我一般会在现场拿示波器量总线波形，确保上升沿满足协议要求的至少1μs/阶。如果发现边沿有明显圆角，就把电阻调小半档再看。
3.3 去耦电容、ESD保护和线缆布置
每颗PJ85718DM的VDD与GND之间，必须放一颗100nF陶瓷去耦电容，而且这颗电容要尽量贴着传感器引脚放。数字温度传感器内部有比较敏感的模拟电路，去耦不好的话，总线上的尖峰会直接干扰到内部转换结果，表现出来的现象就是读数偶发跳变。
传感器在HVAC现场安装，线缆会经过风道、电机附近，静电和感应电是绕不开的。我在每颗远程传感器的DQ引脚对地加了一颗ESD保护二极管，选型用常见的工业级ESD管就行。总线进入控制柜的位置加了一个可恢复保险丝，防止外部短路往上端设备蔓延。
布线方面还有一个细节：单总线信号线尽量不要和AC220V强电走同一个线槽。如果条件限制必须共槽，信号线要选带屏蔽层的双绞线，屏蔽层单端接地，否则电机启停瞬间的感应电压足以把总线状态机打乱。这在HVAC设备里是很容易踩的坑。
3.4 本地传感器的PCB布局注意事项
本地那颗传感器的位置在画板时就要重点考虑。我见过很多项目把本地温度探头放在CPU旁边，测出来比环境温度高出好几度，控制逻辑又拿这个温度去判断机箱是否过热，结果误报警。
正确做法是：把本地传感器放在进风口或电控盒内部气流相对稳定的区域，远离变压器、继电器、大功率电阻这些局部热源。如果要测的是电控盒内部环境温度，传感器周围要有通风孔，不要闷在个角落里。如果意图是测散热器温度，那探头就要贴在散热器翅片上，并加导热硅脂。不同的测温意图对应不同的探头安装方式，这一点在项目需求阶段就要和结构工程师对齐。
4. 软件系统架构与驱动实现
4.1 软件分层设计思路
这套系统的软件如果全部塞进一个大循环，后续维护会非常痛苦。我按BSP、中间层、应用层的结构来组织代码。
BSP层负责最底层的硬件操作，包括GPIO初始化、定时器配置、单总线时序模拟、串口DMA收发、掉电存储驱动。这一层向上只暴露功能接口，比如读温度、写寄存器、发送一帧串口数据。
中间层实现具体的传感器管理和通信协议，包括ROM搜索、点位表管理、温度读取流程、Modbus协议栈、滤波算法。这一层不关心温度读来之后去控制什么，只负责把数据变成可信赖的工程变量。
应用层跑的是控制逻辑和显示逻辑，例如根据温差联动风机、超温报警、LCD刷新、按键响应。这样的分层让每一块都能单独测试，改控制逻辑不会动到底层驱动，非常适合同一套硬件衍生多个项目的开发模式。
4.2 单总线时序模拟关键技术点
PIC32MZ1024EFF144芯片本身没有单总线外设，时序必须用GPIO模拟。好在温度传感器的通信速率不高，复位脉冲只需480μs，读时隙和写时隙都在60-120μs这个量级，主频200MHz下用空循环延时绰绰有余。
但模拟单总线有个细节：读写时序对延时精度有要求，不能简单地用普通空循环敷衍。我建议的处理方式是用定时器做微秒级延时基准，写一个delay_us函数，然后在临界时隙上用GPIO寄存器直接操作，避免库函数调用开销导致时序抖动。
这是PIC32的GPIO操作技巧：直接操作PORT寄存器而不是调用抽象的引脚操作函数。比如拉低引脚，用PORTC的对应位清零指令直接操作，一个写寄存器指令就完成了，耗时固定。如果走库函数的模式配置和电平设置，中间可能插入参数检查，在高主频下也容易出现几微秒的偏差。
最后给出的建议是不要用工具链自动生成的图形界面点出来的代码直接跑驱动，最好把时序敏感的代码自己手写一遍，确保每个延时边沿都紧贴协议规格。
4.3 复位与存在检测驱动代码示例
单总线通信的第一步是复位，主控拉低总线480μs以上，然后释放，传感器会拉低总线60-240μs作为应答。这段代码是整个驱动的基础，一定要扎实。
#define OW_PORT PORTC #define OW_PIN BIT(3) // 微秒延时，基于核心定时器实现 void delay_us(uint32_t us); // 复位脉冲并检测是否存在 uint8_t onewire_reset(void) { uint8_t presence = 0; // 配置为输出并拉低 OW_PORT &= ~OW_PIN; TRISC &= ~OW_PIN; delay_us(500); // 复位脉冲至少480us // 释放总线，切换到输入 TRISC |= OW_PIN; delay_us(60); // 读取是否有传感器拉低应答 if ((OW_PORT & OW_PIN) == 0) { presence = 1; } delay_us(420); // 等待复位时序完整结束 return presence; }代码里有个关键点：释放总线后要等60μs再读引脚。这个时间是协议允许的从释放到读应答的最小等待，目的是让远端传感器有足够时间判断总线释放并拉低应答信号。如果读取太早，可能正好采到总线还维持在高电平的时刻，导致误判没有设备，每轮都复位失败。
4.4 ROM搜索与多节点点位管理
总线上挂多颗传感器时，主控必须先做一次ROM搜索，把每颗传感器的唯一64位地址找出来。这个过程在原理上类似二叉搜索树：发送搜索命令后，按位读两位数据，再读一位补码，根据冲突情况决定下一步的搜索方向。
实际调试时我发现，在PC上写搜索算法好写，但下到嵌入式设备里跑，如果位操作不小心就容易出bug，尤其是冲突位记录和栈回溯，一个索引算错，整棵搜索树就歪了。我建议第一版先用一个简单的实现，单总线上挂两颗传感器，用串口把搜索过程逐位打印出来，手工核对每一轮的分支方向。
工程效率最高的做法其实是“预注册制”：在现场调试阶段用排查工具把每颗传感器的ROM码读出来，直接在代码的配置表里写死。这样量产设备上电后不需要执行搜索流程，直接按注册表轮询就行。好处是启动时间短、逻辑简单、现场加点位时只要改配置表。
4.5 温度读取与转换等待优化
PJ85718DM的温度转换有一个等待时间问题。每颗传感器从发出转换命令到结果稳定，12位分辨率下大约需要750ms。如果一颗一颗轮询并等待转换完成，挂10颗传感器就是7.5秒一轮，明显太慢。
省时间的办法是让总线上所有传感器同时开始转换。发完转换命令后，主控不是去读温度，而是先把所有传感器都发一遍转换命令，统一等一段时间，再分时去读每颗的暂存器数据。这样一轮总耗时还是750ms加读取时间，而不是点数乘以750ms。这个优化思路在任何多节点温度采集系统里都适用。
完整读取流程大致是：
- 复位总线；
- 发跳过ROM命令（如果只有一颗）或发匹配ROM命令带上对应地址；
- 发温度转换命令；
- 等待转换完成；
- 重启总线，进入读暂存器流程；
- 连续读9个字节的暂存器数据；
- 从暂存器中解析温度值、报警阈值、配置字节；
- 关闭该传感器的操作，切到下一个。
4.6 温度解析代码实现
PJ85718DM的温度结果以16位带符号数形式保存在暂存器的第1和第2字节。解析时要注意字节序，低字节在前，高字节在后，符号位在高字节的最高位。解析后按分辨率换算成实际温度值，12位分辨率下每个LSB是0.0625℃。
int16_t temp_raw; float temp_c; temp_raw = (reg[1] << 8) | reg[0]; if (temp_raw & 0x8000) { temp_raw |= 0xF000; // 处理负温度的情况 } temp_c = temp_raw * 0.0625f;负温度的补码处理是新人容易翻车的地方。PIC32MZ有浮点单元，乘0.0625f是单精度运算，没有精度损失，这点比8位单片机强很多。
读回来的暂存器数据还要校验一下CRC。单总线协议里第9字节是CRC校验，前面的8个字节都参与计算。我在驱动里直接用查表法实现CRC校验，生成多项式用标准的多项式，校验失败就判定该帧无效，本次不更新温度值。
5. 数据滤波、校准与可靠性保障
5.1 中值滤波剔除毛刺
温度是慢变量，正常情况下不该有瞬时跳变。但实际现场总线偶尔受干扰，或者传感器内部转换异常，就会冒出一个明显和前后数据不符的毛刺值。如果这个毛刺直接进入控制逻辑，可能导致风机误动作。
我用的是“滑动窗口取中值”策略：每颗传感器保存最近5次有效采集值，排序后取中间那个作为本次最终值。窗口长度选5，是因为太短滤不掉毛刺，太长又会引入明显延迟。HVAC的温度控制响应速度本来就不要求毫秒级，中值滤波带来的几十秒延迟完全可以接受。
5.2 一阶低通滤波平滑温度曲线
中值滤波处理完毛刺之后，输出值在时间轴上仍可能有一格一格的微小台阶。为了让温度曲线更平顺，再加一层一阶低通滤波。
滤波公式是：
T_f = α × T_new + (1 - α) × T_f
α取值，在HVAC场景我用过最顺的是0.2左右。α越大响应越快但越不平滑，α越小越平滑但滞后越多。温度本身就是慢变量，滞后一点不影响。如果用于工业精密控温，这个参数要重新标定。
双滤波的组合效果，实测下来整条温度曲线非常稳定，风扇启停、电机干扰在现场示波器上能看到总线有噪声尖峰，但读回来的温度序列始终一平如水。
5.3 多点温度校准策略
PJ85718DM出厂有校准数据，但不同传感器之间仍然存在离散偏差。HVAC项目对绝对温度精度的要求通常在±0.5℃到±1℃之间。如果要求±0.3℃以内，单靠出厂校准是不够的，现场要做修正。
我的校准做法是线性平移加斜率修正：
T_corrected = T_raw + offset + slope × (T_raw - T_ref)
其中T_ref是校准基准温度点。操作时把传感器和标准温度计放进同一个保温桶，稳定一段时间后记录差值。如果只做一个温度点校准，那slope就取0，只做平移。如果做两个温度点（比如5℃和一个35℃），可以算出slope和offset，整体修正效果更好。
校准数据要单独存放在配置区或EEPROM里，不能写在源程序里。因为现场重新校准时，在线改设备比返厂烧录要方便得多。我在这套系统里给每个远程点位单独分配了一个校准偏移项，这样上位机工具在调试现场直接下发偏移量，不用重新编译固件。
5.4 传感器故障识别与保护逻辑
可靠性保障还有一个重要环节：怎么识别传感器坏了还是线断了。温度采集负责设备保护，如果传感器故障没被发现，主控可能拿着一个错误的温度做控制。
判断策略可以这样：
- 连续多轮采集超时且CRC校验失败，判定该通道通信故障；
- 读回温度超出传感器量程上限（比如高于125℃），判定读数非法；
- 温度变化斜率超过物理极限（比如1秒内变化超过10℃），判定数据异常。
检测到传感器故障后，应用层进入安全保护模式。HVAC设备中，这个模式至少要做到：使用失效前最后一次有效温度值维持当前控制状态、同时被保护置位，不是靠串口告警、触发本地显示故障码，并停止相关的联动控制策略。
6. 本地显示与远程通信方案实现
6.1 本地人机交互设计
现场维护人员需要能直观看到每个温度点。显示屏我用的是常见的12864点阵LCD，分成两行显示区域。第一行固定显示本地温度，第二行轮播显示各个远程温度点，轮播间隔1.5秒左右。
显示刷新频率不要太高。每秒刷新1次足够，人眼感觉不到卡顿，LCD也不会出现闪烁。刷新时只改变化的字符区域，不要整屏清屏重画，避免视觉跳动感。
按键交互做成了最简单的翻页模式，上下键切换远程点位显示页，确认键进入校准模式，校准模式下可以本地输入偏移量。这里的按键逻辑一定要做防抖，延时去抖后还要判断长按和短按，防止现场人员误操作。
6.2 远程通信硬件链路设计
远程接入分两路设计。第一路是RS485，走Modbus RTU协议。PIC32MZ的UART外设通过外部RS485收发器转成差分信号，适合长距离接到上位机或楼宇系统。RS485硬件上需要做终端匹配电阻，在总线两端各放一个120Ω电阻，避免信号反射。
第二路是以太网，走Modbus TCP协议。PIC32MZ自带以太网MAC，外部再接一颗工业级PHY芯片，通过RJ45接口出去。这套方案适合接入TCP/IP网络的管理平台。
RS485链路上，波特率我选9600bps，温度数据量小，1秒轮询一轮完全够用。9600bps的通信距离和抗干扰性都比高波特率好，在工业现场这是一道很实用的取舍原则。
6.3 Modbus RTU协议栈实现要点
Modbus RTU的帧格式是地址加功能码加数据加CRC16，协议本身很简单，但实现质量差别很大。CRC16校验是整个协议栈最基础的部分，我用查表法实现，一张256字节的CRC表，计算一帧数据只要循环几次查表和异或操作，远比逐位计算快。
当前这套系统的寄存器映射定义是：
- 0x0000：设备类型与固件版本
- 0x0001：本地温度值（带一位小数）
- 0x0002-0x0011：远程温度值（共16个点）
- 0x0020：传感器故障标志位，每个bit对应一个点位
- 0x0021：主控运行状态（在线/故障/校准）
上位机每秒钟读取一次这个寄存器组。如果某寄存器长时间无更新或读到异常值，上位机侧的监控逻辑可以判定通信异常。
6.4 Modbus TCP协议栈考虑
如果硬件已经带了以太网MAC，上Modbus TCP实际上是锦上添花。Modbus TCP不需要CRC校验，因为TCP/IP协议栈已经保证了传输层的可靠性。协议栈内部只需处理MBAP报文头的封装和解析。
PIC32MZ运行以太网协议栈加上Modbus TCP任务，资源占用不大，实测在100ms的查询周期下，响应始终在10ms内返回，完全没有卡顿。
6.5 数据掉电保存与日志记录
设备在运行过程中需要保存两类数据：一类是配置参数，比如每颗传感器的校准偏移、点位使能状态；另一类是运行数据，比如温度历史极值、故障发生时间。PIC32MZ内部的flash可以用来做数据记载，但要注意flash的擦写寿命问题，不能频繁擦写同一地址。
我的做法是参照EEPROM模拟的思路做磨损均衡：把数据写到固定区域，按顺序依次使用扇区，写完后记录当前扇区号，下次写入换下一个扇区。再加上系统的硬件CRC模块来校验数据完整性，掉电再上电后能恢复最后一次正确配置。
7. 联调测试与常见问题排查实录
7.1 从单点到多点联调的过程记录
整个联调过程我建议分三步走。第一步把本地传感器和主控板调通，确认单点读温正常，这个阶段我卡了很久，最后发现是复位时序的问题，主控带了很多外设导致中断频繁，复位脉冲被中断打断，拉了不止500μs，导致传感器状态机跑飞。后来在关键延时段关中断，问题解决。
单点正常后再挂远程总线，先挂1颗远点，测信号完整性。实测10米线缆加上去，用4.7k上拉电阻时读回来的数据偶发失败，换2.2k电阻后波形明显改善。再从1颗增加到4颗、8颗、16颗，依次检查每颗数据的连续性和平均读帧时间。
最后测试整机的湿度环境，把设备放进高低温箱，从-20℃到60℃步进测试，观察各点位的线性度偏差。
7.2 总线通信失败与复位失败排查
现场调试遇到最多的错误就是复位失败，表现为某个通道完全读不到存在应答。排查顺序是这样的：
第一，用示波器测主控侧和传感器侧的复位时序，看是不是复位脉冲长度不足或过长。复位脉冲过长也会出问题，我见过一例代码把复位时隙写成了10ms，传感器任何状态都会被强制复位，但后续状态判断错乱。
第二，检查总线上是否有设备把电平拉死。总线拉死时，主控释放总线后电平仍然不为高，或者一直表现为低电平。用万用表或示波器看空载总线电压，如果始终接近0V，基本可以判定某个节点把线拉死了。排查方法是拔掉所有节点，逐个接回测试。
第三，确认上拉电阻在总线上实际的位置。如果上拉电阻放错了端，总线远端波形会明显变差，误码率升高。
7.3 读数跳变的问题实例
某次现场测试，远程一颗传感器读数在正常温度和85℃之间反复跳。查了供电电压正常，总线波形正常，传感器附近也没有强干扰源。后来拆开检查才发现，那颗传感器的VDD引脚旁边没有配去耦电容，焊接的时候因为空间紧张，把这颗电容省略了。总线上的尖峰直接进到芯片电源引脚，导致内部转换电路异常，读回了一个极限值。
补上100nF电容后，问题彻底消失。我的建议是把“每颗传感器必须就近放去耦电容”写进PCB设计规范，不能因为省空间就省略。
7.4 总线超过20米后的信号完整性处理
有一轮外场测试，总线实际走到大约20米时，出现“能枚举到传感器，但定期有某几个点位读取超时”的情况。这是因为远距离下总线信号上升沿变缓，在边沿处采样不确定。
处理办法有几板斧，我最后按顺序都上了：
- 上拉电阻从2.2k降到1k；
- 总线末端再并一个1k上拉电阻；
- 传感器读取周期从每500ms一轮放松到每1秒一轮；
- 尽量让总线走线与强电分离。
处理完后再测，连续跑24小时没有超时。总结下来，单总线拉长距离没有想象中那么脆弱，关键是上拉电阻和走线环境必须到位。
7.5 常见问题速查表
| 症状 | 可能原因 | 快速排查手段 |
|---|---|---|
| 所有传感器无应答 | 复位时序错误、上拉缺失、总线短路 | 示波器量复位波形、查空载总线电平 |
| 单一点位读数跳变 | 该节点去耦电容缺失、总线附近强干扰 | 补电容、换屏蔽线、观察波形 |
| 远距离偶发超时 | 上拉不足、上升沿过缓 | 降低上拉电阻、远端加上拉 |
| 温度整体偏差一致 | 判断基准温差、探头安装位置不当 | 用标准表校准、调整探头位置 |
| 只有部分节点能读到 | ROM搜索代码问题、CR不匹配 | 逐颗检查ROM、用预注册方式轮询 |
7.6 现场温度对比实测
整机跑完一轮，在模拟风箱上做了72小时连续运行。本地温度点在风箱电控盒内部，远程温度点分别在风箱送风口、回风口和距离主控约12米的房间侧壁。用标准玻璃温度计做参考，实测结果：
- 本地温度连续波动范围在±0.2℃以内；
- 远程送风口温度与参考温度偏差0.2℃；
- 远程回风口偏差0.4℃；
- 12米外房间侧壁点位偏差0.5℃以内。
三个点位在校准后偏差均控制在工程要求范围内。远程通信链路在上位机以1秒周期连续轮询，72小时内Modbus RTU报文零超时、零CRC错误。整个系统的稳定性符合预期。
这里有一个现场安装的经验值得单独拿出来说：远程探头固定位置如果贴近金属管道壁，读数会和真正的空气温度差出两三度。原因很简单，金属壁的温度受环境传热影响，和气流温度并不是一回事。探头要往气流中心伸，并且固定支架要用导热系数低的材料，减少管壁通过支架向探头传热。这个细节我踩过坑，后来改成塑料支架加探头悬空安装，偏差明显下降。
还有一件事是后期维护视角的：温度监测系统的点位配置表不要烧死在固件里，最好做成上位机可读写的配置区。现场工程师换一个传感器，只需要在上位机改ROM编码和偏移量，不需要重新编译烧录整机固件。第一次做的时候我嫌麻烦没做，第二次整机维护时后悔了，现在这个配置管理功能已经是标配。
做温度采集这个模块，技术难点其实不在“读”这个动作，而在怎么把大量现场环境因素都考虑进去。很多工程师调通驱动就跑，结果整套设备在现场一通电，三天两头出读数异常。我的习惯是每加一个远程点位，都要拿示波器看波形、模拟断线、模拟干扰、做连续运行压测，确认不至于被现场环境牵着鼻子走，才敢往下做。
这次的PJ85718DM加PIC32MZ1024EFF144方案，算是在测温成本、布线简单度、系统可靠性和维护便利几个维度之间找到了一个平衡点。如果你手头也在做类似的多点温度采集和HVAC控制项目，这套思路和代码结构可以直接拿去做参考，但上拉电阻、滤波参数、校准流程这些工程参数，建议还是结合你自己的现场环境重新标定一轮。
