企业官网建设流程全解析

年前调一块暖通控制器板卡的时候，温度采集方案折腾了我好几轮。主控选的是STM32L152RE，传感器环节最开始想用NTC加比较器自己做，后来换成PJ85718DM这颗“本地加远程”双通道温度传感器，整个方案清爽了很多：一颗芯片同时盯控制板自身的温度和风管远端测点温度，I2C直接读回数字量，省掉了大量模拟前端，标定和量产一致性也更好处理。这篇文章就把整个项目的选型思路、电路设计、驱动实现、现场标定和踩坑过程完整写出来，给正在做嵌入式或HVAC类温度监测方案的朋友做个参考。

1. 项目背景：暖通控制器里为什么会有两个测温通道

1.1 应用场景拆解

HVAC系统里的温度测点，远不止面板上显示的那个室温。我手头这个项目要同时采集几类温度：

• 风管送风温度，装在风管内部，用来判断风机盘管出风是否正常；
• 换热盘管表面温度，直接贴到盘管翅片或铜管上，判断冷媒状态；
• 控制盒内部环境温度，用来防止元器件超温；
• 功率器件附近温度，大功率继电器或者驱动MOS管旁边的板温，作为过热保护依据。

这些测点的特点各不相同。风管内的温度变化很慢，秒级甚至分钟级才有明显变化；盘管表面温度受冷媒启停影响，几分钟内可能波动好几度；板级温度则跟负载和机箱散热直接相关，需要及时响应。如果每个测点都放一颗完整的数字温度传感器，不仅成本翻倍，PCB面积和走线资源也吃不消，有些空间非常紧凑的位置甚至塞不下一颗SOT-23封装的芯片。

用“本地加远程”双通道方案就顺了：传感器芯片本体放在控制板上，本地通道测芯片附近空气或板温，远程通道通过一对细线把外部二极管延伸到远端测点，芯片基于二极管的电压温度特性换算那一小片区域的温度。这样一颗芯片解决本地和远端两个测点，而且远端只增加一个廉价二极管，连供电都不需要，非常适合多出分散测点的HVAC应用。

1.2 本地与远程测温的原理区别

本地通道本质上测的是芯片内部PN结的结温，芯片会通过内部ADC把电压信号转换成数字量，我们读到的是直接可用的温度值。

远程通道原理上有意思得多。它测的是外部二极管在不同电流激励下正向压降的差值，也就是业内常说的ΔVbe测温。为什么不用单个Vbe值直接换算？因为Vbe本身携带太多与温度无关的干扰因素：二极管反向饱和电流的工艺偏差、串联电阻、漏电流，甚至封装应力都会让绝对电压漂移。但如果用两个不同大小的电流分别测量Vbe，再把两个读数做差，那些与材料工艺相关的公共项会被消掉，剩下的量基本只跟玻尔兹曼常数、电荷量和绝对温度相关，线性度非常好。

用生活化的方式理解：就像量地面到屋顶的高度，先拿卷尺量一次，再换根绳子吊着量一次，两个数值相减，你就不用关心地面本身平不平了。ΔVbe测温也是这个道理，它把二极管个体差异的影响压得很低。这就是远程二极管测温能跨批次保持一致性好的根本原因。

1.3 全局数据流向

PJ85718DM和STM32L152RE之间走I2C总线，两个通道的温度值都放在芯片内部的寄存器里。主控STM32L152RE负责做初始化、定时读取、阈值判断和对上级系统上报；PJ85718DM则始终工作在“模拟信号变数字量”的角色上。主控可以大量时间待在低功耗模式，传感器越限时通过ALERT脚拉低来唤醒MCU，这个机制对无人值守的HVAC控制器来说非常实用。

整条数据链路并不复杂：远程二极管或者本地结温 → 芯片内部调制和ADC → I2C寄存器 → STM32L152RE读取并处理 → LCD显示与通信上报。复杂度主要在驱动细节和标定，下面一个个说。

2. 硬件选型思路：PJ85718DM 和 STM32L152RE 各自承担什么角色

2.1 为什么选PJ85718DM而不是一堆单点温度传感器

单点数字温度传感器不是不能用，问题是每多一个测点，就要多一路I2C设备地址、多一颗芯片的供电和去耦。地址引脚数量有限，挂多了还得加I2C开关或改用SPI，系统复杂度很快就上去了。

