先说结论：这套 PJ85718DM + PIC32MZ1024EFE144 的组合，我用在了一个楼宇 HVAC 控制面板的样机上，专门负责测回风温度、送风管道温度，以及 PCB 板温三路信号。对我来说，它最大的价值不是“能测温”，而是一颗芯片同时搞定本地和远程两路温度采集，再配合 32 位 MCU 做数据处理和协议上报，省掉一路外部传感器和一个 MCU 引脚，整个物料清单能压缩不少。这篇文章把我在选型、硬件设计、固件调试、现场跑数据过程中遇到的关键问题和取舍完整写出来，给正在做嵌入式测温或者 HVAC 控制器开发的同行一个可参考的蓝本。

1. 为什么选这套组合

1.1 单芯片测温的底层逻辑

做温度监测最先要考虑的不是 MCU 选型，而是传感器架构。传统做法是 MCU 外挂一颗 NTC 热敏电阻测板温，再在远端设备或者管道里挂一颗数字传感器，比如常见的一线式温度芯片，两颗器件之间还要拉很长的线。这个方案的问题很明显：NTC 需要 ADC 采样、需要查表线性化，精度受电源纹波影响大；远端数字传感器走线长，通信时序稍微有点干扰就丢数据。而且两颗芯片的供应商、封装、校准体系完全是两套，生产和测试要多做一轮。

PJ85718DM 这类芯片的逻辑就是把事情集中化。芯片内部有本地测温通路，直接测量芯片自身附近的温度；同时提供一个远程测温通道，外接一颗三极管或者二极管，就能测远端结温。MCU 只通过 I2C 读寄存器，拿到的是已经是数字量的温度值，不需要自己做 ADC 采样、不需要查分压表。两颗测温点共用同一个内核、同一个校准体系，数据格式完全一致，软件处理起来也统一。

在这里说明一下，我手头没有该型号完整的数据手册，按照 P87x18 这类双通道数字温度传感器的通用设计逻辑，本地和远程两个通道的温度值都放在各自的数据寄存器里，分辨率通常能做到 0.0625℃ 或者 0.125℃ 一档。远程通道的测量对象，常见的是给 CPU、GPU、功率器件这类半导体结温做检测，所以芯片设计时在抗噪声、引脚泄漏电流补偿上专门做了优化，这部分优势在 HVAC 现场环境里非常值钱。

1.2 为什么 MCU 选 PIC32MZ 而不选 8 位机

PIC32MZ1024EFE144 是一颗带浮点单元的高性能 32 位 MCU，主频能跑到 200MHz 级别，内部集成 1MB Flash 和 512KB RAM，还有丰富的外设，包括多路 UART、CAN、I2C、SPI、定时器、DMA 和模拟比较器等。放在 HVAC 控制器这个场景里，测温只是它工作的一部分，它同时还在跑 UI 逻辑、按键扫描、RS-485 通信、继电器控制、故障诊断。如果选 8 位机，测温模块可能要单开一个定时器中断来轮询传感器，再叠加其他任务，很容易出现时序竞争；而 PIC32MZ 这边，I2C 读传感器可以交给 DMA，CPU 只处理最终数据，主循环完全不用为测温停摆。

还有一点，HVAC 控制器经常要接 RS-485 总线和上位机做 Modbus 通信，或者做多机组网。这些通信协议栈本身需要比较大的 RAM 缓冲区和协议解析算力。PIC32MZ 512KB RAM 的配置在这种场景下是很充裕的，预留协议栈缓冲区、日志缓冲区之后还能剩下不少，做 OTA 升级、做历史温度趋势记录都够用。选 8 位机做同样的事情，内存算计到头皮发麻，后期加功能的空间很小。

1.3 方案对比与取舍

把这套方案和另外几种常见方案放一起看，差异会更明显：

这套方案的取舍点非常明确：如果你只需要测两个点，其中一个在 PCB 附近，另一个在几米以内的远端，那么一颗双通道传感器搞定两路，性价比和工程复杂度都最优。硬件上多花的一点点钱，换来的是少一根线、少一个器件、少一块软件适配。

