企业官网建设流程全解析

做 HVAC 温控板的朋友应该都有过这种经历：传感器读数不是不能用，而是你不太确定它反映的到底是哪里的温度。最近我把一套嵌入式温度监测方案从模拟 NTC 换成了 PJ85718DM 数字温度传感器，主控用 PIC32MX675F256L，同时维护本地温度和远程温度两路数据。项目跑了一阵子，该踩的坑基本都踩了一遍，现在把硬件连接、驱动代码、校准思路和排查步骤整理出来，给正在做嵌入式温控或者 HVAC 控制器的人当个参考。

这里说的"本地温度"指的是主控板工作环境附近的温度，"远程温度"指的是传感器被放到风道、回风口或者室外机旁边测到的温度。两者物理位置不同、热惯性不同，控制语义也完全不同。如果你也在纠结"到底以哪路温度为准来控制风机"，这篇文章应该能给你一个比较务实的答案。

1. 温度为什么非要分成"本地"和"远程"两路来测

1.1 HVAC 项目里的真实温度场景

大多数 HVAC 控制器并不是只装在一个恒温环境里。控制器装在电控箱内，箱体里还有开关电源、继电器、驱动器，这些东西一工作，箱内温度比环境温度高个三五度很正常。而真正要控的是风道里或房间里的温度，传感器往往要拉出去一两米甚至更远。

如果把传感器放在控制板上，测到的是"电控箱热不热"，不是"房间热不热"；如果只把传感器放远端，主控板过热时没人管。所以实际项目里两路温度缺一不可：远程温度参与正常温控，本地温度做保护与故障兜底。

1.2 数字温度传感器相比模拟 NTC 省在哪

以前用 NTC 分压采样，电路不复杂，但麻烦在标定。NTC 的 B 值分散性大，同一批料装上去，读数能差一两度；再加上分压电阻的精度、ADC 基准电压的温漂，想把误差压到 ±0.5°C 以内，每一路都要单独校准，量产时相当痛苦。

PJ85718DM 这类数字温度传感器把感温元件、ADC、I2C 接口、出厂校准全部封在一个器件里，MCU 直接通过 I2C 读寄存器，得到的就是经过芯片内部校准的温度数据。对嵌入式项目来说，最大的好处是省掉了模拟链路里一堆不确定性，两路之间的一致性也远比 NTC 好。

1.3 PIC32MX675F256L 在这套方案里承担什么

选 PIC32MX675F256L 倒不是因为它有多强的算力，而是它的外设组合很合适：硬件 I2C 模块可以直接挂 PJ85718DM，ADC 内部有温度指示通道可以做本地参考，UART 可以把两路温度上报给上位机或楼宇自控网关。256KB Flash 对存储标定参数、历史温度记录、控制策略绰绰有余。

另一个实际原因是可靠性。PIC32MX 系列跑 MIPS 内核，工业级温度范围，抗干扰能力比普通 8 位机强一大截。HVAC 电控箱里继电器通断、风机启停，电磁环境并不友好，主控的容错性值得多花一点成本。

2. 硬件连接：I2C 总线怎么把传感器送进风道

2.1 引脚分配与传感器从机地址

PIC32MX675F256L 的 64 脚封装上有多组 I2C 引脚，我这边用 I2C1 挂 PJ85718DM，ULART 留作调试和上报。具体引脚编号看板子的原理图和器件手册，SCL 和 SDA 一对线直接拉到传感器模块的对应引脚即可。

PJ85718DM 这类器件一般带地址选择脚，常见的是 A0/A1/A2 三根脚。全部接地时，7 位从机地址通常落在 0x48 附近。这个地址决定了 I2C 总线上的写字节和读字节：

这个细节最容易翻车。很多人把"0x48"直接填进写函数，结果地址发出去是 0x48，从机根本不认。I2C 地址字节最低位是读写方向位，发送时必须左移一位，读操作还要把最低位置 1。

2.2 上拉电阻、线缆长度和供电去耦

I2C 总线是开漏结构，SCL 和 SDA 必须有上拉电阻。短距离测试板之间用 4.7kΩ 问题不大，但传感器要拉进风道，线缆长度超过半米后，总线电容上升，建议把上拉降到 2.2kΩ，同时把通信速率从 400kHz 降到 100kHz 甚至 10kHz。

我做第一版时偷懒直接用了现成开发板上的 4.7kΩ，线长 1.2 米，结果波形上升沿软得像一条抛物线，偶尔整个总线卡死。后来换成 2.2kΩ 上拉、100kHz 速率、双绞线传输，才算稳定。线缆如果超过两米，老老实实考虑转 RS485 或者单独做传感器子板，不要硬扛 I2C。

