嵌入式HVAC温度监测：STM32F746ZG与PJ85718DM的本地显示与远程上报-育师

做嵌入式这一行的朋友，对“温度”这件事应该都不陌生——尤其是有HVAC（暖通空调）背景的项目，温度从来不是“读个数”那么简单。现场设备间里那块控制板需要本地实时显示，运维人员又要在中控室或者手机端随时看到远端机房的温度趋势，两头都不能误事。这个项目的核心，就是用一颗PJ85718DM数字温度传感器做本地测温，把数据交给STM32F746ZG做处理与分发：本地走LCD显示、按钮切换，远程走RS485和以太网两套通道上送。今天这篇就从头复盘一下，硬件怎么选、驱动怎么调、远程怎么发，以及调试过程中踩过哪些坑。

1. 项目定位：先弄清楚“本地”和“远程”到底各要什么

1.1 把应用场景拆开看（嵌入式柜内 vs HVAC机房）

不少朋友看到“嵌入式”和“HVAC”两个词放一起，第一反应是“测温有什么难的”。但实际到了项目现场就知道，这两个场景对温度监测的要求很不相同。

嵌入式柜内的场景，主要关注的是板级可靠性：电源纹波、芯片发热、风扇失效这些因素会导致机箱内部温度异常，测温节点通常紧挨着功率器件，数据要的是“快”和“准”，延迟几十毫秒都能接受，但整套逻辑必须简洁可靠，不能因为一个传感器故障导致整板复位或者误报警。HVAC场景则更像楼宇自控系统的一个末端：冷站供水管、回风口的温度采集，数据往往要进入BA系统或者物联网平台做趋势分析，对时间戳、数据格式、断线重连都有要求，而且现场环境干扰多、连接线长，信号传输的稳定性比单纯“读个温度”重要得多。

所以这套系统在设计之初就定了一个原则：本地路径和远程路径在逻辑上完全解耦。本地显示和报警依赖ST芯片内部的实时处理，哪怕网络断了、Modbus帧没人回应，LCD上的温度照常刷新，继电器报警照常动作。远程路径则是独立的数据服务组件，负责把数据打包、上传、断线缓存。这样处理之后，两套功能互不拖累，调试、升级、故障定位都清晰许多。

1.2 PJ85718DM与STM32F746ZG在这个项目里各司其职

PJ85718DM这颗温度传感器的定位非常明确：把“物理温度”变成“数字值”。它走I2C接口，返回的数据已经是经过内部校准的数字量，不需要后端再做热电阻桥路、运放调理、ADC采样这些模拟链路。这种方案的最大好处就是设计和调试都省心：硬件上只要接好电源、地、I2C两根线，软件上按时序读寄存器就行，精度靠传感器本身保证。

STM32F746ZG则是整个系统的“中控”。它带一个M7内核，主频能到216MHz，在温度监测这种轻负载应用里性能是富余的，但富余不代表浪费——因为项目里除了测温，还有LCD驱动、按键扫描、RS485收发控制、以太网协议栈，这些功能凑在一起，一个资源够用、外设丰富的MCU就能把整个控制柜的业务都接管下来。F746ZG有这个底气，它的TFT LCD控制器可以直连显示屏，内置的以太网MAC配上外部PHY芯片就能跑网络，省掉一个独立通信处理器，系统复杂度下降了一大截。

打个比方，PJ85718DM像是一支带刻度的温度计，STM32F746ZG则像是旁边那个负责记录、上报、报警的仪表工。温度计只管把刻度读准，笔记怎么记、电话什么时候打，是仪表工的活。

2. 硬件方案：从传感器到MCU再到远程通道

2.1 PJ85718DM关键参数解读

先别急着写代码，硬件的底子得先搭对。PJ85718DM工作在2.7V到5.5V宽供电范围下，这就很友好，板子上无论是3.3V还是5V系统都能直接挂。I2C接口7位地址默认是0x18，这个地址在一条总线上最多只能挂一片，如果你的项目需要多点多路测温，要么选带A0/A1地址脚的版本，要么复用I2C通道，这个后面再展开。

