企业官网建设流程全解析

做暖通控制器这几年，我发现自己被客户问得最多的不是"温度准不准"，而是"为什么控制器上读的温和风管远端测点对不上"。这个项目里我索性把问题拆成两半处理：控制器板级温度交给 PIC18LF45K80 的内部温度指示器，机组各处和房间里的温度统一用单总线数字传感器 PJ85718DM 分点挂测。主控选这颗 MCU，主要是看中它在低电压工作状态下还带 12 位 ADC 和 ECAN 模块，既能读本地温度，又能通过单总线把远程温度收回来，再通过 CAN 把数据交给上层。这套方案没什么高深技术，但对嵌入式和 HVAC 领域的开发者很有参考价值，尤其是想用最少硬件成本实现"本地+远程多点测温"的朋友，可以照着这套思路直接搭。

1. 为什么要用这两颗料：从"远近都要测温"这个需求说起

1.1 一片K80能同时干三件事：采集、控制、通信

PIC18LF45K80 这颗片子拿到手的第一感觉是"什么都有点但都不算夸张"：1.8V 到 3.6V 的低压工作范围，32KB Flash、3.6KB RAM、还有 1KB 数据 EEPROM，12 位 ADC 够做模拟量采集，ECAN 模块直接支持 CAN 2.0B。对我来说最关键的其实是 CAN 和 EEPROM 这两样。

HVAC 现场和实验室完全不一样。一套空调机组分布在机房、风管、楼层末端，控制器和控制器之间动辄几十米上百米。用 RS485 当然也能组网，但相比之下 CAN 的差分信号抗干扰能力、多主机仲裁机制、报文优先级设计更适合这种分散场景。K80 系列自带 ECAN 模块，意味着我不需要额外挂一颗 CAN 控制器，只需要在外面配一颗收发器芯片，成本和 PCB 面积都省下来了。

EEPROM 的价值在系统调试时体现得最明显。单总线温度传感器每个都有唯一的 64 位 ROM 码，这个码要在现场安装后逐一扫描出来。如果每次上电都重新扫描，冷启动时间会拖得很长，而且现场传感器突然掉一个，整个扫描过程可能卡死。把 ROM 码固化到 EEPROM 里，上电直接点名读取，系统行为完全可控。这些需求和嵌入式系统常见的"采集-控制-通信"三段式结构刚好对上了，一片 K80 全包。

1.2 PJ85718DM的定位是"数字温度传感器"而不是热敏电阻

以前做测温，很多人第一反应是 NTC 热敏电阻加 ADC。这方案便宜，但问题在调试阶段全暴露出来：每个电阻的 B 值有离散性，长线缆带来的压降和干扰直接影响 ADC 采样结果，而且不同厂家的 NTC 查表曲线还不一样，软件里得维护一堆参数。

PJ85718DM 这类单总线数字传感器把麻烦挪到了芯片内部。它自己完成温度到数字量的转换，通过一根 DQ 数据线把结果发给控制器，原理上等于"一根线传数据、芯片内部做测量"。这类器件几乎都兼容市面上最常见的 18B20 类命令生态，指令集、时序、寄存器布局都差不多：复位、存在脉冲、写入命令、读取暂存器、CRC 校验。从软件角度来说，这意味着网上大量成熟代码可以直接移植，调试工具也现成。

实际工程中我更看重的是它的多点接入能力。每个传感器烧录了唯一的 ROM 编号，所有传感器可以并联挂在同一根数据线上，控制器用 ROM 匹配命令点名读取，互不干扰。对于一个空气处理机组需要测回风、送风、盘管进出水、室外温度的场景，一根两芯线就能串完，这省下来的线材、穿管和人工成本在工地上是非常可观的。

1.3 本地温度和远程温度在我这里的定义

这个标题里的"本地"和"远程"，我在项目里是这么界定的：本地温度指控制器电路板所在环境的温度，包括 MCU 自身结温和机柜内空气温度，它反映的是设备自身健康状况；远程温度指被控对象和空间里的温度，比如风管、房间、水管的温度，它反映的是系统运行状态。这两类数据用途完全不同：远程温度参与温控闭环，本地温度则参与设备保护和散热控制。

