PJ85718DM与PIC18LF47K40双通道温度采集方案实战

1. 从一个温度采集需求说起：为什么选这对组合

嵌入式温度监测这件事，看起来简单，做起来坑不少。尤其是当你要同时盯着本地机箱内的温度和几十米外某个管道节点的温度时，选型就变成了一道综合题：本地测温要准、要稳，远程测温要能拉远、要抗干扰，主控还得有足够的算力和外设来同时处理两路数据、做逻辑判断、再通过某种方式把数据送出去。

我最近在做一个 HVAC 相关的温控节点，需求很明确：板载一颗温度传感器监测设备自身工作环境，同时通过远距离总线挂一颗远程温度传感器监测风道或水管的温度，主控负责轮询两路数据、做阈值判断、驱动继电器，并把数据汇总上报。选来选去，最后落在PJ85718DM这颗温度传感器加PIC18LF47K40这颗低功耗 8 位 MCU 的组合上。

为什么是这两颗？先说 PJ85718DM。它是一颗本地加远程双通道的温度监测芯片，本地通道用片上二极管或者内置传感结构测自身附近温度，远程通道则支持外接晶体管（通常是低成本的三极管接成二极管形式）来测远端温度。这种"一颗芯片管两路"的设计，直接省掉了一颗额外的远程测温芯片，PCB 面积和 BOM 成本都下来了。更关键的是，远程通道走的是电流模式信号，对走线电阻和噪声不敏感，这是它能拉远的核心原因。

再说 PIC18LF47K40。这是 Microchip PIC18 家族里比较新的一代，带 K40 后缀的型号在存储、外设和低功耗上都做了升级。选它的理由有三条：第一，它支持 1.8V 到 5.5V 的宽压供电，LF 版本尤其适合电池或者低压轨场景；第二，它片上集成了 I2C、SPI、UART、ADC、比较器、PWM 等一堆外设，跟 PJ85718DM 对接只需要 I2C 两根线，剩下的引脚还能干别的；第三，它的低功耗模式做得比较细，idle、sleep、doze 几档可以按需切换，对于 HVAC 这种常年通电但大部分时间没事干的设备来说，省电就是省寿命。

提示：PJ85718DM 的远程通道需要外接一个传感三极管，常见做法是用 2N3904 或 MMBT3904 把基极和集电极短接，用发射结当测温二极管。这个三极管要尽量靠近被测点，引线越短越好。

这套组合的定位很清楚：中低复杂度、成本敏感、需要本地加远程双点测温、主控还要兼顾其他控制逻辑的嵌入式场景。HVAC 里的风机盘管控制器、地暖分集水器温控、机房环境监控节点，都属于这个范畴。下面我把整个链路从硬件到固件拆开讲，包括选型逻辑、寄存器配置、通信协议、校准方法和实际调试中踩过的坑。

2. PJ85718DM 的双通道测温机制拆解

2.1 本地通道与远程通道的本质差异

很多人第一次用这类双通道温度芯片，会默认两个通道只是"位置不同"，配置应该差不多。实际上本地通道和远程通道在物理原理上就是两回事，配置逻辑也完全不同。

本地通道测的是芯片自身 die 的温度。PJ85718DM 内部有一个经过校准的传感结构，输出跟绝对温度成正比的电信号，片内 ADC 把它量化成数字量。这个通道的好处是简单、免外部元件、上电即用；缺点是它测的是芯片自己的温度，如果芯片旁边有发热元件（比如 LDO、MOSFET），读数会被带偏。所以本地通道的布局要点是：芯片尽量远离热源，如果实在避不开，就要在固件里做偏移补偿。

远程通道测的是外接三极管的发射结温度。原理是利用三极管发射结正向压降的负温度系数——温度每升高 1℃，Vbe 大约下降 2mV。但单点测 Vbe 没法直接算出绝对温度，因为 Vbe 还跟具体器件的工艺参数有关。所以这类芯片普遍采用"双电流法"：用两个不同大小的激励电流（比如 10μA 和 100μA，比例 1:10）分别流过传感三极管，测两次 Vbe，取差值 ΔVbe。这个 ΔVbe 只跟电流比和绝对温度有关，跟器件工艺参数无关，公式是：

ΔVbe = (kT/q) × ln(N)

