企业官网建设流程全解析

最近在做一个嵌入式温控项目，涉及 HVAC 风柜的多点温度采集，选型时盯上了PJ85718DM这颗热管理芯片，配STM32F723IE做主控。折腾下来发现这对组合在“本地测温 + 远程测温”双通道方案上非常顺手，既解决了单点温度传感器的布线局限，又不需要额外引入复杂的桥式电路或者高精度运放，很适合嵌入式和暖通场景。这篇就把整个项目的设计思路、电路接法、驱动实现和踩过的坑完整梳理一下，给正在做类似项目的朋友一个可以照抄的参考。

项目核心其实不复杂：HVAC 和很多嵌入式系统要求同时监测设备内部温度和环境远端温度，比如风道里的送风温度、回风温度，或者机柜内外的温度对比。传统的做法是布设多个独立传感器，每路单独拉线、单独采集，成本高不说，线缆一长还会引入误差和 EMC 干扰。PJ85718DM 的思路不一样，它一颗芯片自带本地测温通道，同时支持外接二极管做远程测温，一颗芯片就能读两路温度，配合 STM32F723IE 的丰富外设接口，硬件布线瞬间简化了一大截。这篇文章会从方案选型、硬件设计、驱动编写到实际调试逐一展开，特别适合正在做嵌入式温控、HVAC 控制器或者工业设备热管理的小团队和独立开发者参考。

1. 芯片选型背后的逻辑：为什么是“本地 + 远程”双通道

1.1 嵌入式测温的痛点远不止“读个数”

很多刚接触温度采集的朋友会觉得这事简单——找颗 I2C 温度传感器，STM32 读个寄存器，搞定了。但真到 HVAC 和嵌入式实际工程里，会碰到几个绕不开的现实问题。

第一个是测点位置和主控距离的问题。风道里的送风温度探头离控制板往往好几米远，模拟电压输出型的传感器线缆一拉长，压降和干扰就都来了。第二是测点数量问题，至少要有送风、回风、混风三个点，有些场合还有盘管进出口温度，每个点放一颗数字传感器，BOM 成本和 PCB 面积都受不了。第三个问题比较隐性——维护。HVAC 设备常年运行，传感器探头坏掉是常态，如果每路都单独可插拔、单独接线，现场维护的人会疯掉。

PJ85718DM 这类带远程测温功能的芯片，核心价值就在这里。它利用二极管正向压降随温度变化的特性，通过一颗普通的三极管 MMBT3904 或者干脆用芯片内置的二极管模型做远端测温。一颗芯片、一根双绞线加一个便宜的三极管，就能把测温点从 PCB 上“搬运”到几米外的任意位置，同时芯片自己还能测量板载温度，恰好覆盖“本地 + 远程”两个需求。

1.2 PJ85718DM 和 STM32F723IE 的匹配度分析

选择 STM32F723IE 而不是更常见的 F103，主要有三个原因。

其一，F723 主频高达 216MHz，带硬件 FPU，做温度算法、PID 控制和后期可能加上的 Modbus 协议转换都绰绰有余，不会出现 F103 那种跑个浮点运算就要精打细算的窘境。其二，F723 的 I2C 外设经过改进，支持最高 1MHz 的快速模式 Plus，和 PJ85718DM 高速通信完全匹配，采集速率可以做到非常激进，实话说大部分项目根本用不满。其三，F7 系列有充足的 DMA 通道和多路 UART，后续要把温度数据转发给触摸屏、楼宇自控主机，或者通过 WiFi 模块上传，都留足了接口余量。

PJ85718DM 这边，它的特点是单芯片集成度高、功耗低、精度尚可。本地通道典型精度是 ±0.5°C 以内（0~70°C 范围内），远程通道在理想条件下也能做到 ±1°C 左右，对 HVAC 场景完全够用。芯片还内置了温控阈值报警，可以设定上限下限，温度超限直接拉 ALERT 引脚，不用 MCU 轮询，对嵌入式系统中断响应的场景非常友好。这两个芯片放一起，硬件上基本就是“一颗主控 + 一颗传感”，干净利落。