供电方面，传感器模块要就近放一颗 0.1μF 陶瓷电容，如果传感器和主控之间电压有落差，还要在传感器端加一颗低压差稳压器。风道里的风机一起动，供电电压瞬间波动，去耦电容能挡住大部分干扰。

2.3 本地温度：PIC32 内部温度指示器的接法

本地温度我直接用 PIC32MX675F256L 内部温度指示器，不需要额外接传感器。不过必须说清楚：这个通道量的是芯片结温，不是 PCB 表面温度，CPU 负载一高、主频一拉，读数会明显上涨。所以它更适合做"主控板有没有过热"这类保护判断，不适合做高精度的环境温度采样。

如果你的项目要求本地温度也精确到 ±0.5°C，更稳的做法是在板上给 MCU 旁边贴一颗 PJ85718DM，让本地和远程使用同一型号传感器，这样两路的误差方向一致，控制逻辑更好写。内部温度指示器就当第二道保护使用。

3. 驱动与换算：PIC32MX675F256L 读取 PJ85718DM 的完整代码

3.1 I2C 外设初始化

PIC32MX 的老用户一般已经习惯用寄存器操作，代码也好维护。假设外设总线时钟 40MHz，目标通信速率 100kHz，初始化如下：

#define FPB 40000000UL #define I2C_CLOCK 100000UL #define PJ85718DM_ADDR 0x48 // I2C1 波特率寄存器计算：BRG = (FPB / (2 * I2C_CLK)) - 1 #define I2C1_BRG_VALUE ((FPB / (2UL * I2C_CLOCK)) - 1UL) void i2c1_init(void) { I2C1CON = 0; // 先关闭 I2C1BRG = I2C1_BRG_VALUE; // 写波特率 I2C1CONbits.ON = 1; // 使能 I2C1 I2C1CONbits.SCLREL = 1; // 释放 SCL }

如果你用的是 Harmony 或者 PLIB，本质也是设定这几个寄存器，只是封装了一层。我建议至少能在寄存器层面看懂I2C1BRG和I2C1CON，排查总线问题时能省很多时间。

3.2 读温度寄存器的时序

PJ85718DM 这类传感器的标准读取流程是：先发设备地址加写位，再发要读的寄存器地址，然后发起重复起始条件，改发设备地址加读位，最后连续读两个字节。代码如下：