其中 k 是玻尔兹曼常数，T 是绝对温度，q 是电子电荷，N 是电流比。反解出 T，就得到了远程温度。这就是为什么远程通道能做得准、能互换不同三极管的原因——它把工艺偏差消掉了。

注意：远程通道对传感三极管的型号有要求，必须用低噪声、发射结特性一致的小信号三极管。功率管或者达林顿管不能用，因为它们的发射结面积和串联电阻特性不适合双电流法。

2.2 寄存器映射与关键配置项

PJ85718DM 通过 I2C 跟主控通信，内部有一组寄存器。虽然具体寄存器地址要查数据手册，但功能分类是固定的，大致分这么几类：

配置寄存器里最需要动脑子的是转换速率。PJ85718DM 一般支持从每秒几次到每几秒一次的转换率选择。转换率越高，功耗越大，但响应越快。HVAC 场景里温度变化本来就慢，风道温度从 20℃ 升到 40℃ 可能要几分钟，所以完全没必要每秒转好几次。我通常设成 1 秒一次或者 2 秒一次，既够用又省电。

另一个关键是远程通道的串联电阻补偿。传感三极管到芯片之间的走线有电阻，如果走线长，这个电阻会在双电流法里引入误差。PJ85718DM 支持通过配置寄存器设置一个补偿值，抵消掉一部分串联电阻影响。走线越长，补偿值要越大。这个值不是拍脑袋定的，后面校准章节会讲怎么测。

2.3 远程通道的开路与短路检测

远程测温最怕的不是测不准，而是传感三极管掉了或者线断了，芯片还在那儿报一个看似正常的温度。PJ85718DM 内置了开路检测：如果远程通道的输入引脚检测不到正常的二极管结压降，状态寄存器里的开路标志会置位。

这个功能在 HVAC 里特别重要。想象一下，风道温度传感器装在吊顶里，线被老鼠咬断了，如果固件不检查开路标志，控制器会拿着一个错误的温度继续调节，可能导致风机一直转或者一直不转。所以固件里必须做两件事：一是每次读温度前先读状态寄存器，二是开路标志置位时把远程温度标记为无效，并触发一个故障上报。

短路检测同理。如果传感三极管被击穿短路，远程通道读数会跑到极端值，状态寄存器也会有对应标志。固件里对远程温度做一个合理性范围检查（比如 -40℃ 到 125℃ 之外就认为异常），能兜住大部分硬件故障。

3. PIC18LF47K40 侧的 I2C 主机实现与资源分配

3.1 为什么用硬件 MSSP 而不是软件模拟 I2C

PIC18LF47K40 片上有一个 MSSP 模块，可以配置成 I2C 主机模式。有人图省事用普通 IO 模拟 I2C，觉得灵活。但在跟 PJ85718DM 这种温度芯片配合时，我强烈建议用硬件 MSSP。

原因有三。第一，硬件 I2C 的时序由外设自己保证，不会因为中断打断而拉长时钟高电平导致通信失败。温度采集往往跟其他任务并行，软件模拟很容易在关键时刻被中断搅乱。第二，硬件 I2C 支持时钟拉伸处理，PJ85718DM 在转换期间如果被访问，可能会拉伸时钟，硬件模块能自动等待，软件模拟就得自己写等待逻辑。第三，硬件 I2C 省 CPU，配置好之后一次传输只需要写几个寄存器、等标志位，CPU 可以去干别的。

配置 MSSP 成 I2C 主机的步骤大致是：设置 SSPCON1 的 SSPM 位选主机模式，设置 SSPADD 计算波特率，配置 SDA 和 SCL 引脚的方向和输入输出模式。波特率方面，PJ85718DM 支持标准模式 100kHz 和快速模式 400kHz。我一般用 100kHz，因为温度数据量小，100kHz 足够，而且抗干扰余量更大，走线长一点也稳。

3.2 引脚分配与外围资源规划

PIC18LF47K40 引脚数根据封装不同有 40 脚、44 脚等版本。做 HVAC 控制器，引脚规划要提前想清楚，因为后面加功能很容易发现引脚不够。

