企业官网建设流程全解析

在嵌入式温度采集和HVAC（暖通空调）控制里，测温这件事看起来不起眼，真正要保证在现场稳定跑一年不出毛病，方案选型、总线和电源细节都得较真。最近我在一个温控项目中，用 PJ85718DM 单总线数字温度传感器搭配 PIC18F86J10 单片机，搭了一套同时覆盖本地与远程温度监测的系统。本地温度负责就地显示、启停逻辑和报警，远程温度则通过 RS-485 总线汇总到监控室，让运维人员不用跑到现场就能看到所有温度点。这个方案特别适合壁挂炉、机房空调、新风机组这类场景，如果你正在做嵌入式温控、HVAC 控制器，或者需要把分散的温度点统一管理起来，这篇东西应该能帮你少走不少弯路。

项目做完之后我复盘过，系统本身不复杂，真正花时间的是兼容性、抗干扰和远程通信协议这些“看不见”的部分。下面我把整个项目的硬件选型、电路设计、固件实现和现场问题记录完整拆一遍，尽量把每一步背后的理由也说清楚。

1. 思路拆解：本地与远程温度监测的架构取舍

1.1 为什么选单总线数字温度传感器

HVAC 设备的测温点分布很散，回风、送风、盘管进出口、室外补风，每个位置都想要一个温度点。如果用传统 NTC 热敏电阻加 ADC 采集，一个通道接一路，5 个点就得布 5 根线到主控板，标定还麻烦。PJ85718DM 这类单总线数字温度传感器不一样，它的数据线可以挂多个传感器，每个传感器出厂带有唯一序列号，MCU 只需要一根 GPIO 就能轮询读取一整串测温点。

PJ85718DM 的测温范围大约是 -55℃到 +125℃，默认 12 位分辨率下能分辨 0.0625℃ 的变化，典型精度在 ±0.5℃ 左右，足够暖通控制用。数据用 9 字节分组读出来，最后一位是 CRC 校验，这样线缆受干扰导致的数据错乱能在软件层被发现，而不是直接采到一个离谱的温度去触发压缩机启停。

这个特性放到 HVAC 现场尤其重要。风机、压缩机一启停，接触器火花、变频器输出谐波都会往信号线上耦合。模拟温度传感器遇到这种干扰，ADC 采样结果会瞬间跳变，你很难区分是真实温度变化还是干扰。数字传感器至少能通过 CRC 把大部分错误帧丢掉，宁可重读一次也不拿脏数据做控制。

1.2 PIC18F86J10 的选型逻辑

主控选择 PIC18F86J10，首先是因为项目本身就是基于这一系列 8 位 MCU 的产品线，代码和开发工具链都能复用。PIC18 架构在处理单总线时序、Modbus RTU 这类中低速协议时，性能完全够用，而且它的外设配置灵活，多个 EUSART 可以一个接上位机通信、一个接远程采集板，SPI/I2C 接口也能留给外部存储或者显示模块。

这个型号的封装引脚数比较多，I/O 分配起来很舒服。项目里每个单总线通道独占一个 GPIO，后续扩展也不至于顶上、功能相冲突。另外一个隐性优势是它支持在线调试，配合调试器直接在目标板上看变量，排查单总线时序问题的时候帮助非常大。调试体验这东西，开发周期越紧越能感受到差距。

我见过不少同行在这种项目上直接上 Cortex-M，当然也行，但从产品维护和物料统一的角度看，8 位机把逻辑做清晰了，成本更低、出问题更容易定位。换 MCU 不是拍脑袋的事，要评估外设迁移、底层驱动重写、老产品代码兼容等一系列工作量。这个项目最终沿用 PIC18 系列，本质是综合考虑后的选择。

1.3 本地与远程的架构差异

我把整系统的测温需求拆成两块。本地温度是控制器自己直接读、直接用的，比如室内回风温度用于启停风机盘管，盘管出水温度用于防冻保护，这类数据实时性要求高，控制在同一个 MCU 内闭环，中间不经过任何转发。远程温度则是为了集中监控，把分布在设备间、机房里的温度点汇聚到一块，再通过 RS-485 总线上传到触摸屏或监控主机。

这里说句经验之谈：远程监测不要什么都往无线走。HVAC 现场里变频器、电机、接触器都是强干扰源，2.4GHz 信号穿不透金属桥架和机柜，调试时麻烦不断。RS-485 在 1200 米内、32 个节点以内的场景非常成熟，两根双绞线搞定，屏蔽层接好地之后抗干扰能力很强。项目里远程链路全部走 RS-485，实测很稳，后来即使加了以太网网关，也是 485 先汇聚再转一次。

2. 硬件设计与接口电路要点

2.1 本地温度采集电路