PJ85718DM这类本地加远程芯片，一颗设备地址只占一路，却同时拿到了本地温度和一路远端温度。如果项目有几个分散测点，我当时的做法很直接：板上放两颗PJ85718DM，地址引脚分别拉高拉低错开，一颗测控制板本地和风管送风，另一颗测驱动器件附近和盘管表面。I2C总线上地址逻辑清晰，每颗芯片独立报警，一颗出问题不会影响另一路。远程测点本身不带电源、不带芯片、不带地址概念，结构上就是一对线加一颗二极管，方便程度在维修和线束布置上体现得非常明显。

2.2 STM32L152RE的低功耗和外设正好匹配

STM32L152RE属于超低功耗L1系列，Cortex-M3内核，最高主频32MHz。对于温控器这类任务，温度刷新周期是秒级，主控完全不需要一直满频跑。L系列的优势在于多种低功耗模式之间切换的快和稳：从停止模式恢复到运行只需要微秒级的时间，这让“频繁小睡、醒来干一点活再睡”的架构变得可行。

真正让我选它的还有两个细节。一个是它自带LCD段码屏控制器，HVAC控制器面板上要显示温度、风机档位、模式，段码屏是成本最低、阳光下最好读的方案，省掉一颗外部显示驱动芯片，BOM成本下降不少。另一个是它的I2C外设成熟稳定，接PJ85718DM这类最高工作在400kHz的芯片完全没压力。板子上还要留几个备份I/O做按键扫描和故障灯控制，L152RE的引脚资源也够。

2.3 省掉模拟前端和查表标定

用NTC方案最痛苦的环节不是算分压电阻，而是每一条产线都要做温度标定。同一批100kΩ NTC，在25℃附近个体差异就能差出好几度，想要±0.5℃的精度，每个探头都要单独校准并在固件里放校准表。这对于小批量产品来说工作量不小。

PJ85718DM这类芯片把模拟放大、ADC转换和线性化都封装好了。我只需要用I2C读取已经换算好的温度值，再针对远程二极管的理想因子偏差做一次小范围补偿就行。批量生产时一般只需要抽检，不用逐台校准，这在产线上是实实在在省时间。

有个关键提醒：选型时一定要先确认芯片支持的单次转换模式和报警中断能力，有些便宜的单通道传感器不支持外部唤醒，低功耗方案会受限。PJ85718DM在这一点上做得比较全面，至少我这颗支持的寄存器功能覆盖了项目所有需求。

3. 电路连接与PCB布局：远程二极管不是随便接的

3.1 二极管选型与极性

远程通道的核心元件是外部PN结，常见做法是选小信号三极管并把基极集电极短接，用发射极和短接端作为二极管的两极。之所以不直接用普通发光二极管或整流二极管，主要因为小信号三极管这类器件在高阻态下漏电流小，温度特性更接近传感器芯片内部的理想因子假设，误差最容易通过校准消除。

接线极性一定要和芯片手册对齐：通常D+接二极管正端，D-接负端。原理图上标注清楚，封装图上也放上极性丝印。我在初版画PCB时嫌麻烦没标D+/D-，结果贴片厂把其中一块板的二极管方向贴反，上电后远程通道读出一个-40℃左右的固定异常值，排查了半天才定位到问题，这个低级错误浪费了一整天时间。

3.2 滤波电容和输入保护

远程通道对噪声比较敏感，尤其是走线要经过端子、接插件或者较长距离时，线路上感应的高频噪声会直接叠加到毫伏级电压信号上。通常做法是在D+和D-之间加一个小容值的陶瓷电容，比如100pF到1nF，靠近二极管侧放置；在芯片侧的D+/D-引脚之间再放一个10nF到100nF的电容，起到滤波和防止射频干扰的双重作用。

电容值不是越大越好。容值太大等于给信号加了低通惯性，远程温度读数会变得迟钝，甚至在温度骤变时出现明显滞后。我在调试中试过在远端放1uF电容，结果风门从冷切换到热后，读数要将近两分钟才跟得上实测值，后来换成100pF才恢复正常。这类参数最好在目标线长和实际板卡上验证后再定。

3.3 I2C总线上拉电阻的选择

STM32L152RE的I2C引脚配置成开漏输出，SCL和SDA必须靠外部上拉电阻拉到高电平。上拉电阻阻值会影响通信速度和抗干扰能力。理论上100kHz模式下可以容忍较大的上拉阻值，但实际线缆、多个设备并联后，寄生电容会让上升沿变缓。