这步定义非常关键，因为后续所有硬件布局、固件逻辑都是围绕这个分工展开的。如果一开始不把"哪路温度归保护、哪路归控制"说清楚，写代码时很快就会乱。

2. 系统怎么分工：本地结温、远程测点与CAN节点网

2.1 内部温度指示器：不花钱的板级保护传感器

PIC18 K80 系列有内部温度指示器，原理是输出一个随芯片结温线性变化的电压，接到内部 ADC 通道上。配置流程不算复杂：使能温度指示器模块，选择 ADC 参考电压，然后把对应的内部通道采样转换。得到 ADC 码之后，按照数据手册给出的电压-温度斜率换算成摄氏度。

这里要提醒一下：内部温度指示器的绝对精度并不高，芯片不同批次、不同工作电压都会让偏移量有差异。我在项目里从来不拿它当精密温度计用，而是做三件事：

• 检测机柜是否过热，比如结温超过 85℃ 就强制提高散热风扇转速；
• 和板载的 PJ85718DM 做交叉比对，如果两者偏差超过 20℃，说明传感器导热路径有问题，触发维护报警；
• 作为 MCU 工作环境的长期记录，判断设备是否长期在高温降额状态下运行。

如果不想依赖内部温度指示器的精度，也可以直接在 PCB 上焊一颗 PJ85718DM 当"板级本地传感器"，把传感器贴在容易发热的功率器件附近。我实际做混合方案：内部温度指示器负责快速结温保护，板载传感器负责环境温度记录，两者互补。

2.2 一根双绞线上的单总线多点布局

远程温度部分，我把每台机组的所有测点接头并联到同一根数据线上。单总线协议的结构是：主机通过时序窗口逐位读写，传感器在收到转换命令后自行完成测量，结果放在暂存器里等主机来取。每个传感器的 ROM 码保证了总线上的每一个器件都可以被独立寻址。

现场一套小型空气处理机组我通常挂 4 到 8 个测点：回风温度、送风温度、盘管进水温度、盘管回水温度，再加上室外环境温度。这些测点的共同点是位置分散、线缆走线路径各不相同，但都通过一条总线汇总到控制器。安装调试时先逐个单独连接传感器，把每个传感器的 ROM 码读出来并记录；正式运行时控制器对已知 ROM 码逐一匹配读取，不加搜索总线逻辑，可靠性和速度都有了保障。

单总线还有一个容易被忽略的工程点：总线分支不应太复杂。实测下来，多个传感器在一条主干上"串糖葫芦"式连接，比每个传感器分叉一根线到总线要稳定。分支太长会造成信号反射，波形上就是边沿变缓、振铃严重，后面读回来就是乱码。后面专门有一节讲这个坑。

2.3 用ECAN模块把各节点的温度汇到中央

远程温度在单机上读出来只是第一步，HVAC 场景里还要把不同机组的温度数据汇到中央。我在每台机组的控制器上配了 CAN 收发器，ECAN 模块经过初始化之后就按固定周期上报数据。

报文规划很直白：每个节点有一个基础标识符，报文数据段的前两个字节是节点编号和测点编号，后面是温度原始值。比如中央控制器收到某个报文，先解析节点号，再解析测点号，就知道这路温度来自哪台机组的哪个位置。总线速率我一般配置为 500kbps，在楼内几百米的布线范围内足够使用。

一开始做这个方案时有人问我：为什么不用 RS485 把所有温度传感器直接拉到中央控制器？原因很简单：温度传感器的单总线协议不适合跨越长距离，而且把每个房间的模拟或数字量测点全拉回机房，线缆数量和施工难度都不现实。让分布在现场的控制器就近采集温度、再用 CAN 往中央汇总，才是符合实际施工架构的做法。

3. 硬件决定与现场布线：上拉电阻、供电方式和线缆防护

3.1 上拉电阻的取值不是玄学，是边沿时间问题