PJ85718DM 常规接法是三线制：VCC、GND、DQ。DQ 是开漏输出，必须外接上拉电阻到电源。上拉电阻我用 4.7kΩ，配合普通 MCU GPIO 完全合适。这里有个容易犯的错：上拉电阻放在主控板靠近单片机的位置当然可以，但总线很长时，最好在总线末端再并一个 4.7kΩ 电阻。原因是线缆本身的分布电容会拖慢信号上升沿，末端补上拉能改善波形，尤其传感器距离超过 5 米后效果很明显。

每个传感器旁边我加了一个 0.1μF 陶瓷电容做去耦，VCC 和 GND 之间尽量就近放置。别小看这个电容，HVAC 设备启动瞬间母线电压会跌落，如果传感器供电直接取自继电器或者接触器的辅助电源，读数会时不时异常。电容能撑住几毫秒的跌落窗口，让传感器在电压恢复前不至于进入复位状态。

DQ 线上我还加了 TVS 管和 100Ω 左右的串联电阻。暖通现场经常因为接线不规范把强电碰到信号线上，TVS 能吸收一部分瞬态能量。虽然单总线传感器内部也有一定保护，但外部防护器件的成本远低于换传感器的返工成本。

2.2 远程温度采集与通信链路

远程测温点我分成了两种部署方式。一种是把传感器直接接到控制器总线的扩展通道上，适合距离二三十米内、点数不多的情况。另一种是做一个独立的采集板，采集板放现场，板上的传感器就近布置，采集板自己跑单总线协议，把处理后的温度通过 RS-485 发给主控或者上位机。第二种方式更工程化，因为单总线最怕的就是长线导致时序畸变，采集板放到传感器旁边，总线长度能压到 3 米以内，成功率大幅提升。

远程总线我统一用的是屏蔽双绞线，型号不点名，反正工业现场常见的 120Ω 特性阻抗线就行。RS-485 的总线首尾各接一个 120Ω 终端电阻，注意是“首尾各一个”，不是只在主站端接一个，否则长距离通信反射噪声会直接把帧打乱。屏蔽层在控制器电源地附近单点接地，不要让屏蔽层两端都有接地回路，不然共模干扰反而更严重。

2.3 供电与电磁兼容细节

供电这一块是教训最深的。最初的测试板把传感器电源直接接到了 24V AC 整流后的直流母线上，想着反正都是一个系统，没必要多一路供电。结果只要压缩机一吸合，温度读数就开始乱跳，有时甚至整条总线都找不到传感器。后来把传感器供电改成独立的 3.3V LDO 供电，LDO 输入来自主电源经过 π 型滤波之后，问题立刻消失。原因很简单：压缩机启动时母线电流突变，线路阻抗导致的电压尖峰全部灌进传感器电源里，单总线协议对电平非常敏感，电源脏了时序就崩。

PCB 布局上也要注意，DQ 信号线不能和继电器控制线、强电线在 PCB 上平行长距离走线。实在避不开，就在两层板之间加地平面隔离，或者用垂直布线。我在第二版改板时专门把温度总线从板边引出，远离功率继电器区域，干扰误码率下降了一个数量级。

3. 软件实现：单总线时序、CRC 与远程协议

3.1 单总线驱动时序

PJ85718DM 的时序和业界常见的单总线温度传感器兼容，核心操作有三个：复位脉冲、写时隙、读时隙。复位时序是主机拉低总线 480μs 以上，然后释放并拉高，传感器会在 60μs 到 240μs 内拉低总线作为存在应答。MCU 侧必须用微秒级延时，最好配合定时器实现，而不是简单地靠空循环延时，因为编译器优化级别一变，空循环的时间就变了。

写时序里，写 0 是拉低总线持续 60μs 以上，写 1 是拉低一小段时间（15μs 左右）后释放，让上拉电阻把总线拉高。读时序则是主机先拉低很短的时间，然后释放，在释放后的第 5μs 到第 10μs 之间采样电平。这几个时间窗口都有容差，但你的实现越靠中间值越稳。我在代码里统一用定时器延时函数，关闭中断保证时序不被串口中断打乱。

// PIC18 平台上简化版单总线延时与复位实现 void ow_delay_us(uint16_t us) { while (us--) { _Delay_Instructions(4); // 根据实际主频调整 } } uint8_t ow_reset(void) { uint8_t presence = 0; DQ_TRIS = 0; // 输出模式 DQ_LAT = 0; // 拉低总线 ow_delay_us(500); // 复位脉冲 DQ_LAT = 1; // 释放总线 ow_delay_us(50); DQ_TRIS = 1; // 切输入模式 ow_delay_us(80); // 等待存在应答窗口 if (DQ_PORT == 0) { presence = 1; } ow_delay_us(420); return presence; }

3.2 多点测温与 ROM 搜索