我踩过的坑是初始设计用了10kΩ上拉，总线上挂两个PJ85718DM，传感器离主控大概20cm，刚开始正常，样品测试时偶发读不到应答，把速率降到50kHz才稳定。后来把上拉电阻改成4.7kΩ，示波器上看波形上升沿明显变陡峭，100kHz下连续读写几百次都不再出错。HVAC控制器板内走线通常不会太长，4.7kΩ是个比较稳的起手值，如果板子特别紧凑还可以降到3.3kΩ。

3.4 板级布局和热源规避

本地通道测的是芯片周围的环境温度，可它偏偏就在发热区附近。布局时如果顺手把传感器塞到功率MOS管边上，读出来的就不是控制盒内空气温度，而是“那颗管子最近过得怎么样”。我后来把传感器放在靠近出风口的板边位置，留出空气流通空间，读数才恢复正常。

远程二极管贴到风管或盘管表面时，要确保接触面平整并适当加导热硅脂，减少接触热阻。固定方式上用卡簧或铝箔胶带都比悬空放置更可靠，因为空气层的隔热效果很明显，会直接导致读取温度低于真实壁面温度。

4. 驱动移植与数据处理：从I2C读回度数只是第一步

4.1 I2C初始化基础

STM32L152RE的I2C外设初始化流程属于常规操作：开GPIO时钟、配置SCL/SDA为开漏复用、配置I2C时钟源为合适的PCLK、设置标准模式或快速模式、使能外设。驱动层封装建议直接提供三个基础函数：写入寄存器、读取寄存器、读取多字节温度值。下面是一段示意性质的初始化代码：

void i2c1_init(void) { GPIO_InitTypeDef gpio; I2C_InitTypeDef i2c; RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE); gpio.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; // PB6=SCL, PB7=SDA gpio.GPIO_Mode = GPIO_Mode_AF_OD; gpio.GPIO_Speed = GPIO_Speed_2MHz; GPIO_Init(GPIOB, &gpio); i2c.I2C_ClockSpeed = 100000; i2c.I2C_Mode = I2C_Mode_I2C; i2c.I2C_DutyCycle = I2C_DutyCycle_2; i2c.I2C_OwnAddress2 = 0; i2c.I2C_Ack = I2C_Ack_Enable; I2C_Init(I2C1, &i2c); I2C_Cmd(I2C1, ENABLE); }

把I2C初始化放在系统时钟和GPIO配置之后，上电后可以先用逻辑分析仪抓取SCL波形，确认信号没有畸变，再去做寄存器读写。

4.2 寄存器配置要点

PJ85718DM这类芯片通用寄存器布局大致包含：配置寄存器、本地温度寄存器、远程温度寄存器、上限报警阈值、下限报警阈值以及扩展温度寄存器。具体偏移地址以实际数据手册为准，但逻辑上要注意几个点：

• 分辨率配置：通常用12位模式，LSB对应0.0625℃左右，够HVAC用；
• 工作模式：连续转换或单次转换，低功耗项目一定要支持单次模式；
• 报警阈值：高低温阈值寄存器，超限后ALERT脚输出有效电平；
• 转换率：有些芯片支持可编程转换周期，设置成4Hz或8Hz足够。

读取流程可以写成一个固定函数，先读远程温度高字节和低字节，再做符号扩展和LSB换算。以下是一个简化示例：

uint16_t read_remote_raw(uint8_t dev_addr) { uint8_t reg = PJ85718DM_TEMP_REMOTE; uint8_t buf[2] = {0}; i2c_write_byte(dev_addr, reg); i2c_read_bytes(dev_addr, buf, 2); return ((uint16_t)buf[0] << 8) | buf[1]; } float remote_temperature_c(uint8_t dev_addr) { uint16_t raw = read_remote_raw(dev_addr); int16_t signed_raw = (int16_t)raw; return signed_raw * 0.0625f; }

低字节可能只使用高4位，屏蔽掉无效位之后再参与计算，避免无意义的跳动。

4.3 转换时间与轮询节奏

HVAC温度变化慢，PJ85718DM每个通道转换时间通常在几十毫秒到几百毫秒之间，读取一次双通道数据只需要毫秒级的I2C通信时间。我在固件里设置系统每2秒唤醒一次，唤醒后触发一次单次转换，等待转换完成后读取本地和远程温度，再做软件滤波。这个节奏既保证了显示值的稳定，也不至于让总线一直被占用。