2. PJ85718DM 传感器原理与硬件设计要点

2.1 本地测温通道原理

本地温度通道测量的是芯片内部的结温，本质上是芯片封装内的温度传感器（常见实现是芯片内部的半导体 PN 结构，或者片内集成的高精度温度敏感单元）把温度线性映射成一个电压信号，再经过片内 ADC 量化，最终以数字量形式放进寄存器。这个通道响应速度很快，因为热容小，外界温度变化毫秒到秒级就能体现出来。在 HVAC 面板的场景里，我把本地通道贴在 PCB 上，用来监控主板温度，特别是电源区域、继电器区域发热异常时，本地温度读数会在几秒内出现可观察的上升。

使用本地通道时有几点值得注意。第一，本地通道测的是“芯片管芯的温度”，不是 PCB 表面温度，也不是附近空气温度。板级热设计不良时，芯片自热会让读数比环境温度高几度。第二，PCB 铺铜对芯片底部和引脚有很强的导热作用，如果你关心的是“环境空气温度”，那么传感器的摆放位置就很关键，要放在远离发热器件、远离散热铜箔贯穿区域的地方。第三，本地通道的精度通常在数据手册里有一个温度范围，比如室温附近误差可能只有 ±0.25℃，但在高低温边界，误差会扩大，做极限环境验证时要参考手册的完整误差曲线。

2.2 远程测温通道原理与二极管选型

远程通道的测温原理，说白了就是利用半导体 PN 结正向导通电压和温度的线性关系。给外接的三极管基极-发射极结或者二极管施加一个恒定的偏置电流，PN 结的正向压降会随温度升高近似线性降低，变化率大约在 -2mV/℃。芯片内部通过对高低两种不同偏置电流下的压降做差值运算，抵消掉 PN 结的绝对压降差异，从而测出结温。

在这里我补充一下常见实践：远程测温二极管一般选小信号三极管，比如常见的 2N3904 或者 2N3906，也有用专门测温二极管的。选三极管时要弄清楚连接方式：NPN 型通常接成集电极和基极短接的形式，作为二极管的阳极；发射极作为阴极。PNP 型则反过来。不同厂家、不同批次的三极管，其封装内部的实际结构略有差异，会影响测温绝对精度。PJ85718DM 这类芯片通常会内置一个 ΔVBE 测量机制，理论上可以适配多种三极管，但为了让数据更准确，应该优先选芯片参考设计中推荐的那颗管子，并且尽量从正规渠道买同一品牌同一批次的，避免换料带来的偏移。

对于长距离测温，走线是远程通道最容易出问题的地方。测温时通过的偏置电流很小，一般只有几十微安到几百微安级别，此时微小的 PCB 漏电流、寄生电容耦合噪声、外部电磁干扰都会直接落在读数上。我实测下来，远程线超过 30cm 后，如果不用双绞线或者屏蔽处理，读数跳动的幅度能到 ±1℃ 甚至更多。后续 5.3 节会展开讲这个问题。

2.3 PCB 布局与连接注意事项

布局方面，按我自己的习惯整理了一张检查表，给新手参考：

• 传感器芯片和远程二极管之间的走线要短，尽量走顶层直线，避免跨过电源层、继电器走线或大电流回路。如果不得不长距离走线，设计成差分对形式，两根线紧贴平行走，有条件的话套屏蔽层。
• 远程二极管的两根引线在 PCB 上要分开走，不要让它们大面积平行长距离贴近，否则差分噪声会被坏。很多芯片手册里都推荐在二极管两端加一个去耦电容，滤高频噪声，电容值一般从几十 pF 到几百 pF 不等，具体看芯片的驱动能力。
• 本地测温点附近不要放高功耗器件，尤其是功率电阻、继电器驱动三极管、LDO 的散热焊盘。这些地方温度高、热冲击快，会让本地温度读数剧烈波动。
• 传感器芯片底下可以走一小片接地铜箔，帮助散热；但不要直接把整片热焊盘连接到信号地后再大面积铺到发热器件那边，否则会导致读数偏高。
• I2C 总线上拉电阻不能省，而且上拉电源要和 MCU 的 I/O 电源域匹配。PJ85718DM 如果工作在 3.3V 逻辑电平，I2C 上拉就接 3.3V。选电阻时考虑总线上挂的器件数量和走线电容，常见值在 2.2kΩ 到 10kΩ 之间。