单总线空闲时靠一个上拉电阻把数据线拉到高电平，传感器和主机通过拉低数据线来发送信号。这个上拉电阻的取值直接决定了数据线的上升沿时间。阻值越大，上升沿越慢；阻值越小，传感器拉低时需要承载的灌电流越大。

最常用的起步值是 4.7kΩ。如果你只是在一个实验板上测一堆传感器，线缆很短，4.7kΩ 完全够用。当现场线缆变长、传感器数量增多，总线寄生电容也跟着涨，再用 4.7kΩ 就会发现上升沿明显变缓，严重时传感器传回来的 1 也会被误读成 0。此时可以把上拉电阻降到 2.2kΩ 甚至 1kΩ。但不要无脑降，低于 1kΩ 会让传感器在拉低总线时承受过大的灌电流，影响输出低电平的可靠性。

我的做法是：PCB 上预留一个 0402 电阻位，先按 4.7kΩ 装，现场实测波形后再根据线长和节点数调整。调试时判断标准很简单，用示波器看 DQ 引脚的上升沿，如果从低到高的跃变时间超过 1µs，就该把阻值降一档。

3.2 为什么不建议用寄生供电挂远程测点

单总线传感器支持两种供电方式：外部供电和寄生供电。寄生供电模式下，传感器在总线为高电平时"偷电"给内部电容充电，转换期间靠电容储能维持工作，这样远端传感器只需要数据线和地线两根线，省一根电源线。

但 HVAC 现场恰恰是最不适合寄生供电的地方。电动阀动作、接触器吸合、变频器启停，这些都会在供电线上制造剧烈的电压跌落和尖峰干扰。寄生供电模式下传感器对供电电压跌落非常敏感，一旦在温度转换过程中电容储能不足，芯片直接复位，数据要么不响应，要么返回一个莫名其妙的温度值。

所以我这里明确推荐三线制：VDD、DQ、GND。传感器电源由控制器统一供给，D 线单独走信号。三线制多跑一根线，但换来的是温度转换过程的确定性，在工地上这比省一根线值太多。屏蔽层要单端接地，避免形成地环路。

3.3 线缆、屏蔽与保护器件的安装经验

温度传感器的信号线虽然不像模拟量那样对微弱干扰敏感，但长距离传输时依然要走正经的布线规范。我的经验是：传感器线用双绞屏蔽线，和强电电缆分开穿管，至少保持 30cm 间距；屏蔽层在控制器端单点接地；接入控制器的 DQ 线上加一个 100Ω 左右的串联电阻做阻尼，再加 TVS 管防止静电和浪涌。

还有一个细节容易被忽略：不要随意把传感器线缆当作"反正只有一根线所以无所谓"来布置。实测中我遇到过因为线缆与风机动力线平行走了十几米，导致每次风机高速档启动时温度读数跳变的情况。把线缆移开、加屏蔽、调上拉电阻，三个措施一起上之后，问题彻底消失。硬件层面的余量要给足，后面固件才能省心。

4. 固件核心：在PIC上把单总线时序和温度换算写扎实

4.1 时序参数先背下来再动手写代码

单总线协议严格的点都在时序上。PIC18LF45K80 内部振荡器经过 PLL 可以跑到 64MHz，指令周期是 62.5ns，这意味着每条指令的执行时间都在几十纳秒量级，完全有能力卡出单总线的微秒级时序，但对延时实现的精确性要求很高。

先从复位时序说起。主机要把数据线拉低至少 480µs，然后释放并等待传感器的存在脉冲。存在脉冲是传感器在主机释放总线后 15µs 到 60µs 之间主动拉低 60µs 到 240µs。如果主机这边延时不准，要么错过存在脉冲，要么把不存在误判为存在。

读写时隙的规则更细致：写 1 的时隙是主机拉低 1µs 到 15µs 之后释放，整个时隙持续 60µs 以上；写 0 的时隙是主机把低电平保持 60µs 以上；读时隙是主机拉低 1µs 到 15µs 后释放，然后在时隙开始后的约 15µs 采样数据线。采样点太早，传感器还没把线拉低，读到的是 1；采样点太晚，可能进入下一个时隙。