测温范围-40℃到+125℃，精度在-20℃到+85℃区间内能做到±0.5℃，对HVAC的送回风温度监测和嵌入式机柜的结温监测都绰绰有余。分辨率方面，芯片内部ADC是12位的，温度寄存器值LSB对应0.0625℃，换算公式是：实际温度 = 寄存器值 × 0.0625。这里有个细节：PJ85718DM的标志位格式是二进制补码。负数温度的场景在冷站供水管里很常见，处理不好就是一上来读到零下几百度，代码里必须当成有符号数来转换。

还要留意传感器的上电时间。器件上电后有一个典型80ms的稳定时间，期间I2C通信可能出现NACK或者读到全FF。设计程序时，初始化时序里一定要先延时100ms左右再去访问设备寄存器，否则就会出现“上电后第一次读取永远失败，后面又一切正常”的诡异现象。很多人排查半天，最后发现就是初始化时序太着急了。

2.2 本地显示与控制串：STM32F746ZG外设分配

F746ZG的外设资源很丰富，但如果分配得不合理，后面写代码也会很痛苦。我最终的外设规划是这样的：

I2C1专门挂在PJ85718DM上，这样传感器读数的故障不影响其他I2C设备；
FMC总线驱动4.3寸RGB LCD，分辨率和刷新率都足够，简单用LTDC初始化就行，不用额外加昂贵的高速并口屏驱动电路；
两个独立UART：USART1接RS485收发器的T/R控制脚，采用软件翻转方向；UART7接调试串口，打印日志和诊断信息；
以太网MAC用RMII接口外接一颗PHY芯片，时钟用50MHz的有源晶振，省去MCO分频的麻烦；
几个GPIO接按键和报警继电器，按键做了RC滤波并启用HAL库自带的软件去抖逻辑。

LCD这里我要强调一句：F746ZG本身的LTDC支持RGB接口，数据线多、时序要求高，布线时必须注意等长和阻抗。如果是二层板，建议把LCD的GND和电源层分开走，减少高频串扰。我第一次打样就没太在意，结果屏幕亮度高的时候彩色条纹非常明显，后来加了一路RC滤波才压下去。

按键那边也容易踩坑。很多人喜欢用中断方式检测按键，但在这种存在LCD背光、继电器开关的板子里，电磁干扰很容易触发误中断。更好的方式是用GPIO轮询加20ms消抖，消抖是防误触发的第一道防线，而不是靠中断里再去做滤波逻辑。

2.3 远程通道不是只有以太网：RS485与网络的取舍

项目标题里写了“嵌入式与HVAC应用中的本地与远程温度”，远程的落地方式其实有两种思路，很多人一上来就选以太网，但结合实际工程环境，RS485在很多老旧的楼宇自控现场依然是绝对主力。

RS485的好处是传输距离远，1200米以内基本没问题，线缆要求也低，两条双绞线带屏蔽就行；现场施工也愿意用它，因为和电源线可以走同一根桥架，干扰低，成本也便宜。缺点是需要维护一个主机轮询机制，从机没有主动上报能力。

所以在我的方案里，远程通道是双冗余：RS485走Modbus RTU协议，服务楼宇自控系统的主站轮询；以太网走MQTT和Modbus TCP，服务云端平台和本地监控中心。这样既兼容了老系统，又接入了新平台。切换逻辑很简单：RS485通道检测到主站请求就响应，以太网通道按设定周期主动发心跳数据，两条通道互不干扰，后台可以独立判断每条链路是否在线。

模块选型上，RS485收发器选了带隔离的芯片，而不是那种廉价裸收发器。温度采集的前端和MCU之间如果没有做隔离，远端传感器受到雷击或地电位差冲击时，整块主板的MCU和LCD都可能被一起打坏。HVAC 设备现场环境复杂，地电位的意外波动是常态，这笔钱省不得。

3. 软件实现：把传感器读数变成“本地能看、远程能收”的数据

3.1 驱动层：I2C读取与温度换算