我的分配思路是这样的：I2C 两根线（SDA、SCL）固定给温度芯片；留一路 UART 做调试和对外通信；留两路 ADC 输入接其他模拟量（比如湿度或者压力）；留几个 IO 驱动继电器或者光耦；再留一个引脚做状态指示灯。这样算下来，40 脚封装基本够用，但如果还要加 LCD 或者更多继电器，就得考虑 44 脚或者外扩 IO。

有个细节容易被忽略：PIC18LF47K40 的 I2C 引脚是复用引脚，配置成 I2C 功能后就不能再当普通 IO 用。所以在画原理图阶段就要把复用关系理清楚，别等到 PCB 打样回来才发现某个功能引脚被 I2C 占了。

提示：I2C 总线上一定要加上拉电阻，典型值 4.7kΩ。如果总线走线较长或者挂的设备多，可以降到 2.2kΩ。上拉电阻接到跟 MCU 和传感器相同的逻辑电平轨上，别接错。

3.3 低功耗模式下的温度采集节奏

HVAC 设备很多是常年通电的，功耗直接关系到电费和器件寿命。PIC18LF47K40 的低功耗模式配合 PJ85718DM 的间歇转换，可以做到平均电流很低。

我的做法是：让 PJ85718DM 以 1 秒一次的速率连续转换，MCU 平时处于 sleep 模式，靠定时器或者外部中断唤醒。唤醒后读一次温度，做判断，如果需要动作就驱动输出，然后继续睡。这样 MCU 大部分时间在睡，只有读数据那一小段时间在跑。

这里有个坑：PIC18LF47K40 从 sleep 唤醒后，I2C 模块需要重新初始化吗？实测下来，如果 sleep 期间 I2C 引脚状态保持，唤醒后 MSSP 寄存器内容不丢，可以直接用。但如果 sleep 前把 I2C 模块关了省电，唤醒后就得重新配置。我倾向于不关 I2C 模块，因为它的静态功耗很小，关了再开反而增加代码复杂度和唤醒延迟。

另一个坑是 PJ85718DM 的转换速率和 MCU 唤醒周期的匹配。如果 MCU 每 5 秒唤醒一次，而传感器每 1 秒转换一次，那读到的永远是最新值，没问题。但如果 MCU 唤醒周期比转换周期还短，就会读到重复值，浪费总线时间。所以两者节奏要配合好，一般让传感器转换周期小于等于 MCU 唤醒周期。

4. 从寄存器到摄氏度：数据换算与校准实操

4.1 原始数据的格式与符号处理

PJ85718DM 的温度结果寄存器通常是 16 位，高字节是整数部分，低字节是小数部分。但这里有个容易翻车的地方：负温度的表示。

正温度好办，高字节直接就是摄氏度整数，低字节按位权算小数。比如高字节 0x19（25），低字节 0x80，如果低字节最高位权是 0.5℃，那就是 25.5℃。但负温度就不一样了，很多这类芯片用的是补码或者带符号的定点格式。如果直接按无符号数读，-5℃ 可能被读成 251℃ 这种离谱值。

我的处理方式是：先把 16 位原始值当成有符号定点数，高字节做符号扩展，然后整体除以 256 得到摄氏度浮点值（假设低字节是 8 位小数）。具体代码大概这样：

int16_t raw = (int16_t)((high_byte << 8) | low_byte); float temp_c = raw / 256.0f;

这样不管正负都能正确换算。但要注意，不同厂家的格式可能不同，有的低字节只有高 4 位有效，有的用 0.0625℃ 分辨率。所以第一步一定是查数据手册确认格式，别想当然。

4.2 本地通道的偏移校准

本地通道测的是芯片 die 温度，而 die 温度通常比环境温度高一点，因为芯片自己在耗电。这个自热误差在低功耗间歇工作模式下很小，可能只有 0.1℃ 到 0.5℃，但在连续转换模式下会明显一些。

校准方法很简单：把设备放在一个已知温度的恒温环境里（比如用校准过的温度计确认环境是 25.0℃），等热平衡后读本地通道值，差值就是偏移量。把这个偏移量写进固件，每次读数减去它。

但要注意，这个偏移量跟工作模式有关。连续转换和间歇转换的自热不一样，所以校准要在实际工作模式下做。我一般会在固件里留一个偏移常量，方便后期根据实测调整。

4.3 远程通道的串联电阻补偿实测