如果现场需要更快响应，比如做过热保护，可以把轮询周期压缩到200ms，但要注意传感器自热和功耗的平衡，这个后面单独讲。

4.4 滤波与防跳变

温度跳变在HVAC现场很常见，特别是风机切换、压缩机启动瞬间，读回来的原始值偶尔会跳出一两个尖峰。直接在界面上显示原始值是糟糕的体验：室温明明没变，屏幕上的数字却像打摆子一样上下抖。

我常用的滤波算法是滑动窗口中位平均：取最近9个采样值，去掉最大值和最小值，剩下的值求平均。这个算法在异常点只占少数时，既平滑又能剔除尖峰毛刺。对HVAC这种温度惯性大的场景，我实际测试下来比纯滑动平均稳得多。要注意窗口长度不能设得太大，否则温度突变时响应太慢，比如冷媒管道结霜保护会迟迟不触发。

5. HVAC现场测试与误差校正：实测数据比仿真更诚实

5.1 实验室标定方法

无论芯片声称精度多高，实际项目都要自己做一次标定验证。我每次改板或换料，都会先在恒温槽里做一轮校准。把远程二极管、参考温度计探头和待测板卡一起放入恒温槽，在0℃、25℃、50℃和85℃四个温度点分别稳定后记录芯片读数，再对比参考值的偏差。

下表是一个典型标定记录格式：

如果偏差是一个近似常数的固定偏移，直接写入偏移校准寄存器；如果偏差随着温度线性变大，就需要用两点法修正增益，也就是调整理想因子补偿寄存器。缺少恒温槽的小团队可以用保温杯加冰水、加热水做粗略验证，虽然精度一般，但能快速发现大方向性错误。

5.2 现场实测数据处理示例

现场数据最能反映问题。我在一个测试样本上记录了风机启停过程中送风温度和板内温度的变化：风机刚开启时送风温度从22.1℃缓步上升，半小时后稳定在23.8℃；控制板内部温度则从28℃缓慢爬到34℃。排除传感器后，送风温度整体响应时间大约3分钟，和系统热惯性吻合。本地通道虽然变化更快，但经过滤波后也能稳定显示。

如果现场读到的某一通道有明显周期性波动，优先怀疑两件事：一是远程走线是否与PWM电源线平行或者穿过继电器区域，二是地线回路是否形成了噪声环路。不要一上来就怀疑传感器坏掉，因为HVAC设备的电磁环境远比实验室恶劣，干扰造成的波动才是家常便饭。

5.3 误差来源分拆

我习惯把最终误差分成四块来看：传感器自身精度、远程二极管品质和走线电阻、电源纹波与地噪声、算法滤波造成的动态误差。静态标定能修正前两块的大部分，后两块要靠硬件布局和采样策略配合解决。

• 传感器自身精度：主要由芯片内部基准和ADC决定，通常可以通过校准寄存器修正；
• 远程二极管品质：更换二极管品牌后需要重新确认理想因子，一致性差的批次误差可达±1℃；
• 电源与地噪声：供电不稳会直接影响比较器和ADC，去耦电容位置不对也会引入误差；
• 动态滤波误差：窗口越长越平滑，但响应越慢，要按工况折中选择。

HVAC常规控制的精度目标建议设在±0.5℃以内，这个水平对舒适性控制已经足够。追求更高精度不是不行，而是需要对每一路远程二极管做逐点校准，并在固件里放查表，投入产出比不高。

5.4 高低温老化与断电恢复验证

HVAC设备不是一直在常温下工作。我专门跑过一轮85℃环境箱持续加电的老化测试，监控本地和远程通道的长期漂移，连续48小时读数稳定在±0.2℃范围。断电恢复测试也同样重要：模拟一次意外掉电再上电，确认芯片配置寄存器恢复默认值后，ALERT报警脚不会残留拉低状态，否则整机会出现“刚上电就被反复唤醒”的恶劣现象。

6. 低功耗调理：让整机长时间运行不失控

6.1 MCU的低功耗策略

STM32L152RE适合做低功耗温控器的原因，在于它把“待机低功耗”和“快速唤醒”做到了较好平衡。项目里我把MCU配置成周期性唤醒：大部分时间进入停止模式，每1秒由RTC或定时器唤醒一次，花几毫秒读取温度和按键状态，刷新LCD之后再回到停止模式。

