搞过HVAC控制器或者机房环境监测设备的朋友，应该都有这个体会：温度测点看着简单，真正布起线来全是坑。以前用NTC模拟量采集，线拉到二三十米，读数就飘得没法看，还要做冷端补偿、查分压表、逐点校准，现场工程师能调一整天。最近做一个空调箱监控项目，要把本地机柜温度、送风风道温度和几十米外机房的环境温度汇总到一块主控板上统一处理，我改用 PJ85718DM 数字温度传感器配 PIC32MX675F256L 做采集主控，整个调试过程顺了不少。这篇就把完整的方案架构、关键代码和现场踩坑记录整理出来，给做嵌入式测温和HVAC控制的朋友一个可直接参考的模板。

这套方案的定位很明确：本地测点用数字传感器直接挂在主控引脚上，远程测点通过 RS-485 总线回传，所有温度数据在 PIC32MX675F256L 里做滤波、校准、显示、上报，一套代码同时兼顾本地和远程。适合做空调箱控制器、冷库监控、数据机房动环板卡这类项目的开发人员，也适合刚接触 PIC32 平台想找一个完整外设例程的入门者。

1. 为什么这套方案能同时管好本地和远程温度

1.1 HVAC场景里的测点困境

供热通风与空气调节领域的温度监测，难的不是"读一个温度"，而是"在恶劣电磁环境和远距离布线下，稳定读多个温度"。空调箱旁边就是接触器、压缩机、变频器，一启动就是几十安培的电流变化，模拟量信号线在这种环境下特别容易被干扰。实测下来，用长线走 NTC 分压信号，线缆超过十米，示波器上就能看到明显的工频干扰和尖刺脉冲，ADC 采样值跳几十个字是常事。

另一个麻烦是校准。模拟传感器每个都有个体差异，同一批 NTC，常温下阻值能差百分之几，你想做到±0.5℃的精度，就得一个一个标定，把修正系数写进 EEPROM，产线效率低得让人头疼。数字温度传感器把敏感元件、ADC、线性校正全封装在芯片内部，出厂前已经校准过，单片机只需要按协议把温度字读出来，根本不用关心放大器和 ADC 的标定问题，这对批量生产意味着省掉一大块人工成本。

还有一点，HVAC 项目对"断电恢复"和"稳定运行"要求高。模拟量采集一旦电源纹波变大，读数就跟着波动，很容易误触发报警；数字量传感器只要通信时序稳定，读数一般不会突然跳变，逻辑上也好处理得多。

1.2 整体架构与数据流

这个项目的硬件分两个部分。主控制器用 PIC32MX675F256L，板上直接焊接两路 PJ85718DM 测本地温度：一路放在主控盒子里测机柜内环境温度，另一路用三芯屏蔽线引出，贴在空调箱送风风道外面测送风温度，长度不超过三米，单总线协议能扛住。远程测点放在几十米外的弱电机房，那里也有一块小板，同样用 PJ85718DM 采集机房环境温度，小板上的 MCU 通过 RS-485 把温度值传给主控。

为什么远程不直接用单总线长线？因为 PJ85718DM 这类单总线器件虽然能在两三米内稳定工作，拉到几十米后，线缆分布电容会让时序变形，遇上现场变频器干扰，通信失败率急剧上升。RS-485 是差分传输，共模抑制能力强，工业现场传输几百米都没问题，而且 HVAC 行业的上位机和楼宇自控系统普遍支持 Modbus RTU 协议，主控通过 RS-485 除了收远程测点数据，还能顺便把温度值上报给集中监控平台，一举两得。

数据流是这样的：远程小板每 500ms 读一次 PJ85718DM，把温度值按照 0.1℃ 为单位的整数存到寄存器里；主控作为 Modbus 主站，每隔 1 秒轮询一次远程从站，读出温度后再和本地两路温度一起做滤波和显示。温度超过设定阈值时，主控驱动继电器输出报警信号。整个过程全部由 PIC32MX675F256L 的 UART、定时器、GPIO 完成，不需要外加协议转换芯片。

