★ FEATURED ARTICLE 1. 项目概述温度监测系统的芯片选型与分工逻辑做嵌入式和 HVAC 这两个方向的人大概率都遇到过同一个尴尬本地温度监测很简单一个 NTC 加一个 ADC 就能跑可一旦牵扯到远程监测事情就立刻变得麻烦——要不要加通信模块数据往哪里传MCU 算力够不够系统稳定性怎么保证这个项目标题里给出的两颗芯片恰好就是针对这些问题的典型答案组合PJ85718DM和PIC32MZ1024EFE144。前者是一颗低功耗温度传感器接口芯片后者是 Microchip 旗下带 1MB Flash 的高性能 32 位 MCU。两者配合覆盖了本地温度采集和远程数据上报两条链路。先说说这是什么场景。嵌入式里常见的温度监测比如服务器机柜、电池管理系统、工业控制器核心诉求是精度和响应速度而 HVAC暖通空调里的温度监测比如风管温度、回风温度、室温采集核心诉求则是长期稳定性、抗干扰能力以及多路采集的扩展性。这个项目等于把两种场景揉到了一起用 PJ85718DM 做前端信号调理用 PIC32MZ 做后端处理和通信两条需求都能覆盖。适合谁来参考如果你是做嵌入式硬件、IoT 温控设备、空调控制器、或者工业数据采集的开发者这篇文章的芯片选型思路、硬件接口设计、以及远程上报的协议栈方案都可以直接拿去做预研或者工程落地参考。需要提前说明的是PJ85718DM 这颗芯片的公开资料并不像主流传感器那样铺天盖地很多细节需要从数据手册和实际调试中摸索。所以这篇文章里涉及该芯片的部分我会结合常见温度传感器接口芯片的通用设计逻辑以及我在类似项目中的实操经验来补充尽量保证流程可复现。2. 硬件架构与核心芯片解析2.1 PJ85718DM 在系统里到底扮演什么角色先说 PJ85718DM。从型号命名和引脚分布来看它属于温度传感器信号调理类芯片典型的用法是外接 NTC 热敏电阻或者 PT 系列热电阻完成恒流源激励、信号放大、模数转换然后通过数字接口把温度数据送给 MCU。为什么要单独加这么一颗芯片而不是直接用 MCU 内置 ADC 采样热敏电阻很多新手容易在这里踩坑MCU 内置 ADC 虽然方便但采样精度容易受参考电压波动影响而且 NTC 本身是非线性元件直接测分压值需要查表或者做多项式拟合占用 Flash 和 CPU 时间。PJ85718DM 这种专用芯片的好处在于它把激励、放大、转换、线性化这一整套流程都在内部完成了MCU 拿到的已经是处理过的数据省下来的资源可以用来跑通信协议栈。另外HVAC 场景里往往要求多点测温。比如一台空调外机要同时测压缩机排气温度、冷凝器管温、环境温度。如果全靠 MCU ADC 去轮询每路还得配滤波电路PCB 面积和 BOM 成本都会失控。PJ85718DM 这种接口芯片通常支持多通道输入或者可以通过 I2C/SPI 总线级联几颗这样整套系统的温度采集通道数量就变得非常灵活。2.2 PIC32MZ1024EFE144 的核心优势PIC32MZ1024EFE144 这颗芯片型号里的数字已经透露了很多信息1024 代表 1MB FlashEFE144 指的是带 ECC Flash、144 引脚封装。它属于 Microchip 的高性能 MIPS 内核 MCU主频能跑到 200MHz还有两个独立 ADC、多个 UART、SPI、I2C、CAN、USB 等外设。在这个项目里选择它不是因为算力有多夸张而是这三点第一大 Flash。远程温度监测如果要上 TCP/IP 或 TLS单是通信协议栈就能吃掉几百 KB。PIC32MZ 的 1MB Flash 给了很大的缓冲空间甚至可以在里面塞一个简单的文件系统用来做本地日志存储。第二外设丰富且可重映射。温度传感器接口、LCD 显示、按键输入、RS485、以太网口这些外设都可以通过引脚重映射功能灵活分配画 PCB 的时候不用绕线绕到怀疑人生。第三ECC Flash 对长期可靠性有用。HVAC 设备经常要在高温、高湿、电压不稳定的环境里跑好几年Flash 位翻转的风险比普通消费电子高得多。带 ECC 的 Flash 可以检测并纠正单比特错误这对长期运行的系统是一层很重要的保护。2.3 系统级的整体框架规划整个系统的数据链路可以拆成下面几条本地温度链路传感器 → PJ85718DM信号调理ADC→ PIC32MZ数据处理、显示、本地存储远程温度链路PIC32MZ → 通信模块以太网/Wi-Fi/4G/RS485→ 云端或上位机人机交互链路PIC32MZ → LCD 或者 LED 指示灯用于本地直观查看温度状态从系统架构来看PJ85718DM 承担的是“感知层”PIC32MZ 承担的是“处理层 通信层”。这种分层方式带来的最大好处是职责单一便于调试和故障定位。比如温度读数不准那问题大概率出在传感器和 PJ85718DM 这一侧数据传不到云端那问题就集中在 PIC32MZ 的通信模块配置上。如果所有功能都堆在一颗芯片上排查起来往往一头雾水。3. 通信方案与远程监测实现3.1 远程通信怎么选以太网、RS485 还是无线远程温度监测核心是把本地的温度数据送到一个可以访问的地方。结合 HVAC 和嵌入式场景通信方式大致有这几种以太网适合楼宇自控、机房监控这类设备位置固定且已有网络布线的场景。PIC32MZ1024EFE144 自带以太网 MAC 控制器要做的只是外挂一颗 PHY 芯片比如 LAN8740然后跑 Microchip 的 TCP/IP 协议栈。这种方式的好处是带宽高、延迟低、稳定性好坏处是布线成本高只适合固定安装。RS485 总线在 HVAC 领域非常经典。一台空调外机、多台内机之间经常用 RS485 组网走 Modbus RTU 协议。PIC32MZ 的 UART 加一颗 RS485 收发芯片比如 SP3485就能搞定成本极低而且抗干扰能力很强。缺点是速率不高典型 9600bps 或 19200bps不适合传大数据量。Wi-Fi / 4G 模块适合不方便布线的场景。PIC32MZ 通过 UART 或 SPI 与 Wi-Fi 模块通信模块负责网络连接MCU 负责业务逻辑。这种方式最灵活但要考虑模块的功耗、配网流程、以及断线重连机制。我在实际项目中最常用的组合是本地 RS485 组网 网关统一以太网上报。也就是说每一台设备上只跑 Modbus Slave数据通过 RS485 汇聚到一台边缘网关网关再通过以太网把打包好的数据推送出去。这样每台设备的成本很低而且即使网关断了设备本地依然能正常运行不会因为网络问题导致整个系统瘫痪。3.2 基于 PIC32MZ 的协议栈选型与移植要点在 PIC32MZ1024EFE144 上做网络通信Microchip 官方提供了两套生态一套是老的 Microchip TCP/IP Stack现在叫 Microchip TCP/IP Stack V7.x另一套是更新一点的 MPLAB Harmony 框架。如果你是从零开始的新项目我强烈建议直接用 MPLAB Harmony因为它把外设驱动、中间件、协议栈全都做成了可视化配置工具生成的代码结构也更清晰。这里有一个实操层面的细节Harmony 生成的代码框架分层比较深App 层和 Driver 层之间的回调关系很多。新手第一次接触可能会觉得读代码很吃力但好处是可以避免自己写协议栈时遇到的各种底层坑。TCP/IP 协议栈不是玩具自己从头写一版能用的至少需要几周时间而且稳定性还得靠大量测试去砸。移植协议栈的关键步骤大致如下配置时钟树确认系统主频跑多少给外设分好时钟。PIC32MZ 的 USB 和以太网都依赖特定时钟源这步错了后面全错。配置引脚映射把 RMII 接口、UART、I2C 等外设对应到正确的引脚上。配置 Ethernet PHY根据你选择的 PHY 芯片型号在 Harmony 里选好对应的驱动。实现应用层任务创建 RTOS 任务或裸机状态机周期性地从温度采集模块拿数据塞进 TCP 报文或者 Modbus 寄存器。每一步看着不复杂但任何一个配置不对都可能出现编译通过但运行起来完全没反应的问题。我在这块调试到深夜的经历不少后面专门列一节讲常见问题和排查思路。3.3 本地数据存储与断网续传机制远程监测最怕的就是网络抖动。要是温度数据在传输过程中丢了轻则记录不完整重则错过一次关键的温度越限报警。所以我的做法是本地始终保留一份最近 N 天的温度记录云端只是这份记录的实时镜像。网络正常时就同步网络断了就在本地缓存等恢复后按时间戳补传。PIC32MZ1024EFE144 的 1MB Flash 里可以专门划出一块区域作为日志存储区。假设每小时记录一次温度一条数据占 8 字节时间戳 4 字节 温度值 2 字节 状态标志 2 字节1MB 的空间足够存十几万条记录也就是好几年的数据。当然Flash 读写次数有限制不能频繁擦写一般做法是“只追加、每小时攒一批再写”这样可以显著延长 Flash 寿命。这里的工程难点在于 Flash 磨损均衡和掉电保护。因为 Flash 是按扇区擦除的掉电时如果正好在写扇区容易出现半写的脏数据。我自己常用的方案是双扇区交替写入写前先写一个固定的魔数到扇区头读取时先检查魔数不合法就说明这个扇区数据无效自动切到另一个扇区。这个思路简单但可靠性很高。4. 温度采集与信号处理的工程细节4.1 NTC 还是 PT1000取决于你的测温范围在 HVAC 和嵌入式应用里接触到的温度传感器基本就是两类NTC 热敏电阻和 PT 系列铂电阻。这两类传感器的特性差别很大简单对比一下对比项NTC 热敏电阻PT1000 铂电阻测量范围典型 -40℃ ~ 125℃-50℃ ~ 500℃线性度较差需要查表或线性化较好但仍有非线性响应速度快较慢抗干扰能力较弱强成本低高典型应用室温、管温、板级测温风管温度、高温排气温度HVAC 系统里室温传感器和风管温度传感器用 NTC 比较多因为温度范围不大成本敏感而压缩机排气温度、热水系统温度这种高温场合则往往用 PT1000。PJ85718DM 如果支持配置传感器类型就可以灵活匹配这两种传感器这也是它在这种双场景系统里被选中的原因之一。4.2 信号调理与滤波电路设计要点不管用哪种传感器硬件层面有几件事必须做好去耦电容PJ85718DM 的电源引脚旁边一定要加 0.1uF 和 10uF 的组合电容距离引脚越近越好。HVAC 环境里经常有大功率继电器、变频器起停电源毛刺很严重去耦做不好会导致测量值跳变。传感器引线滤波如果传感器离主板比较远连接线上会感应到各种噪声。我的做法是在接口处加一个简单的 RC 低通滤波器截止频率设置在 10Hz 左右这样既能滤掉工频干扰又不会影响温度变化率的真实采集。屏蔽与走线信号线和电源线、驱动线要保持距离在 PCB 上尽量走内层或者用地线包裹。这不是玄学我遇到过好几次测温跳动最后定位到的原因就是信号线在 PCB 上绕了太远旁边就是继电器驱动线。这些细节在方案验证阶段可能看不出差别但在批量产和现场长期运行的时候差别非常明显。一台机器的读数稳定另一台不断波动往往就是因为这类看起来不起眼的设计差异。4.3 从 PJ85718DM 读温度数据时序与寄存器配置PJ85718DM 这类芯片通常提供标准的 I2C 或 SPI 接口读取流程大致是给芯片上电等待内部电路稳定通常需要几百毫秒。配置传感器类型、量程、转换精度等参数。触发一次温度转换或者等待芯片自动周期转换。从数据寄存器读取温度值按精度要求换算成实际温度。实际调试中有两件事容易出错第一转换时间不够就读取数据。有些芯片转换需要几百毫秒如果读得太快拿到的是上一次的旧值甚至是不完整的数据。我见过有人在这个问题上折腾了一整天最后才发现是多了一行毫无意义的延时就能解决。第二寄存器地址和位宽搞错。温度数据可能是 12 位、14 位或者 16 位分散在两个寄存器里。读取时先读高字节再读低字节的时序差异会导致拼接出来的数据完全不对。这里给后来者一点参考第一版驱动跑通后先弄一个固定的精密电阻箱或者已知温度的环境去验证读数确认芯片回读的值和实际温度对得上再去做后面的通信和显示功能。否则一旦错误数据流到了云端排查链路会非常痛苦。5. 软件逻辑从裸机状态机到 RTOS5.1 温度采集任务与主循环的调度设计PIC32MZ1024EFE144 的算力很强但在嵌入式系统里算力强不代表代码可以随便写。温度采集、通信上报、人机交互、按键响应这些任务如果调度不好很容易出现某个高优先级的操作频繁占 CPU导致温度采集和通信的时序抖动。裸机情况下我的习惯是做一个简单的“时间片轮询”结构把不同的功能拆成不同的函数通过一个调度计数器和时间片去挨个执行。比如每 10ms 执行一次按键扫描和 LED 刷新每 100ms 执行一次串口发送缓冲处理每 1000ms 执行一次温度采集和 PJ85718DM 数据读取每 5000ms 执行一次温度数据打包和网络上报。这样每个功能都被限定在自己固定的时间片里CPU 的负载不会突然冲到很高逻辑也清晰排查问题的时候可以按“时间片”去定位。如果你对系统的实时性要求更高或者需要同时跑多个有严格时序要求的模块那可以考虑上 RTOS。PIC32MZ 跑 FreeRTOS 很轻松任务切换的开销很小。把温度采集、通信、显示各分配一个任务用消息队列和信号量做同步代码结构会比超大的裸机状态机清晰很多。我的个人倾向是如果系统功能单一比如只做温度和上报裸机时间片就够了如果还要同时处理多种通信协议、多路传感器、报警联动等复杂逻辑直接用 RTOS别在裸机上硬扛。硬扛的结果就是代码越来越乱最后改一个功能到处崩。5.2 温度越限报警与历史曲线远程温度监测不能只报一个“当前温度”还要能设置上下限越限时触发本地报警和远程告警推送。这个逻辑看起来简单但设计时需要注意回滞区间比如上限设成 80℃不能一到 80.1℃ 就报警回到 79.9℃ 就撤销。温度轻微波动会导致报警反复抖动必须给报警阈值设一个回滞带比如超过 80℃ 触发回落到 78℃ 以下才复位。多级报警工业应用里通常分预警值和报警值两级。预警值提示“接近危险”报警值才触发停机或强拉措施。HVAC 场景下压缩机排气温度过高属于严重故障跟室温偏高是完全不同等级的告警处理动作也不一样。告警去抖连续多次采集超过阈值才确认告警避免单次毛刺误报。历史曲线方面如果接入了云平台曲线一般由云端绘制本地只需要按周期上报带时间戳的数据点如果本地 LCD 也要显示曲线那就需要自己实现一个简易的环形缓冲区把最近几十条数据存下来绘制时只用画一条横向滑动的折线即可。5.3 低功耗考量如果用在电池供电场景这个项目标题本身没有强调低功耗但在嵌入式温度监测场景里功耗往往是一个绕不开的话题。如果设备是由电池供电那么 MCU 的主频、外设的使能、PJ85718DM 的转换周期都要重新考虑。PIC32MZ1024EFE144 本身不是一颗超低功耗 MCU200MHz 主频全速跑的时候电流不小。如果你需要低功耗正确的姿势是大部分时间让 MCU 进入休眠模式只留 RTC 或外部唤醒源在运行。每隔一段时间醒来一次给 PJ85718DM 上电触发一次温度转换读回数据存到非易失存储然后继续休眠。通信模块不要在休眠期间一直供电可以改成“需要上报时才给模块上电上电后快速发送数据再断电”。这样整套系统的平均功耗可以压到很低。但要注意频繁启停通信模块也会引入稳定性和时间同步问题所以低功耗设计一定要和远程上报频率统筹考虑。6. 常见问题与排查技巧实录6.1 温度读数跳动剧烈这个现象在硬件调试阶段最常见。排查思路按下面几步来先把 PJ85718DM 拿到手单独测试确认芯片本身的 ori 输出是否稳定。如果芯片输入悬空或传感器没接好数据跳动是正常的。检查传感器的连接线和接口。如果传感器远离主板尝试用屏蔽线替代普通杜邦线看跳动是否消失。检查电源去耦电容是否靠近芯片引脚。如果去耦电容离得太远电源噪声会直接耦合到信号链路。降低采样速率或增加软件滤波。比如连续采样 10 次取平均或者用一阶低通滤波算法新值 旧值 × 0.9 原始值 × 0.1。软件滤波是应急手段但不能依赖它去掩盖硬件问题。硬件噪声没有处理好软件再怎么滤波也只是让数据“看起来稳定”而已真实温度变化时响应速度还会变慢。6.2 远程上报数据偶尔缺失但本地显示正常这个问题通常不是温度采集链路的问题而是通信链路的问题。可能的原因有TCP 连接被路由器或云端服务器静默断开。嵌入式设备如果长时间不发数据中间网络设备可能会回收这条连接。解决办法是维持一个 TCP Keep-Alive 或者应用层心跳报文。上报频率太密超出服务器处理能力或者通信模块的缓冲能力。解决办法是上报逻辑里加一个发送队列发送失败时进行重试和退避。多个设备同时上报目标服务器带宽被打满导致丢包。解决办法是客户端之间做随机时延错峰上报避免所有设备都在同一秒发数据。我在实际项目中遇到过一种特别隐蔽的情况设备的发送缓冲区满了但代码没有检查发送函数的返回值导致数据在本地队列里堆积越积越多最后整个通信任务卡死。这个问题的教训很简单任何对外通信都要检查返回值并且要有失败重试和队列溢出的处理逻辑不能默认一次发送就一定成功。6.3 PIC32MZ 程序跑飞或者偶发复位PIC32MZ 的复位源可以通过读寄存器查出来比如掉电复位、看门狗复位、非法指令复位等。对应排查方向是看门狗复位确认喂狗的位置是否放在了长时间阻塞的任务里。如果某一个操作的耗时不确定比如阻塞式网络发送而喂狗在它之后看门狗就会误复位。非法指令复位通常是指针越界、数组越界、或者函数指针错误。这种问题比较难查建议开启编译器的栈保护功能并且在调试阶段打开警告把任何可疑的指针操作都排查干净。供电电压跌落HVAC 设备里继电器吸合瞬间电源电压会被拉低如果 MCU 的供电没有足够的余量就会掉电复位。解决方法是加大电源电容或者在继电器触点并联 RC 吸收电路。这里我特别想强调一点调试嵌入式程序怀疑“硬件偶然问题”之前一定先把软件逻辑中的所有错误处理路径都走一遍。很多时候软件没有对异常情况做处理才导致系统进入异常状态而不是硬件真的出了问题。6.4 一张排查速查表异常现象优先排查方向常见解决手段温度读数跳动传感器接线、电源纹波、采样时序屏蔽线、加大去耦、软件滤波本地显示正常但云端缺数网络连接、心跳维持、发送缓冲加心跳、检查发送返回值、错峰上报MCU 偶发复位看门狗、供电跌落、指针越界查复位源寄存器、优化喂狗位置、加电源电容Modbus 通信时报错波特率配置、从机地址、CRC 计算用串口抓包工具确认报文、检查主从参数Flash 中历史数据乱码掉电写入中断、磨损均衡双扇区交替写入、魔数校验7. 项目实际心得与进阶扩展建议7.1 芯片选型与整体方案的取舍做了几个类似项目之后我的一个体会是温度监测系统的核心难点从来不在“测温度”本身而在“长时间稳定地测温度并且可靠地把数据送到该去的地方”。PJ85718DM PIC32MZ1024EFE144 这个组合其实代表了一种很典型的工程思路传感器接口这种脏活、累活交给专用芯片去处理MCU 只负责自己擅长的计算、控制和通信。这样既保证了温度测量的精度和稳定性又给上层应用留下了充足的可扩展空间。如果需要调整方案替换空间也很清晰想要更低成本可以把 PJ85718DM 替换成普通精密运放 MCU ADC代价是软件复杂度上升想要更简单的开发可以把 PIC32MZ 换成带无线功能的模组代价是有些场景下可靠性可能会下降。没有绝对最优的方案只有适不适合你当前的产品定位。7.2 关于 HVAC 场景长期运行的一点提醒HVAC 设备和普通消费电子产品最大的差距就是运行环境恶劣高温、高湿、振动、电压不稳、常年不断电。这种环境下每一颗电容、每一个连接器、每一行代码的异常处理都可能在某个极端天气的深夜变成故障。我的建议是在做环境测试时不要只做常温下的功能测试。把设备放到温度老化箱里跑上几百个小时模拟全温域范围内的采集精度用程控电源把供电电压拉到接近下限反复上下电看系统能否稳定恢复再模拟网络抖动看本地缓存与断网续传是否正常。这些测试做透比在代码里写一百个功能都更有价值。7.3 后续可以扩展的方向这个系统跑通之后很容易往下面几个方向扩展多通道温度采集用 SPI/I2C 级联多颗 PJ85718DM或者换成多通道版本实现几十路温度同时监测满足机房、仓库这类场景的需求。联动控制温度越限时直接驱动继电器、风扇或者压缩机启停形成闭环控制系统而不只是被动告警。云端可视化把数据上报到通用物联网平台生成温度曲线、报警记录、设备在线状态看板让运维人员远程就能掌握全局。边缘计算在 PIC32MZ 上跑简单的预测算法比如温度速率突变检测提前预判设备故障而不是等温度已经超标才反应。7.4 最后的几个落地建议每次做完一个类似的系统我都会回头检查这几件事温度标定是否做过多点校准、通信模块的异常恢复是否被完整测试过、断电重启后系统能否自动恢复工作、长期运行会不会出现内存碎片或者队列泄漏。如果这些问题都有明确的答案那么这个系统至少可以踏踏实实地放在现场跑很久。如果这些问题还有含糊的地方那趁着项目还在实验室阶段赶紧把这些坑先填完。我个人在这类项目里最深刻的一条经验是监控系统最容易出问题的不是温度采集的那一刻而是在异常情况下系统如何自愈。把这一点想清楚比把所有功能都堆到“演示视频里很完美”重要得多。
阅读完成 · 觉得有帮助？
