做HVAC控制器这几年，有一类需求碰到过太多次了：既要读设备本地的回风温度，又要同时盯住好几个远端风管、水管甚至室外的温度点。最近完成的某项目里，我就用PJ85718DM温度传感器搭配PIC18F66K40单片机做了一套本地+远程温度监测方案。整套方案折腾下来，感觉它在成本、功耗和灵活性上确实能打，特别适合中小批量的嵌入式产品和暖通系统。这篇博文把架构思路、硬件连接、底层驱动、远程通信以及调试踩坑的过程都整理出来，给准备用类似方案的朋友做个参考。
1. 系统架构设计：先分清“本地”和“远程”到底怎么定义
1.1 需求拆解：嵌入式侧与HVAC侧的差异
很多人一看到“本地与远程温度”，第一反应就是“一个温度传感器放在本地，远程用网络去读取”。但实际上在HVAC应用里，这两个词的含义要更具体一些。本地温度往往指的是控制器附近、设备机箱内部或者回风口附近的温度；而远程温度则可能是几米外的送风管道、几十米外的冷热水管道、甚至安装在外墙上的室外温度传感器。
从这个角度看，要解决的不是“一个传感器”的问题，而是“一组分布在不同位置、距离控制器远近不一的传感器”的问题。嵌入式应用则更看重实时性和稳定性，传感器必须能在工业电压波动、电机启停干扰的恶劣环境下可靠工作。PIC18F66K40作为一款8位单片机，定位就很合适：主频够用、外设丰富、价格友好，还能兼顾多种通信接口。
我做方案时定的原则是：单总线或数字接口方式的长距离分布式采集优先，能一根线挂多个传感器就绝不一个点拉一根模拟线。这也是后来选了PJ85718DM的直接原因。
1.2 器件选型：为何选PJ85718DM与PIC18F66K40
先说说PJ85718DM这颗传感器。从手册参数看，它是一款单总线（1-Wire）数字温度传感器，典型测量精度在±0.5°C以内，测量范围覆盖了-55°C～+125°C，这个范围对HVAC系统来说绰绰有余。最关键的是它支持一根数据线上并联多颗，每个传感器都有独立的64位序列号，主机可以按号寻址，这简直是多点温度采集的天然方案。
与传统的NTC热敏电阻方案相比，数字传感器最大的优势就是不需要做ADC校准，不需要在板上焊一堆分压电阻，线长一些也不怕信号衰减。单总线还允许传感器从数据线上寄生取电，某些布线上确实方便。而PIC18F66K40这颗单片机，内部有32KB程序存储器和4KB RAM，跑个单总线协议加上Modbus远程通信的活儿毫无压力。它自带丰富的定时器、UART、SPI和I2C模块，硬件资源分配起来很灵活。
选这颗芯还有一个重要的点：它支持外部5V供电的同时内部逻辑电平可以配置，和3.3V或者5V的外设都能对接，省了电平转换芯片，这在工业设备里很实用。
1.3 整体链路规划：传感器、MCU、上位机之间怎么衔接
我的整体链路是这样设计的：若干个PJ85718DM传感器分布在各个测温点，所有传感器并联在一条单总线上，由PIC18F66K40的一个普通GPIO引脚驱动。单片机按照轮询方式，依次发出跳过ROM或按序列号匹配的命令，读取每一路温度。之后，单片机本地处理这些温度数据，一边把结果显示在本地LCD屏或者通过按键切换查看，另一边通过UART连接的RS485收发器，以Modbus RTU从机的方式挂到总线上，让上位机组态软件或楼宇自控系统来读。
如果需要走无线，也很简单：把RS485换成WiFi模块或者LoRa模块，单片机侧的逻辑基本不用改，只是把寄存器里的温度值通过串口转发出去。这样做的好处是“传感层”和“传输层”解耦，调试时可以先用串口线看数据，确认传感器链路没问题后再接远程通信，减少多层问题交叉排查的麻烦。
2. 硬件设计要点：从传感器接线到MCU外围电路
2.1 PJ85718DM的典型接法与关键参数
PJ85718DM虽然用起来简单，但硬件上有一个地方不能马虎——上拉电阻。单总线协议要求数据线在不通信时处于高电平，所以必须在数据线和一个正的电源（一般是3.3V或5V）之间接一个电阻。这个电阻多大很有讲究，我实测下来，在供电电压为3.3V、传感器数量不超过10个、线缆长度在10米以内时，用4.7kΩ比较稳定。如果线很长或者传感器数量多，就要降到2.2kΩ甚至1.5kΩ，不然上升沿太慢，时序容易出错。
传感器的VDD引脚我建议还是单独接电源，不要依赖寄生供电。虽然单总线支持寄生供电模式，但HVAC设备启动瞬间电流波动大，寄生供电模式在上电时序上容易出问题。我在实验室里试过用寄生供电挂了6颗传感器，刚上电时偶尔会读到全85℃的假数据，改成外部供电之后这个问题基本绝迹。
接法上还要考虑保护器件。传感器如果放在室外或者空调风管附近，引线很容易受雷电感应或静电冲击。我一般会在接口处加一颗小的TVS二极管，把数据线对地钳位在6V左右，再串一个100Ω的电阻做限流。别小看这几个元件，能省掉不少现场返修。
2.2 PIC18F66K40最小系统设计经验
PIC18F66K40的最小系统不算复杂，但有几个坑要避开。时钟我直接用内部16MHz振荡器，通过寄存器配置成16MHz，这样可以省掉外部晶振的两个负载电容，PCB面积也小。不过要注意，内部振荡器的精度大约在±1%左右，如果后面要用Modbus RTU跑19200bps以上的波特率，就最好改用外部晶振或者把波特率误差算进去。实测9600bps下内部振荡器完全没问题，19200也能用，但我不建议再往上硬拉。
复位电路用最简单的RC复位或者直接接VDD就行，PIC18系列内部本身有上电复位和欠压复位模块。我通常只在MCLR引脚接一个10kΩ电阻到VDD，再并联一个100nF电容到地，基本不会出问题。电源引脚要就近放0.1μF陶瓷电容，另外再留一个大一点的电解电容给整个系统缓冲，尤其是带LCD屏幕和RS485收发器的时候，瞬态电流能到几十毫安，没有大电容容易复位。
单总线引脚的选择上，我建议把它放在一个没有复用下载调试功能的引脚上，尤其是使用ICSP编程时不冲突的引脚。另外，这条数据线不要和AC220V或者24V交流线走在一起。我有个项目因为布线空间紧张，把传感器线和24V电磁阀线捆在一起，结果温度数据时不时跳变，后来改成独立屏蔽线并且单端接地，才恢复正常。
2.3 硬件装配与测试注意点
板子回来后，先不要接传感器，用示波器看单总线引脚的静态电平是否被上拉到高电平。然后把一颗PJ85718DM插上，发一次复位脉冲，看示波器上是否存在传感器应答的低脉冲。这一步能快速确认芯片焊接和引线是否正常。我习惯把传感器接口做成三线端子：VCC、GND、DATA，不要用那种防水插头一根线又供电又传数据的接口，维修时拔插容易搞错。
3. 软件实现：从单总线时序到温度采集与滤波
3.1 单总线驱动层的时序怎么抠
PJ85718DM和经典的DS18B20时序非常接近，都是通过拉低总线时间的长短来写0和写1。时序这块是软件里最需要抠细节的地方。写0期间，主机拉低总线60~120μs；写1期间，主机拉低约1~15μs后释放总线，然后依靠上拉电阻恢复高电平。读时序则是由主机发起一个至少1μs的低脉冲，然后释放总线，并在15μs内采样数据线电平。
这些时序参数如果直接用延时函数去磨，会受到主频和编译器优化影响。我的做法是：把GPIO操作和几个关键的耗时循环写死，用NOP指令凑时间，而不依赖通用的delay函数。下面是个简化版例子。
#define OW_PIN LATCbits.LATC0 // 单总线引脚 #define OW_DIR TRISCbits.TRISC0 // 方向寄存器 // 复位脉冲，返回1表示存在应答 unsigned char ow_reset(void) { unsigned char presence; OW_DIR = 0; // 输出模式 OW_PIN = 0; __delay_us(480); // 至少480us的低电平 OW_DIR = 1; // 释放总线，转输入 __delay_us(70); presence = OW_PIN; // 采样应答 __delay_us(410); return presence == 0 ? 1 : 0; // 读到低表示有器件应答 }这颗单片机的内部振荡器频率我用的是16MHz，__delay_us能保证微秒级延时。不过需要特别注意，如果后面改主频，所有时序函数都要跟着重新调，不然全是隐蔽的时序问题。
3.2 读取PJ85718DM的温度数据与CRC校验
每颗PJ85718DM会返回9字节的暂存器数据，前两个字节是温度值，第9个字节是CRC校验。温度数据的格式比较直接：低字节在前，高字节在后，分辨率可配置，默认12位时每个LSB对应0.0625°C。温度为正数时直接乘0.0625，负数时需要把两个字节拼接成16位有符号数再做计算。
我在读取时一定会做CRC校验，这是单总线上多设备通信可靠的保障。单总线CRC是8位多项式0x31，用一个查找表或者在线异或移位生成都行。如果CRC错误，这帧数据就扔掉，不要拿来算温度，宁可下一轮再读。以下是读取并校验的核心片段。
#define PJ_READ_SCRATCHPAD 0xBE #define PJ_SKIP_ROM 0xCC unsigned char ow_read_byte(void) { unsigned char val = 0; for (int i = 0; i < 8; i++) { val >>= 1; if (ow_read_bit()) val |= 0x80; } return val; } // 假设经过复位和跳过ROM后，调用此函数读9字节 unsigned char temp_crc = 0; temp_crc = ow_crc8(scratchpad, 8); // 前8个字节算CRC if (temp_crc == scratchpad[8]) { int16_t raw = (scratchpad[1] << 8) | scratchpad[0]; float temperature = raw * 0.0625f; }这里有个细节：在连续读取多个传感器时，每读完一个传感器后一定再发一次复位，否则下一个传感器可能不响应。而且传感器温度转换启动后，需要等待转换完成。默认12位转换时间最长是750ms，如果温度刷新频率要求高，可以把分辨率设为9位，转换时间降到93.75ms，但精度只有0.5°C，这就看需求取舍了。
3.3 滤波与防跳变：中位值平均才是硬道理
HVAC现场的温度信号其实“毛刺”很多，特别是风机启动瞬间，传感器线上的干扰会被当成有效信号读进来。我试过直接读原始值来显示，结果温度在1秒内能跳2°C左右，虽然实际环境温度根本没变那么快。
我的做法是在温度数据进入业务逻辑前做一次“中位值平均滤波”。具体说，就是连续读取5次温度，去掉最大值和最小值，然后对中间3个值取平均。这样既过滤掉了单个大毛刺，又不会像简单滑动平均那样把突然的真实变化也磨平。代码如下：
float avg_temp(float arr[], int n) { float sum = 0; float min = arr[0], max = arr[0]; for (int i = 0; i < n; i++) { if (arr[i] < min) min = arr[i]; if (arr[i] > max) max = arr[i]; sum += arr[i]; } return (sum - min - max) / (n - 2); }实测下来，5次采样中位值平均之后，显示温度稳定在±0.1°C以内波动，完全满足HVAC控制要求。如果现场干扰更强，可以把连续测量次数加到7次，代价是刷新周期变长，设置传感器12位分辨率时要考虑这个时间开销。
4. 远程通信：本地与远程数据汇总上传
4.1 远程通信方案选型：RS485/Modbus还是LoRa？
做完传感器采集之后，数据放在单片机里还不够，HVAC应用必然要接入上位机或者楼宇自控系统。远程通信方案我一般分两种场景来选。
第一种是集中式机房或者楼宇内，现场传感器分散但总体距离不超过1000米，这种用RS485总线加Modbus RTU协议最合适。PIC18F66K40的UART模块接一个隔离的RS485收发器，成本低，实时性好，工业现场积压了大量现成的组态软件都支持Modbus。
第二种是园区级室外分布点，比如给好几栋楼的冷却塔补水管测温度，中间隔着马路，拉485线代价太高。这种我倾向于用LoRa无线模块做点对点传输，或者用4G DTU把温度数据上传云平台。但要注意无线方案的实时性和供电问题，LoRa虽然省电，但数据碰撞和蹭网关的机制需要单独设计。
这个项目里我先做的是RS485方案，因为楼宇自控机房里面已经有现成的Modbus管理平台，直接对接即可少写一套上位机协议。
4.2 Modbus RTU从机实现要点
PIC18F66K40做Modbus RTU从机，核心是UART中断接收、CRC16校验和地址匹配。波特率我用9600bps，8数据位，无校验，1停止位。这个配置在绝大多数组态软件里是默认选项，兼容性最好。
CRC16的算法用的是多项式0xA001，每次收发一帧数据都要计算。这个计算本身不复杂，但如果在主循环里同步做，很容易阻塞其他任务。我的做法是：UART接收完一帧后置一个标志位，主循环检测到标志后再花几百微秒处理CRC和寄存器读写。以下是CRC16的一个常见实现。
unsigned int modbus_crc16(unsigned char *buffer, unsigned int len) { unsigned int crc = 0xFFFF; for (unsigned int i = 0; i < len; i++) { crc ^= buffer[i]; for (int bit = 0; bit < 8; bit++) { if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; } else { crc >>= 1; } } } return crc; }从机寄存器表的规划也要提前想好。我习惯把每路温度数据映射成一个保持寄存器，单位是0.1°C。比如寄存器地址0x0000存放1号传感器温度，0x0001存放2号传感器温度，当传感器故障时写入0xFFFF。上位机读取到一个不可能出现在正常范围内的值，就能立即判断传感器状态，而不是纠结于“温度怎么突然变成了255°C”。
4.3 远程数据校验与掉线判断
Modbus协议本身有CRC校验，可以保证传输层的完整性，但应用层的超时判断、重发机制却必须自己实现。我的从机程序里，每次收到上位机请求都会先判断地址是否匹配，不匹配则直接丢弃；匹配则等整帧接收完成后再做CRC校验。这样能避免把其他从机设备的数据误解析。
同时，我还在数据寄存器里专门做了一个“心跳寄存器”，上位机每隔一段时间去读取。正常时这个寄存器的值每秒钟递增，上位机如果连续5秒没有读到递增，说明通信链路断了，界面直接显示“通信故障”而不是显示一个假温度。这个思路对提高系统的可维护性帮助很大。
5. 常见问题排查与调试心得实录
5.1 传感器读不到或者全部读到85℃
这是单总线应用里最经典的问题。PJ85718DM上电后暂存器温度寄存器默认值就是0x0550，换算出来恰好是85℃。所以如果程序“成功”读到多个85℃的温度值，说明通信链路是通的，但传感器根本没有执行温度转换，或者主机发的启动转换命令没有被正确执行。
我的排查顺序是：先用示波器看单总线复位和应答波形，确认传感器是否存在；再量一下VDD引脚电压，看是否满足手册要求；最后检查上拉电阻是否焊错或者没焊。遇到过好几次是传感器插反了，能读到全0xFF，但永远不返回正确数据。换成带防反接的三线插头后这个问题就没再犯。
5.2 实际温度正常但显示数值跳变
如果滤波做了还是跳变，大概率是硬件干扰而不是算法问题。我曾经在一个项目里把传感器线从逆变器的散热风扇旁边穿过，结果温度数据每秒钟都能看到规律性毛刺。后来把传感器线换成了带屏蔽层的双绞线，屏蔽层在控制器一端单点接地，毛刺立刻消失了。记住，屏蔽层千万不能在传感器端也接地，否则会形成地环路，反而引入更大的干扰。
5.3 Modbus通信偶尔超时或者数据错乱
这个问题要从三个方面查：一是RS485总线的终端电阻，一般要求总线两端各接一个120Ω匹配电阻。如果监控点位分散、接线不规范，总线长度超过几百米后没接终端电阻就会产生反射，导致波形畸变。我在项目现场用万用表量过A、B端之间的静态电阻，正常应该在60Ω左右，如果量到120Ω，说明只有一端接了电阻，或者根本没接。二是波特率误差，内部振荡器跑9600bps问题不大，但如果上位机用的是独立时钟源，两边偏差过大会造成偶发性的帧错误。三是收发器方向控制引脚切换太慢，我遇到过发送完成后立刻把接收使能打开，但收发器芯片还在驱动总线，导致自己发的一帧数据被自己误接收，解决方法是TX完成后等一两毫秒再切换方向。
5.4 现场实测记录与稳定性数据
在实验室环境里，我用这套系统挂了8颗PJ85718DM传感器，分成两组，一组走10米线，一组走30米线。连续跑48小时，温度读取成功率在99.8%以上。剩余0.2%的失败主要集中在电磁阀动作的瞬间，数据通过CRC校验被滤掉了，没有对控温逻辑造成任何影响。作为对比，如果不上滤波、不校验，读取失败率其实不到1%，但对于长期运行的控制设备来说，这1%可能就是一次误触发。
6. 最后再分享一个调试技巧
单总线传感器在更换device之后，序列号会变，所以如果用“按序列号匹配地址”的方式读取固定点位，那么每一颗传感器在出厂安装时都要把ID烧录到EEPROM里。这个流程很繁琐，而且换传感器还要重新烧录。
我后来改成“跳过ROM+遍历读取”的策略：每次上电后先广播一次“搜索ROM”命令，把所有在线传感器的序列号读出来，建立一张动态映射表；再根据物理安装位置，通过一个本地按键或者Modbus寄存器来绑定“1号温度点对应哪个序列号”。这样换一颗传感器后，只需要重新绑定一次，不用动代码。这个小技巧在实际运维中非常省心。
整个项目做下来，我最大的体会是：PJ85718DM与PIC18F66K40这套组合单看某一个点都不算最顶尖，但组合在一起却是一个难得的低功耗、低成本、多通道且通信扩展性好的方案。尤其是单总线传感器本身的物理特性，天然就适合HVAC这种分布测温、现场环境复杂的场景。如果你正在做类似的嵌入式温度采集系统，希望这份记录能帮你少踩几个坑。