2. 硬件选型与接线细节

2.1 传感器端的取舍：数字输出比模拟输出省心在哪

PJ85718DM 是一颗单总线接口的数字温度传感器，典型的测量范围覆盖 -55℃ 到 +125℃，在 -10℃ 到 +85℃ 这个 HVAC 最常见的区间里，精度标称 ±0.5℃，分辨率可以通过配置寄存器选择 9 到 12 位。这个精度水平用在空调箱送回风温度监测、机房环境温度告警场景下，绰绰有余。

选这颗料还有个现实考虑：单总线只需要一根数据线，主控这边省引脚。PIC32MX675F256L 虽然引脚不少，但一个项目里要接 LCD、按键、RS-485、继电器驱动、DI 输入，引脚资源并不宽裕。一个传感器占一个 GPIO，两路本地加上远程，总共才占三个引脚，比 I2C 还要省事，因为每个 I2C 设备还要分配地址。

接线上有几个容易被忽略的细节。单总线数据引脚必须接上拉电阻，阻值选 4.7kΩ 比较稳妥，如果线缆略长或者线上挂的设备多，可以降到 2.2kΩ。数据线走线尽量避开继电器输出和电源线，特别是高压侧，实在躲不开就加屏蔽层，屏蔽层单端接地。供电方面 PJ85718DM 支持 3.0V 到 5.5V，这个项目里主控是 3.3V 供电，传感器直接挂 3.3V 就行，数据线和 MCU 引脚电平天然匹配，省了电平转换电路。

2.2 主控端的底气：PIC32MX675F256L 的外设够不够用

PIC32MX675F256L 是 MIPS M4K 内核的 32 位 MCU，主频最高 80MHz，Flash 256KB，RAM 64KB。放在 HVAC 控制器这个场景里，性能是明显过剩的，但"过剩"恰恰是好处：跑 Modbus 协议栈、移动平均滤波、LCD 刷新全部毫无压力，剩余资源还可以做日志存储和故障记录。

外设配置我看了一下是够用的。它带六个 UART，一个做 RS-485 与远程从站通信，一个做调试日志输出，还有富余；带两个 I2C 和一个 SPI，接 LCD 和 EEPROM 没问题；带 CAN 2.0B 控制器，如果业主方要求改成 CANopen 总线，硬件不用动，只改软件协议就行；支持 DMA，后续想把温度数据批量搬运到内存做分析，可以省掉 CPU 中断开销。

选型时对比过其他平台，最后定 PIC32MX675F256L 主要是看重两点。一是它的 UART 带有硬件流控引脚映射，RS-485 的收发方向切换可以直接用通用 GPIO 控制，时序做得很干净；二是这个芯片的参考手册和库函数比较完整，寄存器配置清晰，裸机开发时不用猜初始化顺序。唯一要适应的就是 MIPS 内核的中断模型和 ARM 不太一样，刚开始会有个学习曲线，后面我会专门讲一下这里面的坑。

2.3 本地与远程节点的接线设计

主控板供电采用 HVAC 项目里最常见的 24V 直流输入，经过 DC-DC 降压到 5V，再经 LDO 降到 3.3V 给 MCU 和传感器供电。RS-485 收发器建议选带限流保护的型号，A、B 引脚对地各加一个 TVS 管，因为现场总线上可能接入其他设备，免不了遇到共模电压异常的情况。总线末端（最远端从站）并接一个 120Ω 终端电阻，主控端一般不接，以免和多个从站组成复杂拓扑时阻抗不匹配。

本地两路 PJ85718DM 的 DQ 引脚分别接主控的 RD0、RD1，每路各配一个 4.7kΩ 上拉到 3.3V。传感器到主控的线缆用双绞线或者屏蔽线，屏蔽层在主控端单点接地，另一端悬空，这样现场变频器高速开关产生的高频干扰能被屏蔽层导走。