我在 XC8 环境下的实现方式是：用宏定义_XTAL_FREQ 64000000UL，然后直接用__delay_us()做微秒级延时。写时序和读时序的每个函数都临时关闭全局中断，防止 CAN 中断或定时器中断插进来把时序拉长。单总线设备对时序漂移的容忍度只有几微秒，关中断是最简单的保命手段。

4.2 单点采集与多点点名读取的完整流程

单点采集流程是理解协议的基础，逻辑上就五步：

1. 复位总线，检测存在脉冲；
2. 发送跳过 ROM 命令（0xCC）；
3. 发送温度转换命令（0x44），等待转换完成；
4. 再次复位，发送跳过 ROM 命令；
5. 发送读取暂存器命令（0xBE），连续读出 9 个字节。

读出的前两个字节分别是温度值的低字节和高字节，第 3、4 字节是报警上下限，第 5 字节是配置寄存器，最后一个是 CRC 校验字节。12 位分辨率下，把两个字节拼成一个有符号 16 位整数，除以 16 就是实际温度。比如读到 0x0550，拼起来是 1360，除以 16 就是 85.0℃。

多点场景把"跳过 ROM"换成"匹配 ROM"：先复位，再发 0x55 匹配命令，接着把目标传感器的 8 字节 ROM 码逐个发出，然后才发转换或读取命令。这样总线虽然挂了多个传感器，但每次只和指定 ID 对话。核心代码片段大概是这个风格：

// 以12位分辨率发起温度转换并等待完成 uint8_t ds_start_conversion(uint8_t *rom) { if (!ow_reset()) return 0; // 总线无响应 if (rom) { ow_write_byte(0x55); // MATCH ROM for (uint8_t i = 0; i < 8; i++) ow_write_byte(rom[i]); } else { ow_write_byte(0xCC); // SKIP ROM } ow_write_byte(0x44); // CONVERT T __delay_ms(750); // 12位最大转换时间 return 1; } // 读取一次温度，带回CRC校验 int16_t ds_read_temperature(uint8_t *rom) { if (!ow_reset()) return 0x8000; if (rom) { ow_write_byte(0x55); for (uint8_t i = 0; i < 8; i++) ow_write_byte(rom[i]); } else { ow_write_byte(0xCC); } ow_write_byte(0xBE); // READ SCRATCHPAD uint8_t data[9]; for (uint8_t i = 0; i < 9; i++) data[i] = ow_read_byte(); if (ow_crc8(data, 8) != data[8]) // 校验失败返回异常 return 0x8000; return (int16_t)((data[1] << 8) | data[0]); }

ow_crc8是单总线标准的 8 位 CRC 算法，多项式就是 0x8C（反射形式）。CRC 校验这一行绝对不能省：现场环境下总线偶尔受干扰是很正常的，如果读回来的 9 个字节里出现了错误，CRC 能拦住绝大多数情况。

4.3 EEPROM里存什么：ROM码、校准偏移与阈值

PIC18LF45K80 有 1KB 数据 EEPROM，我把它当成这个项目的"现场数据库"。规划出一个固定区域，地址段划分成节点参数区、传感器列表区、校准数据和阈值区。调试时进行一次总线扫描，把发现的所有传感器 ROM 码按顺序写入，同时为每个测点预留一个带符号的校准偏移字节。

校准这件事在 HVAC 里很实际：不同传感器芯片之间存在系统偏差，有的偏正 0.2℃，有的偏负 0.3℃。现场校准时，把传感器和标准温度表放在同一环境，记录差值写入 EEPROM。运行时读温度时自动加上这个偏移，几路测点的读数就能保持一致性。这个"一致性"在客户那里往往比绝对精度更重要。

EEPROM 的写入要小心：擦写寿命有限，写入一个字节还要约 4ms 的等待。我的原则是只在调试模式下写 EEPROM，正常运行固件一律只读。上电时把这块区域整体拷贝到 RAM，之后所有读写都操作 RAM 镜像。

我用的 EEPROM 地址规划大致如下表：

这套设计让设备在现场"换人维护"也能快速上手：调试助手只要进入校模式，自动扫描、自动建档、自动写入，普通电工也能完成传感器更换后的系统重新识别。