先看驱动代码。PJ85718DM的寄存器读取很简单：写寄存器指针地址，然后连续读两个字节。HAL库有现成的接口，下面是核心读取函数：

#define PJ85718DM_ADDR (0x18 << 1) #define PJ85718DM_TEMP_REG 0x00 int16_t pj85718dm_read_temp(I2C_HandleTypeDef *hi2c) { uint8_t reg_ptr = PJ85718DM_TEMP_REG; uint8_t buf[2] = {0}; // 写寄存器指针 if (HAL_I2C_Master_Transmit(hi2c, PJ85718DM_ADDR, &reg_ptr, 1, 100) != HAL_OK) { return TEMP_ERROR; } // 读取温度寄存器的两个字节 if (HAL_I2C_Master_Receive(hi2c, PJ85718DM_ADDR, buf, 2, 100) != HAL_OK) { return TEMP_ERROR; } // 拼成有符号16位整数 int16_t raw = (int16_t)((buf[0] << 8) | buf[1]); // 实际温度 = raw * 0.0625 ℃ // 用乘以625再除以10000的方式做定点运算，避免浮点 int32_t temp_x100 = (int32_t)raw * 625 / 100; return (int16_t)temp_x100; }

这里我故意没用浮点。在M7上跑浮点其实很轻松，但温度这个换算用定点就足够，而且浮点运算的结果在不同编译优化级别下可能会产生细微差异，对日志记录和报警判断来说反而容易造成不一致的困惑。返回值的单位是0.01℃，显示的时候除以100就能得到小数部分，这就是“温度内部统一用百倍整数存储”的工程习惯，好处是协议传输、存储、比较都方便，不会出现浮点数转字符串时精度丢失的问题。

还要注意I2C通信的超时处理。HAL库的默认超时参数我改成50ms，不是越大越好——如果总线上出问题，50ms后就要转而出错处理，而不是死等。连续读取失败3次就判定传感器异常，驱动层会返回TEMP_ERROR，应用层收到这个值后进入错误策略：LCD上显示“SENSOR ERR”，远程上报数据包中置故障标志位，主程序不挂死、不喂狗超时。

3.2 本地显示：LCD与按键交互

本地显示这块，UI逻辑不需要很复杂，但信息层次得清晰。我设计了三个页面：实时温度页、历史温度页（近24小时曲线）、参数配置页（报警阈值、温度修正值）。页面切换靠两个按键，短按切换页面，长按进入配置模式，所有按键事件都通过一个事件队列传入UI模块。

时间上的经验是：LCD的刷新频率不要贪高。温度本身是缓变量，一秒刷新一次完全足够。但就算一秒刷一次，也不建议整屏重绘，而是把温度区域单独做成一个小窗口，只刷新数值字符串。整屏重绘既闪烁又费CPU，还可能因为刷屏占用了I2C总线的访问时间，导致其他任务出现抖动。

报警阈值默认设置为：高温报警60℃，低温报警-5℃，在配置页里可以调整。报警触发时除了LCD上显示状态图标，还会同步驱动继电器动作。这里有个逻辑细节：报警后的恢复状态必须加上滞回区间，例如高温报警60℃触发，要等温度降到55℃后才自动解除。如果没有这5℃的滞回，传感器在阈值附近抖动时继电器会反复通断，现场的人以为设备疯了。

3.3 远程上报：Modbus TCP从站 + JSON心跳两种通道

远程部分我分了两个链路来写。RS485上跑Modbus RTU从站，主站连上来读保持寄存器地址30001（或者你想映射的实际寄存器地址），里面放的是整数格式的温度值（单位0.01℃）。Modbus RTU的CRC校验必须算对，这是老生常谈但依然高频出错的地方，尤其是寄存器个数奇数和偶数都算不出来。最稳妥的方式是查表法，查表查出来的CRC就和标准工具对得上。