提示：远程测温用的三极管非常重要，建议选 MMBT3904 这种小信号三极管，把 B 极和 C 极短接，使用 BE 结作为测温二极管。不要随意换成其他型号，不同三极管的 Vbe 温度曲线系数差别会导致读数偏差明显，后面实测部分我会细讲。

2. 硬件设计：电路连接与关键参数计算

2.1 引脚说明与最小系统接线

PJ85718DM 的封装不大，常用的是 8 脚的 MSOP 或者 SOIC，引脚排布比较典型。我用的这颗是 I2C 接口版本，地址默认是 0b1001100（7 位地址），用 ADDR 引脚可以改。核心引脚有这几个：

STM32F723IE 这边我用的是 I2C1 外设，PB6 作为 SCL，PB7 作为 SDA。上拉电阻的选择需要算一下。I2C 快速模式要求上升时间不超过 300ns，总线电容取典型值 50~100pF，上拉电阻经验值 4.7kΩ 就能满足。但测过之后发现，如果总线线缆较长（超过 30cm 排线），建议用 2.2kΩ，否则上升沿会明显变缓，高速通信时容易出 ACK 错误。

打个比方，I2C 总线上拉电阻就像给水管道提供水压的泵。电阻太大，管子里冲水慢，信号上升沿就软绵绵的；电阻太小，灌水太快，又可能超出器件的灌电流能力。4.7k 适合板内短距离，2.2k 适合跨接排线。

// I2C1 引脚初始化（STM32CubeMX 配置后） void MX_I2C1_Init(void) { hi2c1.Instance = I2C1; hi2c1.Init.Timing = 0x10D2CE7F; // 400kHz Fast Mode hi2c1.Init.OwnAddress = 0; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE; hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; HAL_I2C_Init(&hi2c1); GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); __HAL_RCC_I2C1_CLK_ENABLE(); GPIO_InitStruct.Pin = GPIO_PIN_6 | GPIO_PIN_7; GPIO_InitStruct.Mode = GPIO_MODE_AF_OD; // 开漏复用 GPIO_InitStruct.Pull = GPIO_PULLUP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; GPIO_InitStruct.Alternate = GPIO_AF4_I2C1; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); }

2.2 远程二极管接法与线缆长度影响

远程测温的原理是芯片向 D+ 和 D- 施加一个恒定的偏置电流（通常是 6μA 和 120μA 交替），然后测量二极管 Vbe 的变化来推算出绝对温度。因为 Vbe 和温度之间是近似线性的关系（约 -2mV/°C），芯片内部的 ADC 把这个模拟量转换成数字量。

实际接线时有一个很容易犯的错误：远程二极管的正负端搞反。D+ 必须接三极管的 B 极，D- 必须接 E 极。接反了读数会直接偏掉几十度，而且芯片的报告值往往是一个很离谱的负数，排查时要先想到这个。

线缆长度方面，实测下来使用屏蔽双绞线最长能拉到 5 米左右，读数仍然稳定。再长就需要注意了，因为线缆本身的电阻会串联到测量回路中，导致 Vbe 变大，最终表现为温度偏高。对此常规做法是“抵消电阻”——把 D- 端的线阻减掉。不过 PJ85718DM 这类芯片一般不带自动线阻补偿，需要软件上做修正，这个我在驱动部分会给出具体思路。

硬件上还有一个细节：远程三极管附近不要安排发热量大的元件，尤其是大的功率电阻和 LDO。三极管自身温度就代表了被测点温度，芯片测量的是 BE 结的温度，如果旁边有热源，等于测出来的温度带了脏数据。HVAC 风道场景一般还好，如果是机柜内测量，探头要尽量远离电源模块。

3. 驱动代码与数据处理的完整实现