5. 实测中的故障排查：85℃假读、掉线与毛刺的完整处理过程

5.1 85℃假读：一半是时序问题，一半是干扰问题

第一次在机柜里跑整套系统时，我遇到一个很典型的现象：某些测点偶尔返回 85.0℃，而且看起来很规律，总是在压缩机继电器吸合的瞬间出现。查下来原因有两个层面。

第一，85.0℃ 这个值对应原始数据 0x0550，恰恰是传感器上电复位后暂存器里的默认温度。传感器如果在上一次转换还没完成时被干扰复位，主机再读取暂存器，读到的就会是这个默认值。所以 85.0℃ 是传感器"我又重新上电了"的标志，而不是真实温度。

第二，为什么偏偏这时复位？示波器抓 DQ 波形发现，继电器吸合瞬间，总线高电平上叠加了一个明显的跌落尖峰。传感器的工作电压被瞬间拉低，内部逻辑就复位了。虽然我用了三线制供电，但电源线是从 24V 交流控制箱里引出来的，整流滤波余量不足，负载突变时电压跌得太狠。

排查的过程很长，但思路值得分享：先复现问题，再在关键节点量波形，最后用排除法确认干扰源。最后我做了三件事：给传感器供电加一个小容量储能电容、把信号线改成屏蔽双绞、上拉电阻从 4.7k 降到 2.2k。三管齐下之后，85℃ 假读基本消失。

固件层面也要兜底。我的读温度函数里做了三道检查：CRC 必须通过；温度必须在 -55℃ 到 125℃ 的合理范围内；连续三帧读数要一致才接受。三道检查同时做完，误读率降到了可以忽略的程度。

5.2 分辨率与转换时间的取舍

PJ85718DM 这类器件支持 9 到 12 位可编程分辨率。分辨率越高，转换时间越长：9 位时约 94ms，10 位约 188ms，11 位约 375ms，12 位约 750ms。HVAC 温控系统对响应速度要求其实不高，温度本身的变化就是分钟级的，所以 12 位 750ms 的等待时间并不奢侈。

但如果你有 8 个测点，每个测点都等 750ms 再读下一个，一轮巡检下来要 6 秒多。这个轮询周期对显示和报警还算可以，对控制闭环就显得迟钝了。我的处理方案是：全部传感器配置为 12 位分辨率，但巡检时采用"流水线"方式——先给所有传感器依次发转换命令，等到最后一颗转换完成后，再依次读取所有传感器的暂存器。这样总时间从 N 颗传感器乘以 750ms 变成固定的 750ms 加读取时间，8 点一轮巡检控制在 1 秒内。

配置分辨率要通过写暂存器命令，把配置寄存器写入对应的分辨率位，然后把暂存器复制到传感器的 EEPROM 中保存。这个细节容易漏：只是改了暂存器值，断电后又会恢复默认。配套的复制命令一定要发，否则现场掉电重启后所有传感器又退回 12 位默认值，等你重新配置。

5.3 滤波策略：先去掉毛刺再谈平滑

温度信号本身是慢变量，但单总线上偶尔的干扰会产生一个明显跳变，比如从 23.5℃ 突然跳到 28.1℃。这种毛刺如果用滑动平均去处理，会被平均掉一部分；但如果连续两三次都采到同一个异常值，滑动平均也可能被拉偏。

我的策略是分两步。第一步做中值滤波，每轮巡检对同一测点连采 3 帧，取中间值作为有效值。这一步的目的就是干掉单点毛刺。第二步对有效值做一阶低通滤波，比如filtered = filtered * 0.8 + new_value * 0.2，用来压制随机噪声。两层滤波之后，显示和控制用的温度曲线都非常干净。

实测中有个反直觉的经验：滤波不要做得太狠。有一次我把低通系数调成 0.95，温度响应变得非常迟钝，回风温度从 25℃ 降到 22℃ 的过程在界面上拖了一分多钟才走完，操作员以为传感器坏了。后来我把系数分成两套：控制用稍微灵敏感应一点的参数，显示和趋势用重滤波参数，各取所需。