以太网那边用的是LwIP协议栈。F746ZG内部带着以太网MAC，所以只需要外部一颗PHY。LwIP配置成带操作系统的版本（配合RTOS），跑一个独立的MQTT任务，每30秒向服务器发布一条JSON消息，包含了设备ID、温度值、传感器状态和工作模式。消息格式类似这样：

{ "device_id": "HVAC-NODE-07", "ts": 1734422400, "temp_celsius": 23.81, "sensor_err": 0, "alarm": 0, "uptime_s": 86400 }

为什么用JSON而不是简单发一个“23.81”？因为MQTT的topic里本身就带了设备标识信息，payload里再放一组有语义的键值对，后端解析的时候字段对得上就行。以后加湿度、加开关状态，payload扩展一下就行，不会破坏已有字段的解析。

Modbus TCP这条通道不是必须的，但很多工业上位机组态软件只认Modbus协议，所以我在LwIP里还开了个端口502的低负载TCP服务，实现基本的读保持寄存器命令。两条网络通道并行存在，调试的时候用TCP工具直接连502端口发报文，就能快速验证整条链路通不通，不用等MQTT服务器起来。

4. 实操调试：从点亮LCD到远程收到第一帧温度

4.1 平台与工程化准备

开发环境我用的是STM32CubeIDE，配合STM32CubeMX生成HAL初始化代码。工程上我建议从一开始就开一个独立的任务管理模块，而不是把所有逻辑都堆在main函数的while循环里。这样调试的时候任务之间的调度关系一目了然。

调度周期我大致这样分配的：传感器读取任务100ms周期，本地显示刷新500ms周期，RS485从站处理5ms周期（Modbus的响应时间不能太慢），MQTT发送30s周期。在裸机和RTOS之间，我这次直接选了RTOS（FreeRTOS），因为一旦加入以太网和MQTT，裸机主循环的异步处理会很别扭，而RTOS的队列和信号量能很好地解耦各个模块。

调试阶段建议打印全部打开，但上正式环境之前要收敛掉。严重依赖打印输出会掩盖真实问题，比如I2C偶尔异常时，日志里可能看到的是“读失败又重试成功”，你就忽略了底层时序的隐患。这种问题后续处理起来更费时。

4.2 联调流程与关键测试点

我习惯按下面这条顺序去联调，能省很多找问题的精力：

先单独测PJ85718DM：写一个裸机小程序，只读温度并通过UART打印，确认传感器地址、寄存器映射、温度换算全对，再接进主工程；
LCD单独点亮：只刷纯色，验证FMC/LTDC初始化正确；
把温度值放到LCD上显示：验证UI更新和字符绘制；
接RS485主站模拟工具：用上位机改寄存器地址、读保持寄存器，验证Modbus RTU从站响应；
配置固定IP，测试以太网物理层通不通：利用PHY的loopback模式ping本机；
启动LwIP，验证TCP通道能收到上位机指令；
最后才开MQTT，连上服务器看JSON数据。

为什么要这么拆？因为每一层出问题时的表现都不同，传感器坏了和网络没通是完全不同的现场现象，混在一起排查，效率极低。比如LCD一直没显示，你很难判断是LTDC配置错了还是I2C上传感器压根没给数据。一步一验，坏了就定位在哪一环节，不然到最后对着一个大黑屏干瞪眼。

4.3 标定与长期稳定性验证

PJ85718DM出厂时已经校准过，正常情况下不需要用户标定。但如果你对绝对精度有更高要求，可以在0℃冰水混合物和100℃沸水两个点做两点校准，把偏差记录在STM32内部Flash的某个特定区域，运行时加上修正值。注意：修正值要存两份备份，写Flash前先擦除再编程，注意掉电中断的风险——如果擦除过程中断电，下一版程序直接读不到合法标志位，就会重新走一遍出厂默认流程。

长期稳定性验证方面，我拿这套板子在模拟的恒温恒湿机房跑了72小时，数据记录间隔1分钟。72小时后回放温度日志，发现有两个值得注意的点：一是深夜时段MPU负载极低时，以太网重连速度明显变慢——后来定位是后台线程优先级太低，被其他任务长期占用导致定时器跑偏，调了优先级后重连恢复正常；二是传感器自身读数会出现偶尔的1~2 LSB抖动，这在0.0625℃级别分辨率下是正常的，显示层做一阶滤波（比如new_value = old_value * 0.7 + new_value * 0.3）就能让显示平滑很多。