static void i2c1_write_byte(uint8_t data) { I2C1CONbits.SEN = 1; // 启动条件 while (I2C1CONbits.SEN); I2C1TRN = data; while (I2C1STATbits.TRSTAT); I2C1STATbits.ACKSTAT = 1; // 清零 ACK 状态 while (I2C1STATbits.ACKSTAT); // 等待 ACK I2C1CONbits.PEN = 1; // 停止条件 while (I2C1CONbits.PEN); } static uint8_t i2c1_read_byte(int ack) { I2C1CONbits.RCEN = 1; while (!I2C1STATbits.RBF); uint8_t data = I2C1RCV; if (ack) { I2C1CONbits.ACKDT = 0; } else { I2C1CONbits.ACKDT = 1; } I2C1CONbits.ACKEN = 1; while (I2C1CONbits.ACKEN); return data; } uint16_t pj85718_read_temp_raw(void) { // 配置寄存器也要按数据手册初始化，这里假设已经设置好 12 位分辨率 uint8_t reg = 0x00; // 温度寄存器地址 uint8_t msb, lsb; I2C1CONbits.SEN = 1; while (I2C1CONbits.SEN); I2C1TRN = (PJ85718DM_ADDR << 1) | 0; // 写地址 while (I2C1STATbits.TRSTAT); I2C1TRN = reg; // 写寄存器指针 while (I2C1STATbits.TRSTAT); I2C1CONbits.RSEN = 1; // 重复起始 while (I2C1CONbits.RSEN); I2C1TRN = (PJ85718DM_ADDR << 1) | 1; // 读地址 while (I2C1STATbits.TRSTAT); msb = i2c1_read_byte(1); // 第一个字节回 ACK lsb = i2c1_read_byte(0); // 最后一个字节回 NACK I2C1CONbits.PEN = 1; // 停止条件 while (I2C1CONbits.PEN); return ((uint16_t)msb << 8) | lsb; }

3.3 原始码换算成摄氏度并做符号处理

温度寄存器的数据格式各家略有差别，但主流做法是 16 位寄存器里左对齐放 12 位温度数据，低 4 位为 0。每个 LSB 对应 0.0625°C，也就是 1/16°C。负数温度用二进制补码表示。

float pj85718_raw_to_celsius(uint16_t raw) { int16_t val = (int16_t)raw; // 强制有符号 val = (val >> 4); // 去掉低 4 位 return val * 0.0625f; }

重点在于：先把原始值转成int16_t再做右移，这样负温度才能正确扩展符号位。我见过有人直接用无符号整型右移，温度降到零下之后读数直接变成一百多度，排查了整整一个晚上。

3.4 本地温度的 ADC 读取和校准

PIC32MX675F256L 的 ADC 模块内部温度指示通道，具体通道号要查你手头这颗芯片的数据手册，不同型号不一样。读取流程就是把 ADC 切到这个通道，采样、转换、取平均值：

#define ADC_TEMP_CHANNEL 28 // 替换成你芯片手册里的实际通道号 #define ADC_SAMPLE_COUNT 32 uint16_t internal_temp_sample_avg(uint16_t count) { uint32_t sum = 0; for (uint16_t i = 0; i < count; i++) { AD1CHS = ADC_TEMP_CHANNEL; // 选择内部温度通道 AD1CON1bits.SAMP = 1; // 开始采样 AD1CON1bits.SAMP = 0; // 立即触发转换 while (!AD1CON1bits.DONE); // 等待转换结束 sum += ADC1BUF0; } return (uint16_t)(sum / count); }

出厂校准公式同样要以数据手册为准，每颗芯片出厂时会在特定存储位置写入校准字，拿那个值配合手册给出的公式换算。不建议用网上随便找的公式硬套，不同批次、不同型号的系数可能根本对不上。

4. 实测翻车记录：三条最容易踩的坑与排查链路

4.1 没有任何 ACK，总线静默

第一版样板贴完，上电，示波器看 SCL/SDA 都有波形，但 SDA 上从头到尾没有 ACK。第一反应是传感器坏了，换了一块还是一样。

后来按链路排查，发现问题出在从机地址。我想当然用了网上例程里的 7 位地址，没和实际板子上的 A0/A1/A2 电平对应。IJ85718DM 的地址脚悬空和接地效果不同，我当时把 A0 悬空了，实际地址从 0x48 变成了别的值，自然不回 ACK。

这个坑的正确排查顺序是：

1. 确认 VDD 和 GND 电压正常，传感器供电在手册范围内。
2. 用示波器量 SCL 和 SDA 的静态电平，确认上拉电阻到位。
3. 对照数据手册的地址表，结合实际板子的地址脚接法，算出真实 7 位地址。
4. 先用示波器抓一次完整波形，确认主机发出的地址字节低位的读写方向位正确。

I2C 总线上没有 ACK，大多数情况不是器件坏了，而是地址写错或者上拉缺失。别一上来就怀疑硬件损坏。

4.2 读数跳变，正负好几度

传感器读数稳定了几天，某次调试时发现远程温度偶尔瞬间跳动 3 到 5 度，几秒后又自己恢复。用示波器看 SCL 波形，发现毛刺严重，尤其是风机继电器动作的瞬间，总线被干扰得很厉害。

远程线缆从主控板拉进风道，经过继电器和风机线束附近，干扰不可避免。处理方案分成几层：

• 线缆换成双绞线，SDA 和 GND 绞在一起，SCL 单独走屏蔽；
• I2C 速率从 100kHz 降到 10kHz，给总线更大的噪声容限；
• 软件做中值滤波，连续读 7 次取中位数，再滑动平均；
• 在传感器电源入口加 RC 滤波，比如 10Ω 电阻加 1μF 电容。

实际测下来，最起作用的是降速和双绞线，软件滤波只是兜底。HVAC 环境里别指望 400kHz 速率，稳定比速度重要得多。

4.3 远程温度系统性偏高或偏低

还有一次是读数很稳定，但比参考温度计低了两度多。一开始以为是传感器精度问题，后来发现是传感器放在了风道出风口旁边，风机工作时的风速带走了传感器自身的热量，导致读数偏低。

这是"本地自热"和"气流冷却"共同作用的结果。数字温度传感器自身有功耗，静止空气中本来就会比真实环境温度略高；一旦放在气流里，冷却效果又会让读数偏低。方向相反，必须先弄清楚传感器的实际安装位置和散热条件。

系统性的偏差用软件修正。我的做法是：把传感器和参考温度计放到同一个封闭箱体里，等温度稳定 10 到 15 分钟，记录两个读数的差值，然后把差值作为修正偏移量写进 Flash，每次读取后加上这个偏移。这样只做一点线性偏移修正，对 HVAC 场景已经足够。

5. 温度数据如何真正参与 HVAC 控制

5.1 双路温控策略，别让两路打架

有了两路温度之后，最忌讳的是控制逻辑里两路都拿来做主控，一会儿按这个一会儿按那个。我的策略很直接：远程温度是控制变量，本地温度只做保护。

正常工作时，风机和阀门的启停完全以远程温度为基准。本地温度超过某个阈值，比如 70°C，说明电控箱散热出问题，不论远程温度多少，强制让风机全速运行，同时上报故障。

5.2 用迟滞避免继电器频繁吸合

空调也好、风机盘管也好，继电器频繁吸合是大忌。我在代码里用迟滞控制，目标温度 25°C，回差 1°C：

float remote_temp; float local_temp; uint8_t fan_state = 0; #define TARGET_SETPOINT 25.0f #define HYSTERESIS 1.0f #define LOCAL_OVERTEMP 70.0f for (;;) { remote_temp = pj85718_raw_to_celsius(pj85718_read_temp_raw()); local_temp = sample_local_temp(); if (remote_temp > TARGET_SETPOINT + HYSTERESIS) { fan_state = 1; // 强制开启 } else if (remote_temp < TARGET_SETPOINT - HYSTERESIS) { fan_state = 0; // 保持关闭 } if (local_temp > LOCAL_OVERTEMP) { fan_state = 1; // 本地过热兜底 report_fault(FAULT_OVERTEMP); } }

迟滞的关键在于：开启和关闭的触发点不一样，避免温度在设定点附近抖动导致继电器在一个周期内反复动作。远程温度的热惯性本来就大，加上迟滞后系统会稳定很多。

5.3 简单上报帧设计

HVAC 项目一般还要把温度数据上报给上位机或者楼宇自控网关。串口上报帧不用做得太复杂，关键是定长、可校验、能区分通道：

typedef struct { uint8_t header; // 0xAA uint8_t dev_id; // 设备 ID int16_t remote_temp; // 0.01°C 精度 int16_t local_temp; // 0.01°C 精度 uint8_t status; // 位标记：传感器故障、本地过热等 uint8_t crc; // 简单 CRC8 } temp_report_frame_t;

上报周期我习惯设 1 秒一次。换算成 0.01°C 精度后，20000 就代表 200°C，能覆盖大部分工业温度范围，负数用补码表示。

5.4 传感器故障时怎么兜底

数字传感器也会失效，最常见的是 I2C 无应答或读数锁死在某个极端值。我在代码里维护一个"连续无效计数"，读到无效值或超出合理范围（比如 -40°C 以下或 125°C 以上）就加一，连续三次无效直接判传感器故障，切换到本地温度作为控制参考，并向上位机报告故障位。

HVAC 控制有个基本原则：传感器失效时，设备宁可继续运行也不要停机不动作。风机长期不转比风机一直转后果更严重，所以故障时我的默认动作是"按保护模式全速运行"而不是"关掉一切"。

6. 收尾经验：校准、功耗与多点位扩展

6.1 一阶两点校准，比单点偏移更稳妥

前面说的单点偏移修正，适合要求不高的风机盘管控制。如果设备精度要求更高，我会做两点校准：分别在 10°C 和 40°C 附近用恒温箱稳定半小时，得到增益和偏移两个系数，然后套用线性修正。

校准的要点是传感器必须和参考温度计放在同一热场里，开箱换温时等足够长时间。我这边吃过教训，恒温箱温度刚到设定值就急着读数，传感器和温度计响应速度不一样，校准完反而把误差放大了。

6.2 降低功耗和更新频率

嵌入式设备如果靠电池供电，PJ85718DM 这类传感器一般支持单次转换模式。平时处于关机状态，需要读温度时发一条命令触发单次转换，等待几十毫秒再读结果，平均电流能压到很低。

PIC32MX 本身也有 idle 模式，两路温度每秒读一次足够。实测下来，设备大部分时间在 idle，功耗比一直跑主循环低一个数量级。

6.3 多传感器扩展：地址脚是最大的网格

如果项目要扩展到多个点位，PJ85718DM 的地址脚就能派上用场。A0/A1/A2 组合出最多 8 个不同地址，一根 I2C 总线上最多挂 8 路。楼宇自控里常见的做法是：主控板旁边挂 1 路本地温度，风道里挂 2 到 3 路远程温度，分别覆盖回风、送风、室外温度，控制逻辑会丰富很多。

多路读取时要注意缩短每路的转换周期，避免同一总线上设备太多导致时序紧张。我记得第一版挂 4 个传感器时，总线负载明显上升，后来把速率降到 50kHz 才稳定。

这套方案前前后后调了两个多月，最深的体会是：数字温度传感器的优势在于把"准"这件事提前做掉了，但"能不能可靠地把数据送到 MCU"这件事，还是得靠硬件设计和软件容错来保证。如果你正在做类似的 HVAC 温控项目，建议先从短距离、单传感器跑通整条链路，再慢慢往风道里拉线。稳定可靠地测出两路温度，控制策略才有发挥的空间。