3.1 寄存器地图与读取流程

PJ85718DM 内部寄存器在设计上很直白，沿用热管理芯片常见的布局。我用到的关键寄存器如下：

读取流程不复杂，单个温度寄存器直接给芯片发一个字节地址就能读回来。温度值是 11 位或者 12 位带符号格式，左对齐存放在两个字节中。比如寄存器 0x00 读两个字节，将高字节和低字节拼起来，右移 3 位或者 4 位得到实际的 11/12 位码，再乘以 LSB 值就得到摄氏度。

// 读取本地温度，返回 float 摄氏度 float pj85718_read_local_temp(void) { uint8_t reg_addr = 0x00; uint8_t buf[2] = {0}; int16_t raw; float temp; HAL_I2C_Master_Transmit(&hi2c1, PJ85718_ADDR, &reg_addr, 1, 100); HAL_I2C_Master_Receive(&hi2c1, PJ85718_ADDR, buf, 2, 100); raw = (buf[0] << 8) | buf[1]; raw >>= 4; // 取 12 位有效位 temp = raw * 0.0625f; // 12 位模式 LSB = 0.0625°C return temp; }

3.2 远程温度的读取与软件校准

远程温度寄存器的读取方式有差异。芯片内部有一个 ΔADC，专门测量 D+、D- 之间的电压变化，最终输出的是一个带符号的温度值。基本读取流程和本地类似，但要注意远程通道有两个关键校准点。

第一个是偏移校准。我在实际测试中发现，远程通道存在一个相对固定的系统偏差，通常在 +0.5~1°C 左右。这个偏差在出厂时芯片手册会给出一个典型值，但每颗芯片之间离散性不大。一个省事的做法是在 25°C 恒温环境下用高精度水银温度计或者商用数字温度计做基准，测出偏差值，然后把这个值存到 MCU 的 NVM 中，每次读取后补偿。校准公式极简：

float remote_temp = raw_temp + offset_calibration;

第二个是线阻修正。当远程二极管离主控板距离超过 1 米时，双绞线的铜阻会带来误差。线阻对温度读数的影响不完全是线性的，但近似估算经验值是：1Ω 的串联电阻大约造成 0.5°C 的正偏差。要精准修正就比较麻烦了，需要用二极管的串联等效电阻模型做反推，但 HVAC 应用要求没那么高，按经验值估也算够用。

// 远程温度读取：带线阻估算补偿 float pj85718_read_remote_temp_with_compensation(float cable_r_ohm) { uint8_t reg_addr = 0x04; uint8_t buf[2] = {0}; int16_t raw; float temp; HAL_I2C_Master_Transmit(&hi2c1, PJ85718_ADDR, &reg_addr, 1, 100); HAL_I2C_Master_Receive(&hi2c1, PJ85718_ADDR, buf, 2, 100); raw = (buf[0] << 8) | buf[1]; raw >>= 3; // 不同芯片可能取 11 位或不同对齐位，需按手册确认 temp = raw * 0.125f; // 线阻补偿：1Ω 约对应 +0.5°C 偏差，减去即可 temp -= cable_r_ohm * 0.5f; return temp; }

从工程角度看，远程温度的高阈值报警用得非常频繁。HVAC 控制器经常要求在送风温度过高时自动停止电加热器，这个逻辑放在传感器芯片内部完成比 MCU 软件判安全得多——即使主控跑飞了，硬件报警引脚还能独立拉闸。配置远程报警阈值时，直接写两个字节到 0x02 和 0x03 寄存器即可，ALERT 引脚就跟随报警状态变化了。

// 设置远程温度报警阈值 void pj85718_set_remote_alarm(float high_threshold, float low_threshold) { uint8_t data[3]; uint8_t raw; // 高阈值写入 0x02 raw = (uint8_t)(high_threshold / 0.125f); data[0] = 0x02; data[1] = raw; HAL_I2C_Master_Transmit(&hi2c1, PJ85718_ADDR, data, 2, 100); // 低阈值写入 0x03 raw = (uint8_t)(low_threshold / 0.125f); data[0] = 0x03; data[1] = raw; HAL_I2C_Master_Transmit(&hi2c1, PJ85718_ADDR, data, 2, 100); }