5. 常见问题与排查实录

5.1 高频问题速查表

下面这些坑是我在这类项目中反复遇到过的，整理成表格方便大家直接对应排查。

现象	可能原因	排查步骤	解决办法
上电后第一次读温度失败，之后正常	传感器还没稳定，开始读取太早	查看初始化时序，确认延时是否足够	在传感器初始化之前延时100ms~150ms
I2C一直读到0xFF	地址错误或上拉电阻没接	用逻辑分析仪看SDA/SCL波形	检查7位地址0x18是否正确，上拉电阻用4.7kΩ
LCD出现花屏或条纹	FMC时序不对或电源纹波大	降低刷新频率测试，检查电源走线	LCD背光串一个磁珠，FMC时序加海森堡参数调整
RS485数据时好时坏	收发控制脚切换时序不对	抓RS485芯片DE端波形	T/R方向切换后加10μs延时再发送数据
以太网ping不通	PHY芯片复位时序或时钟源问题	检查PHY的CLK是否输出正常波形	用50MHz有源晶振，使RMII时钟稳定
Modbus读寄存器返回错误值	寄存器数量或地址映射不对	用Modbus Poll工具手动读几个地址	核对从站地址映射表，按实际寄存器个数声明

5.2 几个容易忽略的细节

第一个细节，就是你在RTOS任务里喂I2C，需要使用互斥量保护。如果你在两个任务里同时调HAL_I2C相关的接口，且不加保护，那么在线程切换的瞬间很容易发生数据竞争，表现为偶发性读取失败，而且难以复现。这个坑在裸机上不存在，但上了RTOS就躲不掉。

第二个细节和电源有关。PJ85718DM虽然功耗很低，但如果你把它和LCD背光、继电器的电源放在同一路LDO后端，那当继电器吸合瞬间，电压跌落会导致传感器短时间内输出错误值。工程项目里我经常看到这个问题，尤其是继电器线圈没有续流二极管的设计，压降毛刺非常明显。给传感器单独用电感加电容做一个LC滤波，能挡住绝大部分电源噪声。

第三个细节，是出厂默认的温度修正值。很多芯片寄存器里默认值不是0，如果程序里没把它读出来，就会和你期望的“0修正”不一致。建议程序初始化时，把修正值寄存器显式写0，这样后续比较和分析数据时不会有偏差。

6. 这个方案还能往哪走

这套系统做完之后，我当时给项目留了几个扩展口。一个是把PJ85718DM换成多通道版本，比如做8路温度巡检，这在数据中心机柜场景很常见，F746ZG的I2C总线只需要再加一个TCA9548A多路复用器，就能把8个传感器挂在同一条总线上。另一个是把MQTT的topic按楼宇层级设计，比如/floor/room/device，云端做嵌套存储，可以在不改变设备端代码的情况下支持多级告警规则。

还有一点，很多朋友会问为什么要用STM32F746ZG这种带LCD控制器和以太网MAC的高性能MCU来测温，是不是大材小用了。这个问题的答案要看整个系统，而不是只看温度采集本身。温度只是数据来源，后面接的上位机协议、屏幕显示、远程控制、数据记录才是系统的主体功能，这些东西凑在一起，普通小容量MCU很快就吃力了。如果你只是做一个测温模块单独用，选一颗小芯片就够，但如果测温是整套控制的一部分，选F746ZG这种带图形和网络能力的MCU，反而省了很多外围芯片和软件开销。

我个人在实际操作里的感受是，温度采集这类功能，作为产品设计永远是锦上添花，但要把“读取”变成“系统”，真正的功夫花在协议、周期、异常处理和链路设计上。PJ85718DM很快就能读通，难的是让它稳定地融入一个长期运行的控制系统，这时候每一步细节都值得较真。