单总线上挂多个传感器，主机必须知道总线上都有谁。每个 PJ85718DM 出厂时烧录了 64 位序列号，最后一个字节是 CRC。主机通过 ROM 搜索算法逐位判断总线上的设备跳变，把号读出来，之后就可以直接对指定序列号发起温度转换和读取。

这步逻辑不复杂，但千万别试图省掉。我最初为了省代码，直接在初始化时“假设”只挂了一个传感器，后来远程采集板接到第二条总线上新增了传感器，固件却不认识新设备，排查了半天才发现是搜索逻辑没写。正确做法是上电时先执行整棵 ROM 树的搜索，把设备列表存到结构体数组里，运行中周期性检测有没有设备消失，同时也可以识别新接入的传感器。

读取温度时，主机先发 Skip ROM（0xCC）或者 Match ROM（0x55+序列号），然后发 Convert T（0x44）启动转换。12 位分辨率下转换时间最长约 750ms，这个等待时间里总线是空的，可以在主循环里处理其他事情，等时间到了再发读暂存器命令。好的工程实现应该是状态机轮询，而不是死等。

3.3 CRC 校验与重读机制

每条完整温度数据是 9 字节：前 8 字节包含温度、报警阈值和配置寄存器，第 9 字节是 CRC。CRC 多项式是 X^8+X^5+X^4+1，这个 CRC 可以用查表法实现，计算量很小。我的习惯是无论时间多紧，CRC 校验绝不能省。HVAC 现场的电噪声很任性，没有校验直接拿读到的温度做控制，等于把系统安全寄托在运气上。

如果 CRC 校验失败，我会连续重读 3 次，3 次都不通过就把这个传感器标记为“通信异常”。标记异常之后不是立刻报警或者把温度清零，而是保持上一次正常读到的最新的温度值参与控制，同时记录错误计数。这样做的好处是，短暂的干扰不会导致风机突然停机。连续错误计数超过一定次数后，才正式判定传感器离线，并触发上位机报警。

3.4 远程通信协议：Modbus RTU 子集

远程监测我用了 Modbus RTU，这是工业现场最通用、也最不容易踩坑的协议。PIC18F86J10 的 EUSART 直接接 RS-485 收发器，作为 Modbus 从机占用几个保持寄存器，上位机用 03 功能码读温度。温度值用有符号 16 位表示，单位 0.1℃，比如 253 代表 25.3℃。寄存器读取一次能读出全部通道，批量数据效率高，上位机不用轮询每个点。

实现 Modbus 从机时序时要注意帧间隙。RTU 模式下，两个帧之间至少要有 3.5 个字符时间的静默，收到完整一帧后要马上回帧。如果控制器的中断较多，建议把接收超时检测放在定时器中断里，避免主循环忙其他事的时候串口缓冲被覆盖。我遇到过上位机 10ms 轮询一次、主控板同时还在做单总线巡检，结果主循环总是在单总线延时里拔不出来，导致 Modbus 响应超时。解法是把单总线巡检改成状态机，一段延时拆成多个时间片，主循环保持高速响应串口。

3.5 主循环状态机设计

主循环我把它拆成几个状态：初始化、扫描总线、温度转换等待、数据读取、协议处理。状态机的好处是每个周期只做一件事，不会因为某个阻塞延时把其他任务饿死。温度转换等待期间，MCU 可以去刷新 LED、处理按键、响应 Modbus 请求。最终系统的输入输出响应时间从最开始的“偶尔卡顿”变成稳定的 10ms 级。

本地通道轮询状态机简化流程： READY -> START_CONVERT -> WAIT_CONVERT_DONE -> READ_SCRATCH -> CRC_CHECK -> UPDATE_VALUE -> NEXT_SENSOR

温度转换等待的时间槽里还可以干一些启动自检、参数刷新等轻量级任务。整体代码结构清楚之后，现场新加一个传感器通道只是配置数组加一，不用改主流程。

4. 实测记录：精度校准与现场稳定性

4.1 冰水混合物校准方法

数字传感器本身出厂有校准，但批量器件还是会有个体偏差。我在样机阶段用冰水混合物和 50℃ 恒温水浴做了两点校准。冰水混合物要把冰块打碎、加水搅拌，等温度稳定到 0℃ 附近再读取，记下每块传感器板的零点偏移。恒温水浴则用来校准斜率偏差。

校准的过程也暴露了一个细节：如果传感器探头部分直接泡在水里，必须用导热硅脂加保护套管，或者用带有防水封装探头，否则长时间浸水会导致读数漂移和密封失效。项目里我统一选了带不锈钢外壳的防水封装，校准完直接固定到风道和管道表面，长期稳定性好了很多。

4.2 线长与信号完整性实测

