做 HVAC 嵌入式控制有一段时间的人基本都会碰到同一个问题控制板上跑得很好的温度算法一接上现场管线读数就开始漂。温度测量看似简单本地 MCU 自带传感器、远端加一个 PJ85718DM就能同时看板温和环境温但真正落地的工程细节比表面看到的要多得多。这篇文章就以 STM32F334R8 为例讲清楚如何用它配合 PJ85718DM 构建一套既适合嵌入式设备自检又能覆盖 HVAC 远端测点的双通道温度监测方案从选型、硬件、代码到标定一次讲透适合正在做空调控制器、冷链监控、机房温控或各类板级温控产品的开发者参考。1. 方案选型与总体思路1.1 为什么选 STM32F334R8 做主控STM32F334R8 属于 Cortex-M4F 内核主频 72MHz带硬件浮点单元在这个定位里算得上“麻雀虽小五脏俱全”。真正吸引我的是它的外设组合高分辨率 ADC、比较器、运放、HRTIM 一起出现在同一颗芯片上。对 HVAC 项目来说HRTIM 可以直接用来驱动压缩机或 PTC 加热器的 PWM 波形运放能处理模拟电流信号做故障判断而 ADC 负责温度采样一颗 MCU 就能把采样、保护、控制串成一条完整链路。相比用普通 MCU 外挂一颗温度芯片来测板温STM32F334R8 内部已经集成了温度传感器省掉一路 PCB 布局和一颗物料测出来的是芯片结温附近的值用来反映控制板整体热状态非常合适。很多工程团队在这个位置习惯放一颗 NTC但 NTC 需要外部分压电阻、校准表格直贴在芯片旁边还会被局部铜皮导热影响实际精度并不比内部传感器好到哪里去。只要产品允许 1~2℃ 的板温误差内部传感器就是性价比最高的选择。远程温度则需要一颗适合接线的传感器这里用到 PJ85718DM。它通过 I2C 总线输出数字量带片上带隙基准和 ADC出厂校准精度通常在 ±0.5℃ 这个级别。放在空调回风口、冷冻水管表面或者机房远端比模拟输出方案抗干扰能力更强也比单总线方案省去严格时序的烦恼。它的地址引脚还能让我在一根 I2C 总线上挂多个测点后续扩展非常灵活。1.2 本地温度与远程温度的分工逻辑很多人会问“既然有远端传感器为什么还要测板温”这个疑问我在项目里被问过很多次。HVAC 设备最常见的故障模式有两类一类是环境温度异常另一类是控制板自身发热异常。如果只测环境温度控制板散热风扇堵转、功率器件老化导致的板级过热根本发现不了如果只测板温现场实际温度波动又没法参与控制决策。两条通道相互配合环境温度用于制冷/制热控制板温用于板级保护和老化预警测出来的是两组独立数据判断逻辑也能分开写。在具体的采集拓扑上我把它设计成 “本地 ADC 直采 远程 I2C 轮询” 的双通道结构。本地传感器直接挂在 ADC 内部通道上采样最快、代码最简单远程 PJ85718DM 挂在 I2C1 总线MCU 每 500ms 轮询一次读取温度寄存器然后换算。两个通道的数据都进入同一个滤波和缓存层上层控制逻辑只认最终温度值不关心原始数据来自哪里后续换传感器型号也不影响控制策略。1.3 从标题看整个项目要解决的三个问题拆开这个标题核心其实就三件事本地温度怎么低成本地测准、远程温度怎么抗干扰地传回来、两个温度怎么在嵌入式与 HVAC 场景里用起来。嵌入式场景关心的是 MCU 资源占用与故障隔离HVAC 场景关心的是温度控制的响应速度和长期稳定性。把这两个场景放到同一块主板上关键在于不要让远程传感器采集反客为主地占用过多 MCU 时间也不能让本地板温误触发保护。所以整体架构上远程传感器走 I2C 中断或轮询本地温度走 ADC 单次转换两边的数据都不做复杂运算滤波和判断放到上层任务里统一处理。2. 硬件设计与接口实现要点2.1 PJ85718DM 远程测温的接线与信号完整性PJ85718DM 采用标准 I2C 接口供电范围 2.7V 到 5.5V我这里直接挂在 3.3V 电源轨上。常规接线就是 VCC、GND、SCL、SDA 四根线SCL 和 SDA 各接一颗 4.7kΩ 上拉电阻到 3.3V。如果你的线缆比较短比如一米以内4.7kΩ 没问题要是传感器装在好几米外的风管里总线电容会明显变大我会把上拉电阻降到 2.2kΩ同时把 I2C 时钟降到 100kHz这样能很有效地减少信号沿失真。值得注意的是HVAC 设备里面往往有变频器、继电器和感性负载电磁环境并不干净。我吃过一次亏传感器线缆和风机驱动线走同一个线槽结果每次风机启动瞬间温度读数就跳几下。后来把传感器线缆改成屏蔽对绞线屏蔽层单端接地并且在线缆入口处加了一颗 100Ω 串联电阻和 1nF 对地电容组成 RC 低通。这个组合下来现场干扰引起的毛刺基本消失。远程测点如果离控制板很远我建议在传感器供电端那里放一颗 100nF 和 10μF 的退耦电容防止总线供电被拉低。I2C 总线上还应该加一颗 ESD 保护二极管这种二极管电容很小不影响总线时序但对现场插拔线缆和静电放电非常有帮助。2.2 内部温度传感器测量电路与参考电压问题STM32F334R8 的内部温度传感器已经集成到 ADC 内部模拟通路不需要外部电路但有一个细节很容易被忽略ADC 的参考电压直接决定换算精度。很多最小系统板把 VREF 和 VDDA 简单连在一起用一颗低压差稳压器供电如果稳压器本身精度一般温度换算出来的电压就会有偏差。我在项目里把 VREF 单独走线接到一颗高精度基准芯片的输出端虽然多花了几毛钱但 ADC 全量程精度明显改善。内部温度传感器的输出最终体现为 ADC 编码值采样时间对噪声影响很大。参考手册通常要求采样时间足够长让内部采样电容完全充放电我配置的是 ADC 采样时间 239.5 个周期。实测在 12 位分辨率下这个采样时间得到的读数波动很小。如果采样时间太短你会看到本地温度读数在几度范围内跳动那不是传感器问题是采样保持电容没充满电。建议在 PCB 布局上让 VDDA 和 VSSA 走线远离 PWM 驱动输出和继电器驱动线。我曾经在一块板上画出很漂亮的单点接地结果数字部分回流和模拟部分共用了一段铜皮ADC 读数在功率输出开启后依然有规律性抖动。后来把模拟地分割、单点汇接到电源输入处问题才彻底解决。这种问题用示波器很难一眼看出来数据却会诚实告警。2.3 两层电压域与抗干扰的取舍远程传感器安装在现场控制板可能处于另一个供电环境要留意共地问题。如果远程传感器和控制板共用一个电源还好说如果传感器单独供电两个电源之间没有很好共地I2C 总线上的电平可能完全不在正常范围内。对 HVAC 现场应用我通常让传感器直接由控制板供给 3.3V避免分压差异导致的潜在风险。隔离方案在消费类产品中不一定需要因为数字隔离芯片会增加 BOM 成本和布局面积。但如果你的设备要过电磁兼容认证且现场强干扰源很多可以考虑在 SCL/SDA 上增加隔离。我实际测试中发现普通 RC 滤波加屏蔽线已经能应付绝大多数情况真正需要隔离的场景很少。设计时把可选项做成兼容位在 PCB 上预留隔离芯片封装和电阻位这样同一块板子既能跑低端产品也能升级高端版。3. 软件实现与核心代码解析3.1 初始化流程与时钟配置软件上我基于 HAL 库开发。第一步是配置系统时钟使用外部晶振 PLL 倍频到 72MHz如果产品要求低成本也可以用内部 HSI 16MHz 直接运行温度测量精度不依赖 MCU 主频所以不影响传感器读数。I2C1 使用 PB8/PB9 复用功能配置为开漏输出、内部禁止上拉因为外部已经有上拉电阻再开内部上拉会导致并联电阻变小。ADC1 初始化是本地温度读取的关键。配置为 12 位右对齐、单通道、软件触发、单次转换即可。第一次初始化时要调用校准函数让 ADC 完成内部自校准这个步骤不做的话前几次采样值可能偏差很大。完整代码大致如下void MX_ADC1_Init(void) { hadc1.Instance ADC1; hadc1.Init.ClockPrescaler ADC_CLOCK_SYNC_PCLK_DIV4; hadc1.Init.Resolution ADC_RESOLUTION_12B; hadc1.Init.DataAlign ADC_DATAALIGN_RIGHT; hadc1.Init.ScanConvMode ADC_SCAN_DISABLE; hadc1.Init.EOCSelection ADC_EOC_SINGLE_CONV; hadc1.Init.LowPowerAutoWait DISABLE; hadc1.Init.ContinuousConvMode DISABLE; hadc1.Init.NbrOfConversion 1; HAL_ADC_Init(hadc1); if (HAL_ADCEx_Calibration_Start(hadc1) ! HAL_OK) { error_handler(); } sConfig.Channel ADC_CHANNEL_TEMPSENSOR; sConfig.Rank ADC_REGULAR_RANK_1; sConfig.SamplingTime ADC_SAMPLINGTIME_239CYCLES_5; HAL_ADC_ConfigChannel(hadc1, sConfig); }内部温度传感器的使能通常在 ADC 初始化里通过环境控制寄存器打开不同系列寄存器名不同但 HAL 库底层已经封装好了。哪怕不额外操作只要选择了对应通道库函数就会把内部传感通路接通。3.2 内部温度传感器的数据读取与换算换算公式是手册里给的直线近似先计算传感器输出电压再用电压减去 25℃ 时的典型电压除以平均斜率加上 25℃。不同单片机的 V25 和 Avg_Slope 参数不同量产产品最好从手册规格书里查一下最小值、典型值、最大值把典型值写入代码。我的读取函数如下#define V25 0.760f #define AVG_SLOPE 0.0025f float read_internal_temp(void) { uint32_t adc_val 0; float vsense 0.0f; float temp 0.0f; HAL_ADC_Start(hadc1); if (HAL_ADC_PollForConversion(hadc1, 10) HAL_OK) { adc_val HAL_ADC_GetValue(hadc1); } HAL_ADC_Stop(hadc1); vsense (float)adc_val * 3.3f / 4095.0f; temp ((vsense - V25) / AVG_SLOPE) 25.0f; return temp; }这里 3.3V 是参考电压如果你的板子用了 3.0V 或其他电压一定要改成实际值。我遇到不少初学者在这个地方直接抄网上代码结果测出来的温度整体偏移好几度就是因为参考电压和硬件不一致。换算之后可以做一级低通滤波不过内部温度变化通常比较慢控制周期 100ms 采一次直接滑动平均即可。3.3 PJ85718DM 的驱动与温度计算PJ85718DM 的读数方式很简单发送器件地址后写温度寄存器地址然后连续读取两个字节。不同厂家的寄存器宽度可能不同我的驱动代码按 12 位分辨率处理数据高 12 位有效低 4 位作为余量uint8_t read_remote_temp_reg[2]; uint8_t reg_addr 0x00; int16_t raw 0; float remote_temp 0.0f; if (HAL_I2C_Mem_Read(hi2c1, PJ85718DM_ADDR 1, reg_addr, I2C_MEMADD_SIZE_8BIT, read_remote_temp_reg, 2, 100) HAL_OK) { raw (int16_t)((read_remote_temp_reg[0] 8) | read_remote_temp_reg[1]); raw raw 4; remote_temp (float)raw * 0.0625f; }如果器件温度分辨率是 12 位那么低 4 位是无效位右移四位后带符号扩展LSB 是 0.0625℃。如果你的 PJ85718DM 批次是 11 位或 16 位分辨率换算系数要依实际情况调整。这个细节在数据手册里一般有明确说明实在找不到就通过恒温环境实测对照反向推算 LSB。实际项目里远程传感器偶尔会出现通信失败HAL_I2C_Mem_Read 会返回非 HAL_OK。对 HVAC 应用我不会让一个通信错误就把控制线程卡死而是在调用处加重试和计数。连续 3 次失败就报传感器异常把上次有效值保留继续用于控制这种策略能显著提升设备容错性。3.4 滤波、报警与故障诊断策略温度数据进了系统之后要先经过滤波器再参与控制。我常用的是 8 点到 16 点的滑动平均取中间值而不是简单算术平均。滑动平均对长期趋势有平滑作用但对突然出现的单点尖峰不够敏感一旦有一个异常大值混进去均值会被拉偏。限幅平均滤波是好选择先按顺序采集排序后去掉最大最小再求平均。这个滤波方式在 HVAC 现场干扰下表现非常好。报警逻辑分三档正常、预警、故障。本地温度高于 85℃ 时控制逻辑会触发降频或停机保护高于 105℃ 直接切断加热输出。远程温度则根据设定值判断超出上下限范围时发预警连续多个周期超限才进入故障状态防止瞬时波动导致误报。两个通道温差若是长期超过某个阈值比如 15℃基本可以怀疑传感器安装位置有问题或者风道堵塞这个交叉判断能力是单通道方案不具备的。为了防死循环I2C 通信任务用超时机制每轮读取的等待时间不超过 100ms。同时开一个软件看门狗如果上层任务超过 1 秒没有被喂狗就复位重启。这样即使 I2C 总线被现场强干扰打挂系统也会自动恢复而不是无声无息地停在某个状态。4. 实操记录与参数调试4.1 标定方法与误差补偿任何温度传感器在工程现场都建议做一次标定。内部传感器和 PJ85718DM 的标定方法稍有差异。远程传感器出厂校准做得比较到位我主要验证它的一致性把它和标准温度计放在同一个铝块冷却槽里记录 0℃、25℃、60℃ 三个点的读数差。如果偏差小于 0.5℃直接使用如果偏差在 0.5℃ 到 1.5℃ 之间就在软件里加一个偏移量补偿没必要把传感器退回供应商。内部温度传感器就稍微麻烦一些因为它不可能从芯片里拆出来单独测。我通常让带芯片的控制板在常温环境中稳定半小时用高精度温度探头贴在芯片封装表面记录此时内部传感器读数。然后计算出实际温度与内部读数的偏差把这个偏移量存到 FLASH 里每次上电读取并加到换算结果上。这个方法可以把板级传感器误差从 ±3℃ 压缩到 ±1.5℃ 以内对于板级保护用途完全够用。标定数据不要只存在 MCU 的 RAM 里调试器一断开就丢了。我习惯把标定参数写到一个末地址扇区程序启动时先读取校验校验失败就用默认值。这样量产时只需要在终检工位写入一次标定结果。4.2 实测数据与长时间运行表现我搭建了一个模拟 HVAC 环境用 PTC 加热器从室温开始循环升温降温PJ85718DM 放在出风口附近控制板放在旁边记录 10 分钟的本地和远程温度变化。数据结果是加热器启动瞬间远程温度有 0.4℃ 左右的抖动随后快速收敛本地温度保持平缓上升没有异常毛刺。这说明滤波和去耦设计达到了预期效果。长时间运行测试中我连续运行了 72 小时每 10 分钟记录一次数据。远程传感器的最大偏差不超过 0.6℃本地传感器由于芯片自身发热会比环境温度高 2℃ 左右。这不是测量错误而是内部传感器本来就是测芯片结温的用来做板级过热保护更合适而不是作为环境温度采集源。这个认知在项目评审时很重要避免被误读成设计缺陷。I2C 总线的健康状态也做了监控。正常运行 72 小时通信失败次数只有个位数全部集中在电加热继电器通断的瞬间。我的驱动代码会自动重试重试后全部恢复。这个现象也说明远程传感器不能完全依赖物理层抗干扰软件重试机制是不可省略的兜底。4.3 常见问题排查速查表我在调试过程中把问题收集成一张速查表每次拿到新板子都会先按这个表排查。典型症状可能原因解决办法远程温度读回固定值或全 0I2C 地址错误、线序接反、上拉电阻缺失检查硬件连接用 I2C 扫描工具检查器件地址远程温度尖峰跳动电源噪声污染、总线过长、PWM 干扰耦合增加 RC 滤波上拉电阻改小线缆改用屏蔽双绞线I2C 偶发 NACK总线电容过大、速率过高、器件故障电流拉低 SCL降速到 100kHz加大上拉能力修复线缆接触本地温度整体偏高芯片自身发热、板级发热传导区分结温与环境温度修正控制阈值或加偏移本地读数波动很大ADC 采样时间偏短、参考电压不稳、数字地干扰加长采样时间VREF 独立供电优化接地远程读数正常但不受加热影响传感器安装位置远离气流或贴附在结构件上调整测点位置避免热桥直接接触这些排查经验对刚做温度监测的团队特别有用很多问题看起来像是芯片不行实际是硬件布局或参数配置的问题。5. 应用扩展与工程化建议5.1 从 Demo 到产品的工程化改造原型验证通过后如果要进入产品阶段第一件事是把标定参数、器件地址和故障记录统一存到 EEPROM 里而不是存在 MCU 内部 FLASH。这是因为 MCU 固件升级时可能会擦除 FLASH标定参数一旦丢了要全部返工重标定。EEPROM 独立存储写坏还能重新写足够安全。第二件事是加通信协议。我用的是 Modbus RTU远程温度、本地温度、报警状态放到三个保持寄存器里上位机可以直接读取。对 HVAC 控制系统来说Modbus 生态非常成熟无论是接楼宇自控还是接入物联网网关都很方便。如果产品只做本地控制至少也要预留一个日志输出口方便现场用串口工具排查。第三件事是安全冗余。温度传感器一旦彻底失效系统不能直接停止运行。我在软件里设定了“故障替代值”如果本地和远程温度中任何一个失效就用另一个温度值替代并且标记为降级模式。这样设备仍然能维持基本控制只是精度会下降维护人员也能在报警记录里看到哪个通道出了问题。5.2 与 HVAC 系统联动时的控制时序温度监测最终要参与到控制逻辑里这时要注意采样周期与控制周期的配合。比如压缩机启动前先连续采样 5 次远程温度取稳定的初始值作为控制基准而不是用上电第一时间的数据。否则压缩机一开始工作风机带来的气流会瞬间改变传感器附近的温度场控制算法会因为参考值突变而误判。另一个容易踩坑的地方是远程传感器探头不要安装在蒸发器直接出风口正中央那里的瞬时风速和温度均匀性都比较差读数波动会明显大于房间平均温度。更可靠的做法是把探头放在回风路径上或者离出风口有一段距离的混合区。现场安装时我会拿手持风速仪和标准温度计验证一下测点数据确认读数能代表控制对象的真实温度。5.3 升级思路多测点与无线化如果后期产品需要更全面的温度覆盖可以把多颗 PJ85718DM 挂到同一根 I2C 总线上只需要给每颗传感器设置不同的地址引脚组合。总线轮询代码加上地址数组循环读取即可MCU 计算负荷几乎不变。更进一步的方案是走无线采集把远程传感器换成带射频模块的无线节点控制板和节点之间用私有协议通信。这样一来现场免布线、测点挪动方便但会增加协议开发成本和电池维护需求是否值得要看具体项目场景。我个人在实际项目里更倾向先用有线多测点把系统调通把算法和控制策略验证好再评估无线化改造。毕竟无线链路带来的数据延迟和丢包重传会直接影响温度控制响应在 HVAC 这种控制周期很长的场景下影响可能不大但排查问题时要多一个维度。做这个双通道温度监测方案我最大的感触是难的不是读取传感器而是让读数在真实电磁环境里保持可靠。你会遇到各种“怪象”比如远程温度在电加热启动瞬间跳一下、内部温度在高负荷时缓慢漂移、I2C 通信偶尔来个 NACK。这些问题都不是芯片本身的问题而是系统层面的设计问题。本地与远程两个通道拼在一起等于同时暴露了电源、布局、时序、滤波所有环节的短板也正因为这样一套扎实的采集方案可以把整个硬件平台的底子摸得很清楚。如果你正准备做类似产品建议从一开始就把总线滤波、参考电压和重试机制规划好后续调试能少走很多弯路。