3.3 数据滤波与单位换算的工程细节

直接读到的浮点温度能直接用吗？噪声和瞬时波动会让人抓狂。HVAC 系统中，风道里的温度探头受到气流扰动，读数会有 ±0.2°C 左右的快速抖动。为了不把这种抖动带到 PID 控制器里，需要做滤波。

常用的是一阶低通滤波（指数滑动平均），代码只要两行：

float filtered_temp = 0; void update_temp_filter(float new_sample) { // 系数 a 根据采样周期和环境时间常数调整，默认 0.2 适合 1Hz 采样 filtered_temp = filtered_temp + 0.2f * (new_sample - filtered_temp); }

滤波系数 a 的取值不能太激进。空调系统温度变化本来就慢，如果 a 设成 0.05，响应会迟滞很多，电加热器动作滞后反而容易超调。我项目里用的是 1Hz 采样频率和 0.2 系数，实测下来送风温度变化 3°C，滤波跟随时间约 5 秒，这已经够了，因为 HVAC 的温度变化本身不是秒级的事。

注意：在设备调试阶段就别开滤波了，原始数据直读反而方便定位问题。等到现场实测调参完再把滤波加进去，否则滤完的数据会掩盖传感器本身的异常行为，增加查错难度。

4. 工程化落地：RTOS 集成与低功耗策略

4.1 多任务架构下的传感器调度

如果项目是裸机循环，直接在主循环里轮询即可。但这次 STM32F723IE 上跑的是 FreeRTOS，温度采集要作为独立任务。任务优先级的设计有讲究：温度采集任务的优先级不需要设太高，因为它没有强实时性要求，但报警处理必须及时。

我实际采用的调度方案是：温度采集任务每 500ms 做一次采样、滤波和告警判断，优先级设在中低档；报警响应任务通过事件标志组唤醒，一旦 PJ85718DM 的 ALERT 引脚触发了外部中断，中断服务函数直接置位标志位，报警任务立刻启动停机流程，优先级最高。这样分层处理既不影响其他任务（比如人机界面刷屏、Modbus 轮询），又能保证紧急事件的快速响应。

// 温度采集任务主体（FreeRTOS） void temp_monitor_task(void *param) { (void)param; for (;;) { float local = pj85718_read_local_temp(); float remote = pj85718_read_remote_temp_with_compensation(0.1f); filtered_local = local * 0.2f + filtered_local * 0.8f; filtered_remote = remote * 0.2f + filtered_remote * 0.8f; vTaskDelay(pdMS_TO_TICKS(500)); } }

任务通信不建议直接共用全局变量裸奔，用一个简单的结构体加互斥锁能避免很多奇怪的问题。如果追求极限性能，F723 支持原子操作或者关临界区保护临界资源，但温度数据本身不是高速变量，互斥锁的开销完全可以接受。

4.2 通信协议扩展与诊断接口

很多 HVAC 项目最终都要把温度数据汇到楼宇自控系统（BAS）或者触摸屏上。F723 上的多路 UART 除了给调试口用，留一路给 Modbus RTU 从站是个很理想的设计。Modbus 的寄存器映射可以这么定义：

用 0.01°C 作为分辨率是为了避免浮点在 Modbus 报文传输中的字节序问题。MCU 内部怎么用浮点都行，但发出去给上位机就统一换算成整数，双方都清爽。

另外，我在调试阶段还往代码里塞了一个辅助诊断功能：把最近 32 次原始采样值和滤波值打包存到一个环形缓冲中，通过调试串口命令触发导出。遇到现场环境恶劣、间歇性出现异常读数的情况，这个功能帮了大忙——不用接仿真器也能离线分析数据波形，非常推荐大家尝试。

5. 实测数据与踩坑记录

5.1 风道测温测试结果

搭建测试环境时用了模拟风道：一个 1 米长的方形风管，一台变频风机，风道内放置远程探头（MMBT3904 探头），PJ85718DM 和 STM32F723IE 的主控板放在风道外约 2 米处。给电加热器设定了不同的功率档，让送风温度从 20°C 上升到 45°C，再自然回落，记录传感器读取值和参照温度计读数。

实测结果挺好，稳定状态下本地通道和参考温度计差值在 ±0.3°C 以内，远程通道差值在 ±0.8°C 以内。在加热上升沿，远程通道响应速度比想象中快，铝合金探头外壳让热传导很顺畅，并没有出现明显的滞后。数据记录如下：

远程通道整体偏高了约 0.4°C，和我前面说的线阻修正补偿正好吻合。精度对 HVAC 来说绰绰有余，毕竟普通恒温器控温精度也就 ±1°C。

5.2 实际踩过的几个大坑

第一个坑是地址冲突。板子上初始设计有两片 PJ85718DM，我以为都默认地址就行，结果 I2C 通信时好时坏。排查半天才发现第二片芯片的 ADDR 引脚悬空了，和第一片一样都是默认地址，总线上的两个从机地址发生了冲突。解决办法是用 10kΩ 电阻把第二片 ADDR 接到 VDD 上，改成备用地址，通信立刻稳定。所以多片同型号芯片时一定记得逐片设置不同地址。

第二个坑是远程二极管引脚误当作普通 GPIO 去驱动。调试时为了省事，直接把 D+ 引脚代码里复用成 GPIO 输出，想把探头当开关用，结果后面改回传感器模式后读数怎么都不对，老是偏大十几度。手册上虽然没强调，但远程测温引脚对接入源的阻抗很敏感，代码切换前后务必确保没有任何残余的推挽输出状态。

第三个坑比较隐蔽：ALERT 引脚中断触发优先级与设备误停机。初始配置了一个中优先级的外部中断，结果有一次现场电压波动引发瞬时干扰，ALERT 信号误触发，把压缩机直接停了。后来改成在中断服务函数里只置标志位、在主循环里连续确认三次（每次间隔 50ms）才执行停机动作，彻底解决了误动问题。调试经验就是：涉及到停机动作的报警，软件上一定要加确认次数，硬件上可以并一个小电容做滤波。

6. 几个实用的后续扩展方向

这套本地 + 远程的方案做完之后，我又尝试了一些扩展玩法，效果不错，分享出来供参考。

PJ85718DM 的报警阈值能力配合 F723 的 DAC 或者 PWM，可以做个纯硬件的温度风扇调速器：远程温度高于设定值时，MCU 输出对应占空比控制风扇，温度降下来再缓缓减速，比继电器开关温控舒服得多。结合 F723 的以太网或者 WiFi 模块，把两路温度数据定期上报到云平台，做设备远程监控和故障预测，这套硬件超低功耗跑一个月没问题。

如果精度要求更高，可以考虑针对远程通道做多段校准。实测下来，不同温度段的偏差不完全一致，30°C 以下偏差偏正，50°C 以上偏差偏负。用一个简单的分段线性插值表代替单一固定补偿值，可以把远程通道的最大误差从 ±0.8°C 压到 ±0.4°C 左右。这个方案我后来用在了另一个项目中，效果很满意。

最后分享一个我的个人经验：硬件设计时给远程温度通道留一个 0Ω 电阻位，用来切换二极管连接方式（三极管接法还是二极管接法），现场调试遇到温度异常时就可以快速换接法验证。这种小细节看似不起眼，真到排查问题的时候能节省大量时间。温度监测从来不是方案越复杂越好，选对芯片、做好校准、留足调试余地，比堆算法和堆硬件都管用。