远程通道的串联电阻补偿是这套方案里最需要动手测的部分。理论上的补偿值是走线电阻加上三极管串联电阻，但实际走线电阻不好精确计算，所以得实测。

我的实测方法是：先用一根很短的线连接传感三极管，读一个温度值作为基准。然后换上实际长度的线，再读一次。如果读数偏高，说明串联电阻导致激励电流实际变小，ΔVbe 偏大，算出的温度偏高，需要增加补偿值。反复调整补偿寄存器，直到长线读数和短线读数一致。

这个过程听起来麻烦，但做一次就行，因为走线长度固定后补偿值就固定了。我一般会在 PCB 设计阶段就把传感三极管的走线长度定下来，然后在样机上做一次校准，把补偿值固化到固件里。

注意：串联电阻补偿只在双电流法下有效，而且补偿范围有限。如果走线太长，超出补偿范围，就得考虑用屏蔽线或者换用其他远程测温方案。一般几十米以内问题不大。

4.4 温度数据的滤波与上报策略

原始温度数据总会有抖动，尤其是远程通道，走线长、噪声大，读数可能上下跳 0.5℃ 甚至更多。直接拿原始值做控制判断，会导致继电器频繁动作。

我的做法是加一个滑动平均滤波。维护一个长度为 8 的环形缓冲区，每次读到的温度存进去，取平均值作为有效值。这样既能平滑抖动，又不会引入太大延迟。8 个样本在 1 秒转换率下就是 8 秒延迟，对 HVAC 来说完全可以接受。

如果抖动特别大，可以在滑动平均之前先做限幅滤波：如果本次读数和上次有效值差超过 2℃，就认为这次是异常值，丢弃不用。这个限幅阈值要根据实际场景定，太小会误杀真实快速变化，太大又起不到滤波作用。

上报策略上，我一般只在温度变化超过 0.5℃ 或者状态标志变化时才主动上报，平时就静默采集。这样能减少通信负担，尤其是用无线或者总线上报的场景。

5. 联调阶段踩过的坑与排查链路

5.1 I2C 通信时好时坏：上拉电阻与走线的锅

样机刚做出来的时候，I2C 通信十次里有两三次失败，读回来的温度是 0 或者 0xFF。一开始怀疑是芯片配置问题，查了半天寄存器没发现异常。后来用示波器抓 SDA 和 SCL 波形，发现 SCL 上升沿很缓，明显是上拉太弱。

原来我按习惯用了 10kΩ 上拉，但这条总线走线比较长，加上探头和杂散电容，10kΩ 拉不起来。换成 4.7kΩ 后，上升沿明显变陡，通信成功率上去了。后来为了保险，又降到 2.2kΩ，彻底稳定。

这个坑的教训是：I2C 上拉电阻不是随便选个常用值就行，要结合总线电容算。总线电容越大，上拉电阻要越小，但太小又增加功耗。经验公式是上升时间约等于 0.8 倍 RC，标准模式 100kHz 要求上升时间小于 1000ns，据此反推 R 值。

5.2 远程温度读数偏高十几度：补偿值没设

远程通道第一次读数，比实际温度高了差不多 15℃。一开始以为是三极管接错了，检查发现基极和集电极确实短接了，没问题。又怀疑是电流比配置错了，查寄存器发现默认就是 1:10，也没错。

后来想到串联电阻补偿，查数据手册发现补偿寄存器默认是 0。我的传感三极管走线大概 30 厘米，串联电阻不小。把补偿值从 0 逐步往上调，每调一档读一次温度，调到某个值的时候读数跟实际温度对上了。最后固化下来的补偿值对应的等效电阻大概几十欧姆，跟 30 厘米走线的电阻量级吻合。

这个坑说明，远程通道不校准直接用，误差可能大到没法接受。而且不同板子走线长度不同，补偿值不能照抄，必须每块板子或者每种走线长度单独校准。

5.3 负温度下读数乱跳：符号处理写错了

冬天测试的时候，把设备放到室外，温度降到零下。结果远程温度读数在 -5℃ 和 251℃ 之间乱跳。一看就是符号处理出了问题。