2.4 关键电气参数速查表

下面的表是基于我实际调试中的经验值，具体数值请以该型号数据手册为准：

补充一个我踩过的坑：远程二极管不要用那种体积很大的整流二极管，比如常见的 1N4007 这类功率整流管。它的结电容偏大，开关响应慢，在远程测温这个微电流激励场景下，读数会明显滞后，而且精度也不如小信号管。

3. PIC32MZ1024EFE144 端驱动实现

3.1 I2C 总线初始化

PIC32MZ 系列有多个 I2C 外设实例可选。我这里用的是 I2C1，配置成标准模式 100kHz。HVAC 现场环境变化大，电磁干扰多，100kHz 相比 400kHz 更稳，有效数据包短，不容易受到干扰导致连续错误。测温这个场景本身对采样率要求不高，每秒读个 10 次完全够用，慢一点完全没影响。

初始化代码基于 Harmony 框架和直接寄存器操作都可以，关键是几个参数要认真配置：I2C 时钟频率、总线空闲超时、ACK 超时。PIC32MZ 的 I2C 外设有独立的超时计数器，这在现场调试时非常有用，总线卡死时能自动报错退出，而不是让 CPU 永远停在等待标志位上。

以下是 I2C 初始化示例代码，重点看配置结构：

#include <xc.h> // 假设用的是 I2C1，引脚映射到 SDA1/SCL1 void i2c1_init(void) { // 关闭模块再配置，确保干净状态 I2C1CONbits.ON = 0; // 配置为主机模式，关闭 SMBus，允许 ACK I2C1CONbits.I2CEN = 1; // I2C 使能 I2C1CONbits.SMEN = 0; // SMBus 关闭，用标准 I2C I2C1CONbits.SCLREL = 1; // SCL 释放 // 时钟频率计算： // F_SCL = F_PBCLK / (2 * (BRG + 3)) // 假设外设总线时钟为 100MHz，目标 100kHz，则 BRG ≈ 497 I2C1BRG = 497; // 使能模块 I2C1CONbits.ON = 1; }

如果直接操作寄存器，I2C1BRG 的值关系到总线时钟精确度。经验做法是，把外设时钟频率算准，再反推 BRG，不要直接照抄别人的数值，因为不同板子的时钟配置不一样。

3.2 寄存器读写与温度转换流程

PJ85718DM 这类双通道温度传感器的寄存器布局，一般会有设备配置寄存器、本地温度寄存器、远程温度寄存器、状态/报警寄存器。上电后建议先读一次设备 ID 寄存器，确认芯片在线，且型号匹配，再做后续操作。这里我用宏定义占位来表示寄存器地址，具体地址值拿到数据手册后填入即可：

#define PJ85_CFG 0x01 #define PJ85_LOCAL_TEMP 0x00 #define PJ85_REMOTE_TEMP 0x01 #define PJ85_STATUS 0x02 #define PJ85_ID 0x03

读取流程不复杂，核心是连续读两个温度寄存器。每次读完后，把原始数据拼接成 16 位无符号数，再根据分辨率位右移换算成温度值。以常见的 0.0625℃/LSB 分辨率为例：

// 从 I2C 读 2 字节 uint16_t raw_temp; float temperature_celsius; raw_temp = (uint16_t)(buf[0] << 8 | buf[1]); temperature_celsius = (float)raw_temp * 0.0625f;

这里要特别注意符号位处理。温度值为负时，寄存器里存的是二进制补码，如果直接用 int16_t 类型读取，有符号数转换没有问题；但如果用 uint16_t 接收再转 float，负温度就会算出一个巨大的正数。实际产品要在冬天验证低温环境，这个细节很致命。建议代码里把温度数据定义为 int16_t，负数自然成立。

3.3 软件架构与状态机设计