int16_t temp_filter(int16_t raw) { static int16_t history[3]; history[2] = history[1]; history[1] = history[0]; history[0] = raw; int16_t median = history[1]; // 三值取中 if (history[0] > history[1]) { if (history[1] > history[2]) median = history[1]; else if (history[0] > history[2]) median = history[2]; else median = history[0]; } else { if (history[0] > history[2]) median = history[0]; else if (history[1] > history[2]) median = history[2]; else median = history[1]; } return median; }

6. 从单机到HVAC组网：温度数据怎么真正变成控制动作

6.1 一套空气处理机组的测温点位设计

举一个很常见的落地场景：一台空气处理机组要给一个楼层送风，需要监控回风、送风、盘管进出水和室外温度。五个测点各挂一颗 PJ85718DM，都并联在控制器的一条单总线上。控制器放在机组电控箱内，传感器分别装在风管、水管和室外防雨盒里。

这五个测点各管一件事，缺哪一个都会让控制逻辑少一只眼睛。特别是盘管进出水温度差，是判断换热器是否结垢、水流量是否正常的重要依据。只测回风和送风、不测水管温度，系统能运行，但出了问题往往只能用猜的。

6.2 温度参与控制：阈值、滞环和联动

温度数据的最终价值在于控制动作。我在固件里没有用复杂的 PID 算法，而是先用阈值加滞环把安全逻辑做扎实，控制回路再往上层迭代。

送风温度保护是第一步：送风温度低于 10℃ 时，关闭风机前电加热和加湿器，防止冷风直接吹入房间；高于 45℃ 时报警并限制风机转速。这里必须用滞环，比如回温到 12℃ 才重新允许加热，否则风机和阀门会在临界点反复通断，几个小时就能把接触器磨坏。

盘管回水温度还有一个独立功能是防冻保护。冬季机组停机时，如果回水温度跌到 5℃ 以下，即使机组处于停机状态也要强制打开水泵和电动阀，防止盘管冻裂。这个逻辑必须在控制器上独立运行，不依赖中央管理系统，因为通讯故障时中央帮不上忙。

本地结温也参与了联动：夏天机柜内温度超过 60℃ 时，控制器主动把散热风扇开到最高档，同时降低 CAN 报文的发送频率，减少自身发热，这就是前面说的内部温度指示器真正的应用场景。各项控制参数我都以表驱动的方式放在 EEPROM 区域，现场改阈值不需要重新编译固件。

6.3 数据后续还能怎么用：趋势与预警

温度数据如果只是用来做实时调节，其实浪费了一大半价值。我在这个项目里把各路温度和温差的历史值保存到外部存储，后台定时拉取形成趋势曲线。两周之后再看曲线，规律非常明显：送风回风温差随着时间缓慢变大，基本可以断定过滤网在积尘；盘管进出水温差变小，要么是水流量下降，要么是换热效率变差。

这类趋势判断不需要高级算法，把每天同时段的数据对比就能给出预警。比如过滤网报警的判据是：相同室外工况下，送风温差比过滤器初始状态下降超过 30%。这个逻辑放在中央控制器里，运行一个月后已经成功提前预警了两台机组的风机超温风险。

再往远了说，所有测点的温度数据通过 CAN 上报后，统一格式接入楼宇管理后台，就能做能耗分析、设备轮值优化和故障诊断。温度监测的价值不在于"测出来"，而在于"数据怎么参与判断"。把判断逻辑设计好，这套基于 PJ85718DM 和 PIC18LF45K80 的系统才算是真正用满了。

我在实际项目里最大的体会是：测温度本身不难，难的是设计"哪些读数可以信、哪些读数要丢弃"的规则。CRC、范围检查、连续帧确认、中值滤波，这几层兜底一个都不能省。最后分享一个小技巧：给控制器留一个调试串口，上电后逐帧打印每个测点的原始暂存器数据和 CRC 校验结果，现场排查问题时能省掉大量猜疑时间——你永远不知道下一次出现奇怪温度的是哪根线上的哪个传感器。