远程从站小板也做得很简单：一颗小体积 MCU（我直接用同系列的 PIC32MX675F256L，方便复用代码）、一颗 PJ85718DM、一颗 RS-485 收发器、一个隔离电源模块。从站电源从现场 24V 取电，用 DC-DC 隔离出来，避免地回路导致 RS-485 通信异常。这个隔离设计看着多花二十块钱，但能在现场省掉大量排查通信问题的工时，非常值。

3. 软件实现：从读温度到上报远程数据

3.1 工程框架与初始化流程

开发环境用 MPLAB X IDE 加 XC32 编译器，调试器用 ICD4。工程结构上我习惯裸机编程，不用 Harmony 框架，因为项目逻辑不复杂，裸机更容易控制每一行代码的执行时机，出了问题也容易定位。系统启动后，按下面的顺序初始化：关闭看门狗 → 配置时钟 → 初始化 GPIO → 配置定时器 → 初始化 UART → 初始化 LCD → 开中断 → 主循环。

时钟配置是第一步，也是最容易出问题的。使用外部 8MHz 晶振，通过 PIC32MX675F256L 内部的 PLL 倍频到 80MHz，外设总线时钟（PBCLK）分频为 40MHz。设备配置位写成下面这样：

#pragma config FNOSC = PRIPLL #pragma config POSCMOD = HS #pragma config FPLLIDIV = DIV_2 #pragma config FPLLMUL = MUL_20 #pragma config FPLLODIV = DIV_1 #pragma config FPBDIV = DIV_2 #pragma config FWDTEN = OFF #pragma config JTAGEN = OFF

外部晶振 8MHz 先经过 PLL 输入分频除到 4MHz，20 倍频到 80MHz，输出分频 1，得到 80MHz 系统主频；再经过外设分频 2，得到 40MHz 外设时钟。UART 波特率生成器和定时器全都基于 40MHz 计算。

主循环的结构很直白：

while (1) { local_temp[0] = read_temp_sensor(0); local_temp[1] = read_temp_sensor(1); remote_temp = read_modbus_remote_temp(); filtered[0] = temp_filter(local_temp[0], 0); filtered[1] = temp_filter(local_temp[1], 1); filtered[2] = temp_filter(remote_temp, 2); lcd_display(filtered); relay_check(filtered); ClrWdt(); }

主循环里有一句 ClrWdt() 非常重要。如果传感器在总线上没响应，读温度函数的阻塞等待时间会拖长，不喂狗的话系统就被无故复位了；喂狗太早也不行，必须在主循环末尾喂，保证一个周期内所有操作都完成了。

3.2 传感器驱动与数据校验

PJ85718DM 的单总线时序和常见的数字温度传感器方案基本一致。整个驱动可以拆成四个函数：复位脉冲、写字节、读字节、读温度。核心时序用延迟函数自己控制，不依赖硬件定时器。

先看引脚配置。DQ 引脚设置为开漏输出，外部 4.7kΩ 上拉保证静态高电平。读数据的时候把引脚切到输入模式采电平，写数据的时候切到输出模式拉低或拉高，这个切换必须在时序要求的纳秒级时间内完成，PIC32 的 IO 操作够快，实测不会丢时序。

#define DQ_TRIS TRISD #define DQ_LAT LATD static inline void dq_output_mode(void) { DQ_TRIS &= ~(1 << 0); } static inline void dq_input_mode(void) { DQ_TRIS |= (1 << 0); } static inline void dq_low(void) { DQ_LAT &= ~(1 << 0); dq_output_mode(); } static inline void dq_high(void) { DQ_LAT |= (1 << 0); dq_output_mode(); } static inline uint8_t dq_read(void) { dq_input_mode(); return (PORTD >> 0) & 1; }