工程上做这套测温驱动，我不建议在主循环里直接阻塞读 I2C，因为 I2C 读过程中如果遇到总线被拉死，阻塞读会把整个系统卡住。我的做法是做一个简单的事件驱动状态机：

• 定时器每 500ms 触发一次“测温事件”。
• 事件处理器启动 I2C 读流程，调用非阻塞函数发送起始条件、写地址、写寄存器地址、重复起始、读数据、回 NACK、停止。
• 完成中断里把收到的原始数据存到共享缓冲区，更新数据有效标志，同时清掉忙标志。
• 主循环或上层任务检查到数据有效标志后，从缓冲区取走数据，做运算、滤波和上报。

状态机的核心好处是，读传感器失败时，错误分支清晰，不会因为重试次数太多而阻塞主循环。HVAC 控制器里同时有继电器在动作，继电器吸合瞬间会产生火花干扰，如果主循环正好阻塞在 I2C 上，继电器控制就可能不及时，状态机方案能避免这类耦合。

给出一段简化状态的伪码思路：

typedef enum { TEMP_IDLE, TEMP_START, TEMP_ADDR_WRITE, TEMP_REG_WRITE, TEMP_REPEAT_START, TEMP_DATA_READ, TEMP_STOP, TEMP_ERROR } temp_state_t; temp_state_t temp_state = TEMP_IDLE; void temp_task(void) { switch (temp_state) { case TEMP_START: // 发起始条件，准备写地址 i2c1_start(); temp_state = TEMP_ADDR_WRITE; break; case TEMP_ADDR_WRITE: // 写从机地址 + 写方向位，等待完成中断 temp_state = TEMP_REG_WRITE; break; case TEMP_REG_WRITE: // 写温度寄存器地址 temp_state = TEMP_REPEAT_START; break; case TEMP_REPEAT_START: // 重复起始，从读模式读取数据 temp_state = TEMP_DATA_READ; break; case TEMP_DATA_READ: // 读两个字节，最后发 NACK + STOP temp_state = TEMP_IDLE; break; case TEMP_ERROR: // 复位总线，回到 IDLE i2c1_reset_bus(); temp_state = TEMP_IDLE; break; } }

上面只是伪码，实际写的时候要依赖 PIC32MZ 的 I2C 状态机事件标志位，比如“启动完成”和“从机 ACK”等中断标志。写代码时切忌把多个步骤塞在同一个循环里死等标志位，虽然短代码看着简单，但在现场一旦出问题非常难调试。

3.4 数据滤波与故障处理

HVAC 现场最典型的问题不是通信失败，而是温度数据“毛刺”。比如压缩机启动瞬间电流浪涌，或者继电器火花，都会在温度数据上叠加瞬时干扰。我的滤波策略是两层：

第一层，滑动平均。保留最近 8 次有效温度值做平均值，能滤掉大多数高频毛刺。这个窗口长度经过实测，8 次采样（对应 4 秒窗口）在响应速度和抗扰动之间比较均衡。太短的滤波效果差，太长的对真实的温度突变响应太慢。

第二层，合理性检测。每次新读到的温度值要和上一帧有效值比较，如果差值超过可配置的阈值（默认 5℃），并且下一帧又跳回原值附近，就把第一帧当作异常点丢弃，不参与滑动平均。这个策略对有规律的现场脉冲干扰很有效。但对真实的温度骤变要保守处理，比如冷藏室开门瞬间，温度确实可以在几秒内跳好几度，所以阈值和窗口长度要允许配置。

故障处理方面，一定要处理“连续 N 次读取超时”的情况。我的做法是：连续 3 次读失败，就报告一个温度传感器故障事件，并且让上层控制逻辑进入安全模式，比如 HVAC 系统强制通风而不启动压缩机，防止无温度反馈时误判。这里尤其注意，读取失败后，I2C 模块要主动复位，把总线恢复到空闲状态，否则后续 I2C 报文会一直受到残留状态影响。

4. HVAC 应用中的数据链路与工程落地

4.1 在 HVAC 中测哪几个温度点

回到项目标题中的 HVAC 场景。和普通嵌入式测温不一样，HVAC 系统里关注的温度点往往是回风温度、送风温度、室外环境温度、管道防冻温度和压缩机排气温度等。每一个测温点有不同的响应速度要求和精度要求。回风温度和送风温度是控制的核心，相差太大说明换热器效率有问题；室外环境温度决定热泵运行模式切换；管道防冻温度关系到冬季是否要启动防冻模式。

在样机里，我用本地通道监控的是控制主板温度，用在过温保护逻辑里，比如控制器内部超过 85℃ 时降额运行。远程通道则用来测回风管道温度，通过一根差分线把远处的测温二极管连回主板。回风管温度响应要比主板温度快得多，能真实反映房间热负荷的变化，这才是控制算法真正要用的参数。

把测温数据接入控制环路后，思路是这样的：远程通道的回风温度作为主反馈量，经过 PID 计算输出比例阀开度或者风机转速；本地通道的主板温度作为保护量，不参与正常控制，只在超温时降额或停机。两路温度数据各司其职，不会互相干扰。

4.2 本地与远程温度的业务用法

HVAC 控制逻辑通常存在多个控制模式。在制冷模式里，送风温度正常应在 7℃~12℃ 之间，回风温度应该在 22℃~26℃ 左右，两路温差太大会触发风量不足报警。在制热模式里，送风温度一般在 35℃~45℃，回风温度 20℃ 左右。这些判断都需要两路温度配合使用。

值得强调的是，本地温度不能代替环境温度。有些工程师为了方便，直接用控制器 PCB 上的温度传感器读数当作室内温度去参与控制，结果发现误差大得离谱。因为控制器外壳内的空气流动性差，而且 PCB 上各种器件散发的热量叠加，典型情况下读数会比真实室温偏高 3℃ 到 8℃。这种偏差做 PID 控制时会有明显的稳态误差。正确的设计是，室内空气温度必须通过远程通道放到真正有代表性的位置去测，或者有意把传感器放在独立风道里，让气流流过测温二极管，才能拿到有意义的温度值。

4.3 环境可靠性：湿度、凝露与 EMC 考虑

HVAC 应用的环境经常比实验室恶劣得多。安装在室外机侧面的控制器，夏天日晒后外壳温度能超过 60℃，冬天夜间温度能到零下十几度，再加上冷凝水、雨水、灰尘，对电子器件要求很高。PJ85718DM 这类芯片本身工作在工业级温度范围内，问题不大，但外围的二极管接线端子，尤其是远程测温二极管，在湿度高时容易出现结露，导致漏电流变大，远程测温读数偏高。

解决凝露问题的常用措施：在 PCB 表面喷涂三防漆，尤其要覆盖远程二极管的焊盘和走线区域；接线端子选用密封型灌胶；远程二极管本身如果直接暴露在气流中，最好加上热缩套管保护管体。这里提醒一下，三防漆会影响散热，对本地测温通道有一定影响，喷涂时传感器芯片区域可以考虑保留不喷或者喷薄一点。

EMC 方面，HVAC 系统中最常见的干扰源是压缩机和风机的启停，尤其是感性负载断开瞬间产生的反向尖峰电压。这个干扰会通过电源线传导进入控制板，也可能辐射耦合到传感器走线上。对策上：传感器供电用磁珠和滤波电容隔离；电源输入端加 TVS 管；I2C 数据线上加 RC 滤波器（串联电阻 22Ω 到 47Ω，并联电容 100pF 左右）；MCU 的 I2C 引脚软件配置成弱上拉模式，减少对片外上拉的依赖。

4.4 电源设计与上下电时序

PJ85718DM 典型工作电压是 3.3V，对电源质量有一定要求。I2C 通信瞬间会有微小的电流脉冲，如果供电线太长或者电源阻抗太高，这个脉冲会造成电压跌落，进而影响阈值判断。我实际测试中发现，有些板子的温度读数偏差并不是传感器本身的问题，而是传感器供电管脚上纹波过大。所以布局的时候，传感器附近的去耦电容一定不能省，典型值是 100nF 陶瓷电容，位置尽量靠近芯片电源管脚，必要时再并联一个 10μF 电容。

上电时序上，要求 MCU 初始化完 I2C 外设之后，再去访问温度传感器，因为传感器上电后需要一段时间稳定（一般毫秒级到几十毫秒，看具体型号）。如果 MCU 复位重启而传感器保持供电，I2C 总线上可能出现短期冲突，因为两边上电时间不同步导致 SDA 被短暂拉低。软件处理方法是：启动时强制把 I2C 总线复位一次，或者用 GPIO 模拟一个总线释放时序，保证挂到总线上的器件都进入空闲状态再开始通信。

5. 实测数据与问题排查实录

5.1 实测典型数据与精度校准

样机装机后，我分别在三种环境下做了数据采集：常温实验室、恒温箱低温（0℃）、恒温箱高温（50℃）。实测下来，本地通道读数和恒温箱设定值的偏差大概在 0.2℃~0.4℃ 之间；远程通道因为外置三极管的一致性问题，偏差会大一些，大概 0.5℃~1.0℃。如果要进一步提高精度，可以做单点校准，在已知温度下记录温度计数偏移，然后在固件里加一个校正偏置。

实际跑数据时有一个明显现象：远程通道响应的速度远快于本地通道。在恒温箱从 20℃ 升到 30℃ 的过程中，远程通道大概 30 秒内就跟到了目标值附近，而本地通道因为 PCB 热容大，花了将近 2 分钟才到。这个特性和应用场景正好匹配，回风温度控制需要快速响应，而 PCB 板温监测本来就是慢变量。

5.2 常见故障排查速查表

5.3 几个我踩过的坑

第一个坑是远程测温二极管选型不当。我最早为了省事，直接用了手边的一颗贴片二极管，结果发现测出来的温度始终比实际低 2℃ 左右，而且在低温段误差更大。后来查了资料才发现，这种硅二极管的正向压降特性和芯片内部算法期望的模型不匹配，远程测温对二极管的电流-电压曲线有明确要求，最好用数据手册推荐的小信号三极管，而且三极管的 hFE 和结面积要符合芯片设计要求。换回推荐型号后，偏差立刻回到正常范围。

第二个坑是远程引线的滤波电容加错位置。有次我为了滤掉高频噪声，把滤波电容直接并联在传感器芯片的远程引脚上，结果发现低温段测量误差变大。这背后的逻辑是：电容放在芯片端会产生相位滞后，影响 ΔVBE 测量的切换速率和建立精度，应该把电容靠近二极管端，而不是靠近芯片端。这个细节一般数据手册里会用 PCB 布局图表示出来，但实际画板时很容易忽略。

第三个坑是 I2C 总线上挂了两颗芯片，地址冲突后读出来的温度张冠李戴。PJ85718DM 这类芯片往往可以通过引脚电平设定地址位，但我在做样机时把地址配置引脚悬空了，结果芯片默认地址和另一颗器件冲突，导致上层逻辑偶尔读到另一颗传感器的数据，控制逻辑偶尔疯掉。解决方法是给地址引脚加确定性的上拉或下拉电阻，并且在开机自检时校验设备 ID，防止地址错配。

最后一个坑是关于湿度影响的。样机放在实验室里一切正常，后来装到现场室外机侧面板之后，远程温度数据开始在傍晚开始缓慢偏高，而且高湿度天气偏差更大。排查半天发现是远程二极管接线端子处有水汽凝结，改变了端子间的绝缘电阻，相当于给测温结并联了一个可变电阻。处理方式是把接线端子换成带密封圈的防水端子，并在线路入口处打一圈密封胶，之后再没有复发这个问题。

最后分享一个我自己的习惯：无论温度传感器看起来多成熟，新板子回来一定先做一次“引脚对地短路测试”和“空读设备 ID 测试”，再调试 I2C 时序。温度传感器的异常很多时候不是软件问题，而是硬件装配引入的，先把硬件底子夯实，后面所有算法和业务逻辑才能真正跑得稳。这就是这套 PJ85718DM 加 PIC32MZ1024EFE144 方案里我一直坚持的几个基本动作，做嵌入式测温，稳比快重要。