整机功耗数据大致如下：

如果条件允许，RTC唤醒周期可以加长到2秒，整机平均电流还能再往下压。对不带显示的物联网节点场景，这个优势会进一步放大。

6.2 采样模式对自热的影响

PJ85718DM这类芯片在连续转换模式下，内部会持续工作，芯片自身温度会比环境略高。我实测连续转换和单次转换两种模式下，本地通道读数可以相差大约0.2℃。对恒温控制来说，0.2℃不是可以忽视的小数，尤其HVAC目标温度精度通常在0.5℃之内。

因此我在软件里采用“按需转换”：MCU唤醒后写一次单次转换命令，等待转换完成标志置位，读出温度后立刻关闭转换。这样传感器90%以上的时间处于空闲状态，自热被压到最低，本地读数的可信度也提高不少。远程通道同样受益，因为芯片内部差分测量电路的零点漂移会随时间变小。

6.3 报警唤醒的红利

把PJ85718DM的ALERT引脚接到STM32L152RE的外部中断输入，温度越限时可以直接把MCU从停止模式唤醒，而不是依赖主控定期醒来轮询是否越限。这个设计让“正常状态少干活、异常状态立刻响应”成为现实。

需要注意，报警唤醒后程序要在中断服务里正确读走报警状态并清除标志，否则ALERT引脚会一直保持有效，MCU会被反复唤醒，整机电流会异常偏大。我调试时碰到过一次这个问题，线上跑了一天功耗正常，日志却显示唤醒次数每分钟上百次，最后定位到就是清除寄存器顺序写错了。

7. 复盘：几个最有价值的坑与解决办法

7.1 二极管接反，远程读数直接掉到-40℃

远程通道的正负接反时，芯片大概率会读出一个非常低的固定值。排查思路是：先确认本地通道正常，再查远程通道的原始寄存器值，如果异常，拿起万用表二极管档去量D+/D-两端，确定二极管方向。原理图上标注极性只是第一步，PCB封装也必须看清丝印，焊接返修和样品手工焊都很容易弄反。调试早期就把方向标记做好，能省掉大量时间。

7.2 I2C上拉电阻导致的偶发通信故障

前面提到过，10kΩ上拉在长线多设备场景下会导致上升沿太缓。排查这类问题有个高效方法：不要只看能不能通信，而是用示波器观察SCL的上升沿时间。如果上升沿超过时钟周期的20%以上，通信随时可能出问题。降到4.7kΩ后上升沿变锐利，速率恢复100kHz依然稳定。这个经验对所有多设备I2C总线都适用。

7.3 远程走线穿越强电区域，读数波动明显

有一版PCB把风管传感器走线安排在继电器旁边，实际运行中继电器吸合和断开瞬间，远程温度读数波动接近0.8℃。处理方案做了三件事：走线改到板边并远离继电器区域、传感器双绞线外层增加屏蔽并接地、D+/D-之间在芯片端并联10nF电容。最终波动压到0.1℃以内。HVAC设备强电干扰确实比想象中猛，布局阶段一定不要把模拟走线和高频或继电器驱动线并行。

7.4 断电重启后报警标志残留

报警标志残留会直接表现为ALERT脚一直拉低，MCU被频繁唤醒。解决办法是在初始化流程中先读取状态寄存器，把上一次残留的报警标志读掉并写清除指令，再写入阈值。这一步看起来不起眼，但直接影响整机待机电流和用户体验。所有用到报警中断的项目都应该把“清残留标志”写进上电初始化例程，不要只清一次就完事。

整个项目做完，我对“本地加远程”双通道测温方案的看法有了很大变化。最大的收益其实不是省了一颗传感器，而是让板内温度和远端被测对象温度在同一个芯片、同一套校准逻辑下完成，天然避开跨芯片偏差对齐的问题。远程二极管的布置方式也确实灵活，风管、盘管、电机外壳这些位置都能用一对细线加小元件解决，不用为每个测点准备完整传感器模组。最后再分享一个小经验：调试这类系统时，从第一天起就把每次读到的寄存器原始值记录下来，而不是只记换算后的温度值。一旦后面怀疑标定和校准有问题，原始寄存器数据是唯一可以追溯的依据，只留温度结果很多时候根本查不出是哪一步出了问题。希望这篇梳理能帮你少踩几个坑。