本地总线我控制在 3 米以内，远程总线通过独立采集板控制在 2 米以内，实际跑下来没有 CRC 错误。为了验证极限，我把一根 30 米长的网线芯对剥出来当 DQ 线测试，结果发现复位后的存在应答窗口变小，偶尔出现找不到传感器的情况。原因是长线电容大，上拉电阻需要更多时间把信号拉高，原本的采样时机就偏了。

处理办法有两个：一是把上拉电阻从 4.7kΩ 降为 2.2kΩ，增强驱动能力；二是在固件里适当延长读时序里切换输入后的等待时间，比如把采样点从释放后的 10μs 改为 20μs。这两个措施配合后，30 米线的可靠性还是不行，但 15 米以内基本能跑。所以我最终的结论是：单总线适合短距离本地采集，真正的远程点位要拆分到独立采集板上，或者考虑直接用 RS-485 温度传感器。

4.3 现场两个典型的疑难问题

第一个问题是远程采集板偶尔上报 -127℃。排查半天发现，不是传感器坏了，而是采集板上电时序里，MCU 引脚还没有完全进入开漏工作模式时，总线上的第一个复位脉冲居然被传感器忽略了。解决办法很简单：上电后先等 200ms，再执行一次完整复位周期，如果无应答就再复位一次。现在很多单总线传感器在上电后需要一段稳定时间，这个“先等再复位”的动作能省大量返工。

第二个问题更隐蔽。Modbus 轮询在某一台设备上总是 20 分钟左右卡一次，重连后又正常。后来抓了串口波形才发现，是上位机的轮询周期和采集板上的定时器中断产生了相位对齐，导致某个时刻中断占用过长，Modbus 帧尾的静默时间被拉长到超出上位机超时阈值。应对办法是给 Modbus 发送增加一个“忙则延迟”标志，主控检测到上位机连续重试时，自动把单总线巡检暂停 50ms，优先保证响应。这个问题也提醒我：现场稳定性问题，很多是多个周期性任务互相抢占造成的，不是某一个功能不行。

5. HVAC 场景的专项优化

5.1 回差控制与防频繁启停

温度监测的数据最终要回到控制逻辑。HVAC 设备最忌讳的是温度在阈值附近抖动导致压缩机频繁启停。我在控制逻辑里做了 2℃ 回差：制冷模式下，目标温度 24℃，不是到了 24℃ 立刻停，而是降到 23℃ 才停；回温到 25℃ 再启动。这样一台压缩机一个小时的启动次数能少一大半，使用寿命明显改善。

回差逻辑的数据来源也有讲究。直接用单次采样值做判断还是会被偶发尖峰带偏。我在温度数据上叠加了一个递推平均值滤波，窗口长度为 8 个采样周期，每个采样周期 1 秒，相当于 8 秒的平滑。这个响应速度对 HVAC 来说足够快，又不会因为瞬间干扰误动作。必要时还可以把“软件滤波值”和“实时采样值”分开，一个用于显示，一个用于保护逻辑。

5.2 防冻保护与报警联动

空调机组冬天容易冻盘管，这类保护逻辑必须稳定可靠。我在盘管出水温度上设置了两个阈值：低于 5℃ 时远程预警，低于 2℃ 时强制开启水泵防冻。这两个阈值对应的传感器通道是独立供电、独立总线的，即使其他通道通信失败，防冻通道依然能用。隔离不是浪费，是一种备份逻辑。

报警方面做了分级：传感器离线是最低级告警，只在上位机标记；温度超上限且持续 5 分钟，则输出声光报警并联动开启备用风机。温度报警延时的逻辑很有必要，因为现场开个门、调试一下也会导致短时温度波动，一波动就响铃会让人很快对报警“脱敏”。

6. 常见问题排查速查表

我把现场遇到过的现象和排查顺序整理成了表格。很多人一看到温度乱跳就怀疑传感器坏了，其实大部分是总线、电源或者接线的问题。

排查顺序上我的习惯是：先看电源质量，再看接线物理连接，最后才怀疑时序和协议。电源是一切的基础，在示波器上量一下传感器供电引脚上的纹波尖峰，很多诡异问题当场就能看清楚。

这个项目做到最后，我对温度采集这件事最大的体会是：传感器和 MCU 之间的协议只占一小部分，真正决定成败的是线缆如何走、电源怎么给、异常如何处理。单总线数字温度传感器的好处是布线简单、协议标准，但它对时序、上拉、寄生干扰同样敏感。把物理层的问题解决到位，这套架构在嵌入式温控和 HVAC 场景里可以非常稳定地跑很久。后来我又在几个新项目上复用同样的硬件和固件框架，基本就是换一下挂载数量、改一下寄存器表就完事，这也印证了当初在方案选型上花的功夫没有白费。