复位时序必须严格按照 480μs 低电平、释放、等待从设备拉低 60μs 来写。实际调试时，如果示波器看不到从设备的存在脉冲，优先怀疑的就是低电平时间不够长，或者引脚配置不是开漏输出。我习惯把复位写成带超时的函数，避免从设备没接时主控死等：

uint8_t pj_reset(void) { uint32_t timeout = 0; dq_low(); delay_us(500); dq_high(); delay_us(30); if (dq_read() == 0) { while (dq_read() == 0) { if (++timeout > 200) return 0; delay_us(1); } return 1; } return 0; }

读温度的函数流程是：复位 → 发送跳过 ROM 命令 0xCC → 发送启动温度转换命令 0x44 → 等待转换完成（12 位分辨率需要约 750ms）→ 复位 → 发送 0xCC → 发送读暂存器命令 0xBE → 连续读 16 个字节（低 8 位温度、高 8 位温度、配置字节和 CRC 校验位）。温度值拼接成 int16_t 后，右移 4 位就是实际温度的整数部分，小数部分看低 4 位，0.0625 摄氏度为一个 LSB。

CRC 校验不能省。总线现场干扰会导致数据错误，不校验的话可能在屏幕上显示一个完全错误的高温值，触发误报警。PJ85718DM 的 CRC 多项式是 X^8+X^5+X^4+1，也就是常见的单总线 CRC 算法，我直接用了查表法，速度足够：

uint8_t crc8(uint8_t *data, uint16_t len) { uint8_t crc = 0; for (uint16_t i = 0; i < len; i++) { crc ^= data[i]; for (uint8_t j = 0; j < 8; j++) { if (crc & 0x80) crc = (crc << 1) ^ 0x31; else crc <<= 1; } } return crc; }

校验失败时直接丢弃这一次的读数，保留上一次的有效值。连续失败超过 5 次，才判定传感器链路异常并报警，这就不会因为偶发的干扰导致系统误动作。

3.3 滤波与本地显示

现场的温度波动分两类：一类是真实的环境温度变化，比如空调箱送风温度随压缩机启停周期性起伏，这类变化是正常的，不需要滤掉；另一类是瞬态干扰造成的采样毛刺，比如变频器启动瞬间传感器电源被拉低，读数突然跳高 8 度，这一类必须滤掉。

我用了"异常值剔除 + 移动平均"两级滤波。先判断本次采样值和历史平均值的偏差，如果超过 5℃，直接判定为无效采样，不参与平均；有效值才进入一个长度为 8 的环形缓冲区，每来一个新值，就计算缓冲区平均值作为输出。这个算法在风机启停、压缩机吸合的条件下，温度输出波动能控制在 ±0.3℃以内。

#define TEMP_BUF_N 8 float temp_filter(float raw_value, uint8_t ch) { static float buf[3][TEMP_BUF_N]; static uint8_t idx[3] = {0, 0, 0}; static uint8_t filled[3] = {0, 0, 0}; float sum = 0; for (uint8_t i = 0; i < TEMP_BUF_N; i++) { sum += buf[ch][i]; } float avg = filled[ch] ? sum / TEMP_BUF_N : raw_value; if (fabsf(raw_value - avg) > 5.0f) { return avg; } buf[ch][idx[ch]] = raw_value; idx[ch] = (idx[ch] + 1) % TEMP_BUF_N; if (!filled[ch]) filled[ch]++; return avg; }

注意这个滤波函数里有个细节：环形缓冲区初始状态全零，直接平均会把第一个有效读数拉低。所以我用一个 filled 标志位来区分"缓冲区还没有填满"和"已经填满"两种状态。实测中如果在第一次上电时不做这个处理，温度显示会在启动后两秒内出现一个明显的低谷，看着像故障，实际上是滤波逻辑的 bug。

显示部分用的是 I2C 接口的 1602 字符模组。第一行显示本地两路温度，第二行显示远程温度和通信状态。LCD 刷新频率控制在一秒一次，太频繁会导致字符闪烁，而且在现场看温度本来就只需要一秒量级的刷新率。