原来我读温度结果时，先读高字节再读低字节，拼成 16 位后直接当无符号数处理。正温度没问题，负温度时高字节是 0xFF 之类的值，当无符号数就是 255，减去偏移后变成 251。改成有符号数处理后，-5℃ 就正常显示了。

这个坑的教训是：温度数据一定要确认符号格式，是补码还是偏移二进制，是 8 位还是 16 位。不同芯片格式不同，甚至同一芯片不同寄存器格式都可能不同。读数据手册时要把这一节看仔细。

5.4 低功耗模式下唤醒后第一次读数异常

在做低功耗测试时发现，MCU 从 sleep 唤醒后第一次读温度，值总是偏高或者偏低，第二次读就正常了。一开始以为是传感器需要稳定时间，后来查资料发现是 I2C 总线在 sleep 期间状态不确定，唤醒后第一次传输可能不完整。

解决办法是在唤醒后先做一次 dummy 读（读一个无关寄存器），把 I2C 状态机理顺，然后再读温度。或者更稳妥的做法是唤醒后重新初始化 I2C 模块，虽然多花点时间，但保证状态干净。

这个坑比较隐蔽，因为正常运行时不会出现，只有低功耗场景才暴露。做低功耗产品时，唤醒后的外设状态恢复一定要专门测试。

6. 这套方案还能怎么扩展

6.1 多路远程测温的复用思路

PJ85718DM 只有一路远程通道，如果 HVAC 系统需要同时监测多个点位（比如回风、送风、盘管三个温度），一颗芯片就不够了。这时候有两个思路：一是挂多颗 PJ85718DM，用 I2C 地址区分；二是换用多通道的远程测温芯片。

挂多颗的话，I2C 地址要规划好，别冲突。PJ85718DM 一般有地址选择引脚，可以配出几个不同地址。总线负载也要考虑，挂太多设备电容会上去，上拉电阻要相应调整。

如果点位特别多，我会考虑用模拟开关切换传感三极管，只用一颗芯片的远程通道分时测量。这样成本最低，但切换后需要等稳定时间，响应会慢一些。对 HVAC 这种慢过程来说，慢一点无所谓。

6.2 把温度数据接入上层系统的几种方式

温度采回来之后，怎么送出去也是个设计点。PIC18LF47K40 有 UART、SPI、I2C 可以选。如果设备是独立控制器，可能只需要本地显示和继电器输出，那就不用通信。如果要接入楼宇自控系统，常见的是 Modbus RTU over UART，或者通过无线模块上报。

我一般会留一路 UART 做调试口，同时兼容 Modbus 从站协议。这样既能用串口助手看数据，又能接入标准系统。协议实现上，Modbus 的保持寄存器映射温度值，整数部分和小数部分各占一个寄存器，上位机读两个寄存器拼起来就行。

6.3 固件升级与参数存储的考虑

HVAC 设备装到现场后，改参数或者升级固件是常有的事。PIC18LF47K40 的 Flash 支持自写，可以做 bootloader 通过 UART 升级。参数（比如温度门限、补偿值、校准偏移）存在 EEPROM 或者 Flash 的保留区，掉电不丢。

这里有个经验：参数存储要做校验和，读出来先校验，校验不过就用默认值。现场干扰大，EEPROM 偶尔会翻位，没有校验的话可能拿着一个错误参数运行，后果比用默认值严重。

6.4 电磁兼容性方面的实际处理

HVAC 环境里继电器、风机、变频器一大堆，电磁干扰不小。温度信号本身是低频慢信号，抗干扰主要靠硬件。我的做法是：传感三极管的走线尽量短，用双绞线或者屏蔽线；I2C 走线远离功率走线；电源加去耦电容；继电器线圈加续流二极管。

软件上也能做一点事：温度读数做合理性检查，突变超过阈值就丢弃；通信失败重试几次再报错；关键参数写 EEPROM 时先擦后写再回读校验。这些措施加起来，现场稳定性会好很多。

我在实际项目里用这套 PJ85718DM 加 PIC18LF47K40 的组合做过几版温控节点，从样机到小批量，整体表现比较稳。最深的体会是：远程测温的校准不能省，串联电阻补偿和符号处理这两个点最容易翻车，低功耗场景下唤醒后的外设状态恢复要专门测。把这几个地方盯住，剩下的就是常规的嵌入式开发工作了。