3.4 远程上报：UART转RS-485与Modbus RTU实现

远程从站通信基于 Modbus RTU 协议，主控作为主站，远程小板作为从站，功能码用 0x04 读输入寄存器。为什么不用 0x03 读保持寄存器？因为温度是只读量，逻辑上用输入寄存器更规范，而且有的上位机系统会自动轮询 0x04，用同一个功能码可以减少上层配置工作。

UART 初始化配置为 9600、8、N、1，9600 波特率在 RS-485 现场总线上的传输距离和抗干扰性平衡得比较好。系统主频 80MHz、外设时钟 40MHz，UART1 波特率寄存器计算如下：

U1BRG = (40000000 / (16 * 9600)) - 1;

算出来等于 259.4，取整为 259，实际波特率约 9615bps，误差约 0.16%，远在 Modbus RTU 允许的 ±2% 范围内，通信非常稳定。如果改用 19200，U1BRG 计算值是 129.2，取整误差会稍大一点，但也够用。

Modbus 主站的轮询写成状态机，不搞阻塞等待。发送完请求帧之后，把 UART 接收中断打开，同时启动一个 100ms 超时定时器；收到完整响应帧或者超时后，再回到空闲状态准备下一轮轮询。这样即使从站断电，主控也不会卡在某个 while 循环里等数据，看门狗不会乱复位。

发送一帧轮询请求的代码展开就是这样：

uint8_t modbus_request_frame[8] = { 0x01, // 从站地址 0x04, // 功能码：读输入寄存器 0x00, 0x00, // 起始寄存器地址 0x00, 0x01, // 寄存器数量 0x00, 0x00 // CRC16 占位 };

CRC16 计算函数是 Modbus 标准多项式 0xA001，初始值 0xFFFF。需要注意发送时 CRC 的低字节在前、高字节在后，很多人第一次写都栽在这个字节序上：

uint16_t modbus_crc16(uint8_t *buf, uint16_t len) { uint16_t crc = 0xFFFF; for (uint16_t i = 0; i < len; i++) { crc ^= buf[i]; for (uint8_t j = 0; j < 8; j++) { if (crc & 0x0001) crc = (crc >> 1) ^ 0xA001; else crc >>= 1; } } return crc; }

从站响应帧是 7 个字节：从站地址、功能码、字节数、16 位温度值的高字节和低字节、CRC16 低字节和 CRC16 高字节。温度值用有符号整数表示，单位 0.1℃，例如读取到 0x00C8 就是 20.0℃。收到帧后先做 CRC 校验，再做地址和功能码校验，全部通过后把温度值存入全局变量。

还有个工程师容易忽略的点：RS-485 收发器的收发方向切换必须严格卡住时序。主控发送完最后一个字节、进入接收模式前，要留 500μs 左右的延时，让总线上最后一个字节完整发出。如果切换太快，最后一个字节可能被截断，从站根本收不到完整帧。

4. 工程实操记录：从开板到跑数

4.1 开发环境与烧录工具

开发环境我直接用的 MPLAB X IDE，版本支持 PIC32MX 系列即可，编译器用 XC32。工程建好后，第一步不是写应用代码，而是先用一个空工程把时钟配置跑通，确认系统主频稳定在 80MHz。用 ICD4 调试器连接目标板，在调试窗口看系统时钟寄存器的实际值，同时用一个 GPIO 输出一个方波，接示波器测频率，就能确认 PLL 配置是否正确。

烧录时注意 PIC32 的上电时序。如果目标板上的 MCLR 引脚接了外部复位电容，首次烧录可能因为电容充电太慢导致 ICD4 连不上。遇到这种情况，把复位电容暂时拆掉，烧录成功后再焊回去。这是我在几个项目里踩过不止一次的坑。

4.2 上电调试的先后顺序

给板子上电之前，先量电源对地阻抗，确认没有短路。上电后第一步不写任何应用代码，只点一颗 LED，确认最小系统能跑。然后用示波器看 8MHz 晶振波形，晶振起振正常再配置 PLL。PLL 配置有问题时，系统主频不对，UART 波特率全是乱的，就像收音机没调准台，然后看什么都觉得是通信代码的问题，实际上根源是时钟。

传感器调试单独做。先用逻辑分析仪抓单总线波形，检查复位脉冲、存在脉冲、读时序的时间参数。PJ85718DM 这类单总线传感器的时序都是微秒级的，用逻辑分析仪比示波器直观，一个采样率 24MHz 左右的逻辑分析仪就够用。波形抓对了，再写代码把温度值打印到调试串口。

远程通信调试时，先不接远程从站，主控发轮询帧，用 RS-485 转 USB 工具在总线上抓包，确认主站发出的 Modbus 帧 CRC 是否正确、地址是否匹配。之后再接从站，用同样的工具确认响应帧格式。这种逐级排查的方法，看起来慢，实际上比一次把全部设备接上再瞎猜快得多。

4.3 温度校准与精度修正

PJ85718DM 出厂前已经校准过，但系统级精度还会受传感器安装位置和热阻影响。比如传感器贴在风道管壁外侧测的是管壁温度，和管内空气温度必然有偏差；传感器放在主控盒子角落，和机柜中心温度也有梯度差。所以系统装好后要做一次整体校准。

校准方法我用的是两点法。第一点：把传感器探头和精密测温仪的探头绑在一起，放进冰水混合物中，等读数稳定后记录偏差，记做偏移量。第二点：把探头放到恒温箱，设定 45℃（HVAC 夏季送风温度上限附近），稳定后记录读数。两点之间做线性修正，把修正公式写进固件：

display_temp = (raw_temp * slope) + offset;

其中斜率根据两点实测值计算，偏移量等于测量值减去标准值的差。实测下来，经过两点校准后，系统在 10℃ 到 40℃ 区间的误差可以控制在 ±0.2℃ 以内，远高于 HVAC 控制的要求。

还有个小技巧：校准系数要保存到外部 EEPROM 或 Flash 数据区，不要写死在代码里。现场安装位置变了，热阻变了，只需要在小键盘上输入新的修正值，不用重新编译固件。这个细节在量产和后期运维阶段能省大量时间。

5. 常见问题与排查技巧

5.1 传感器读数为全F或错误值的处理

PJ85718DM 读回 0xFFFF 或者 0x7FFF，绝大多数情况不是传感器坏了，而是时序不对或者总线状态不对。我用逻辑分析仪排查时发现，最常见的原因是复位后的存在脉冲检测逻辑写错了：释放总线后，应当在 30μs 到 60μs 之间检测从设备拉低的信号，如果这个窗口没抓住，后面所有时序都白搭。

其次检查上拉电阻。忘记焊接上拉电阻时，总线一直处于低电平，复位后从设备根本没有供电逻辑，自然返回错误。用万用表量 DQ 引脚对地电压，正常待机状态下应该为高电平。如果量到 0V，先查上拉电阻而不是查代码。

还有一种情况是用了错误的引脚映射。PIC32 的引脚多功能复用，容易被其他外设抢占。排查时建议先只初始化 GPIO，不初始化其他外设，看传感器能不能读通，读通了再打开其他外设，这样可以快速定位是不是引脚冲突。

5.2 温度读数跳变的真正原因

滤波函数已经处理了大部分毛刺，但偶尔还是会有跳变。用示波器抓传感器供电脚的波形，发现变频器启动瞬间，3.3V 电源上叠加了一个几十毫伏的跌落。传感器的模拟电路对电源变化是敏感的，电源瞬时跌落会导致内部 ADC 转换结果异常。

解决分两头：硬件上在传感器供电引脚就近加 10μF 钽电容和 0.1μF 陶瓷电容，并联使用，低频高频干扰一起滤；软件上把滤波窗口从 8 个点提升到 16 个点，同时把异常值判定阈值从 5℃ 收紧到 3℃。改完之后，连续跑一个星期，没有出现误报警。

这里有一个矛盾点要提醒：滤波窗口太长，真实温度变化会被"拉平"；太短，毛刺滤不掉。HVAC 的温度变化本身就是慢变量，一分钟能变 1 度就算快了，所以窗口拉长到 16 个点完全不影响系统响应，这是 HVAC 场景对滤波算法友好的地方。

5.3 RS-485通信异常的排查

现场 RS-485 通信不稳定，先看接线拓扑。高速率长距离的总线，要求从设备"手拉手"菊花链连接，不能星型。现场经常有电工师傅图省事，把每台设备的 A、B 线并在一起接到主控，看起来连通了，实际上信号反射严重，通信误码率居高不下。

第二查终端电阻。总线上只应该在最远端加一个 120Ω 终端电阻，如果在主控端和从站端都加了，总线负载变重，驱动能力不够，反而通信距离变短。之前一个项目就是两端都接了 120Ω，通信距离从一百多米缩短到十几米，去掉主控端那个电阻后问题马上消失。

第三查地电位。RS-485 虽然不需要共地也能跑，但对共模电压有上限，超过 -7V 到 +12V 范围就会损坏收发器。两个设备分别用两个开关电源供电，地之间电位差大的时候，稳定运行全靠隔离。远程从站板用了隔离电源模块之后，再也没有因为地环路问题导致收发器烧毁。

5.4 看门狗误复位的解决

主控开了看门狗，但现场频繁复位。抓日志发现每次都发生在轮询远程从站超时的时候。原因是我最初把 Modbus 轮询写成了阻塞式：发送帧后用一个 while 循环等待响应，从站掉电时这个循环要等 3 秒超时，主循环里的喂狗语句执行不到，看门狗就复位了。

后来改成状态机加定时器的方式，每次进入状态机的处理函数不超过 1ms，即使从站完全无响应，主循环也能正常运行并喂狗。同时给传感器读取也加了超时计数，PJ85718DM 总线上的任何等待都不超过 100μs 无条件退出。这样看门狗只负责检测真正的主循环"饿死"场景，不再被异常外设阻塞误伤。

6. 这个项目还能怎么扩展

把主题之外的一些扩展思路也分享一下。如果现场要求把温度数据直接上传到云平台或工业物联网网关，PIC32MX675F256L 有足够的资源挂一个以太网控制器或 SPI 接口的 Wi-Fi 模块，在现有固件基础上增加一个 MQTT 任务并不复杂。如果总线上要挂多个远程从站，Modbus 从站地址从 1 扩展到 247 就可以了，主控固件只需把轮询地址表改成长度可配置的数组。

如果要采集湿度、压力、风速这类信号，我建议传感器的数字接口尽量统一。能找数字输出的就用数字输出的，实在只能模拟量采集的再加独立的高精度 ADC，避免把模拟信号线和数字通信线混在一起布线。这个原则在当前项目的 PCB 改版中起到了明确指导作用。

最后想说的是，这套方案的难度不高，能稳定跑下来，核心不在于某个算法有多玄妙，而在于每个环节都把"异常情况"考虑周全了：传感器总线超时怎么办、Modbus 从站失联怎么办、电源抖动怎么办、滤波缓冲区初始值怎么办。把这些边界条件都处理掉，系统自然就稳定了。我在几个现场项目里实测下来，PJ85718DM 加 PIC32MX675F256L 这个组合，在 HVAC 温控和嵌入式环境监测场景里，不管是性能、成本还是调试友好度，都非常值得纳入备选方案。如果你正在选型，不妨拿这个思路在自己板子上先跑一个最小原型，感受一下数字温度传感器和 Modbus 总线配合的省心程度。