1. 项目核心拆解H标签里的“本地”和“远程”到底指什么“用 PJ85718DM 和 PIC32MX795F512L 做本地与远程温度监测”——这句话在嵌入式和暖通圈子里听起来挺顺但真落到现场第一版设计最容易翻车的就是对“本地”和“远程”这两个词的误解。PJ85718DM 本质上是一款和 DS18B20 指令级兼容的单总线数字温度传感器精度 ±0.5℃测温范围覆盖 -55℃ 到 125℃PIC32MX795F512L 则是 MIPS M4K 核的 32 位 MCU80MHz 主频、512KB 闪存、128KB RAM还带了以太网 MAC、USB、CAN 和五个 UART。这个组合最常见的落点就是 HVAC供热通风与空调系统的温度采集节点以及嵌入式设备内部的温度健康监测。先说清楚“本地”和“远程”在项目里的实际含义。在 HVAC 场景里本地温度通常是指靠近控制器主板的回风温度、机柜内部温度或者控制面板旁边的室内温度远程温度则是布置到几十米外风管末端、冷水管道表面、室外机散热器或者洁净室吊顶内部的探头。在通用嵌入式场景里本地是 PCB 板上传感器远程是电池盒附近、线缆末端、 电机绕组外侧这些“手够不着”的位置。用单总线方案做的好处非常明显一条总线可以挂几十个传感器每个传感器有唯一 64 位 ID主机通过 ROM 指令精确寻址本地探头和远程探头挂在同一条总线上不需要给远端单独拉电源线。这里要先纠正一个常见误区很多人一看“远程温度”就想到无线实际项目中 80% 的远程采集用有线单总线就够了。无线要解决供电、配对、干扰、频段合规一堆问题成本远高于一根双绞线。本文这套方案里PIC32MX795F512L 负责总线调度、温度换算、本地显示和远程上报PJ85718DM 负责把物理温度变成数字量两者用单总线协议连接硬件成本控制在几十块钱以内非常适合设备厂商做成本敏感的 HVAC 控制器。这个项目适合谁来参考如果你是做 HVAC 控制器的嵌入式工程师或者在学校做嵌入式课程设计的同学再或者是做冷链监测、机房环境监测的开发者这套方案可以直接抄作业。文章会把硬件选型理由、单总线时序、PIC32 侧代码框架、远程上报协议、现场踩坑经验全部拆开讲而不是只贴一段 datasheet 了事。2. 硬件选型解析为什么是 PJ85718DM为什么是 PIC32MX795F512L2.1 PJ85718DM 的关键参数与内部结构PJ85718DM 是单总线数字温度传感器封装常见的是 TO-92也有 SOIC-8 和打线芯片形式。它的电气特性和指令集和 DS18B20 兼容这意味着市面上所有现成的单总线驱动逻辑基本都能直接用省去了一大半移植工作量。传感器内部有三个主要部分64 位激光 ROM 序列号、温度传感器元件、报警触发寄存器TH/TL和配置寄存器。它的温度分辨率可以通过配置寄存器设置成 9 到 12 位对应精度从 0.5℃ 到 0.0625℃。默认上电一般是 12 位分辨率一次温度转换时间最长 750ms。这个时间在 HVAC 控制里完全够用因为空调系统的温度环本身就不需要 10ms 级别的响应。下面整理一份关键参数表格工程选型时可以对着看参数项数值/说明供电范围3.0V - 5.5V支持寄生供电模式测温范围-55℃ 到 125℃精度-10℃ 到 85℃ 范围内典型 ±0.5℃分辨率9/10/11/12 位可配置默认 12 位转换时间12 位模式下典型 750ms总线方式单总线 1-Wire漏极开路唯一 ID64 位激光 ROM支持多传感器寻址典型封装TO-92 / SOIC-8选它而不是选 I2C 的温度传感器核心原因是单总线的拓扑优势。I2C 的地址一般只有 7 位同型号芯片挂第二颗就要改地址引脚挂三颗以上就很麻烦而单总线传感器靠 64 位 ID 区分总线上挂几十颗都不需要额外地址引脚线缆也只要一根数据线加一根地线。在 HVAC 项目里远端风管探头分布在几十米范围内单总线从接线、布线和驱动复杂度上都明显优于 I2C。2.2 PIC32MX795F512L 外设资源盘点PIC32MX795F512L 在 Microchip 的 PIC32MX 系列里属于“大而全”的型号TQFP-100 封装内部外设资源非常充裕5 个 UART、2 个 SPI、2 个 I2C、6 通道 DMA、USB 2.0 OTG、CAN 2.0B以及 10/100 以太网 MAC。这些外设刚好覆盖了 HVAC 控制器的典型需求UART 接触摸屏或调试口CAN 接楼宇总线以太网做远程上报SPI 接 LCD 或者 Flash 存储。为什么是这一颗而不是更低端的 PIC18F 或者 STM32第一512KB 闪存和 128KB RAM 在跑单总线协议栈、Modbus 从站、实时操作系统和显示驱动时非常从容。第二以太网 MAC 是内建的外置只需要一颗 PHY 芯片对做远程温度上报是极大的成本优势。第三这颗芯片自带足够多的定时器单总线时序模拟即使完全关中断也不影响其他任务的调度——前提是你给它分配一个空闲的高优先级通道。MCU 和传感器之间的配合也很关键。PIC32 的 GPIO 输出速率足够快到 1-Wire 标准时序要求1-Wire 标准时序最小写时隙是 60μsPIC32 跑在 80MHz一个 NOP 大概是 12.5ns即便用延时函数也能轻松控制到微秒级精度。实际项目里不建议用纯延时轮询更稳的做法是用定时器捕获这部分在第四章的固件设计里展开。2.3 方案选型的代价与冗余考虑这套组合并不是没有短板。PIC32MX795F512L 是 3.3V 器件PJ85718DM 支持 3.0V 到 5.5V直接 3.3V 供电没问题但如果你要兼容老的 5V 系统就必须仔细检查上拉电平和 IO 电平转换。另一个短板是单总线时序依赖软件模拟MCU 和传感器之间没有硬件控制器时序处理不好就会出现偶发读错、甚至找不到设备。针对这些短板项目设计时做了三个冗余。第一总线数据线串一个 100Ω 电阻防止远端线缆反射第二每路探头都预留了独立的 ESD 保护二极管位置第三PIC32 的程序存储器里做了两个版本的驱动参数表一套标准时序一套慢速时序现场如果碰上长线缆导致时序余量不足直接切换参数表重新校准不用重新编译。3. 硬件连接与线缆规划决定系统稳不稳定的都在这一层3.1 单总线电路设计要点单总线的基本电路就是一个漏极开路输出加一个上拉电阻传感器数据引脚直接并到同一条总线上。上拉电阻的选择是个大学问阻值太小低电平拉不下去总线被远端长线缆的等效电容拖慢阻值太大高电平建立缓慢时序边沿不满足要求。常规情况下用 4.7kΩ总线长度超过 20 米建议用 2.2kΩ超过 50 米建议 1kΩ 配合屏蔽双绞线。推荐一个我实际验证过的电路配置PIC32 的 GPIO 口配置为开漏输出或者推挽输出取决于你用的是哪个引脚组外部接 2.2kΩ 上拉到 3.3V同时并联一个 100pF 到 220pF 的电容做高频滤波。注意这个电容不能太大太大会影响时序上升沿。数据线和地线之间加 TVS 管型号随便选一款低电容的比如 5V 双向的就可以防止 HVAC 现场静电耦合打坏传感器。在杂散电磁环境很强的设备房里总线入口处还要加一个共模电感。别觉得一个温度传感器不需要这么讲究实际项目里我曾经遇到过总线数据线上感应的 50Hz 工频干扰表现为温度读数周期性跳动后来就是靠共模电感和屏蔽层单端接地解决的。总线屏蔽层只能在一端接地两端接地会形成地环路地环路在 HVAC 大功率设备启动瞬间能感应出几十伏的瞬态电压。3.2 本地传感器和远程传感器的接线拓扑本地传感器可以有两种接法。位置允许的话直接把 TO-92 封装焊接在 PCB 上数据引脚连到 MCU 的 GPIO如果探头要安装在机箱前面板用一条三芯排线连接供电、地、数据各一根排线长度控制在 30 厘米以内避免排线过长造成信号反射。远程传感器的接法要更讲究。建议使用带屏蔽的双绞线其中一对双绞线的一根走数据另一根接地屏蔽层再单独接地。电源线可以选择独立的一根线也可以采用寄生供电模式省掉这根电源线。需要说明的是寄生供电模式下传感器从数据线吸收电流给内部电容充电转换期间主机必须把总线拉高否则转换中途掉电会导致读回 85℃ 的固定错误值。HVAC 现场我强烈建议使用外部供电模式也就是数据线、地线、电源线各一根原因有两个一是寄生供电在长线上容性负载大容易供不上电二是电源线可以给传感器提供稳定电压转换精度更高。总线上同时挂本地和远程传感器时要注意信号反射。理论上单总线的末端应该接一个匹配电阻但实际上多传感器分叉布线时没法做标准匹配靠的是每个分支线不要过长、总线总长度控制在 100 米以内。如果现场超过 100 米建议把总线分成两段中间加一个单总线中继器或者用第二路 GPIO 单独驱动远处那一段这就是设计里预留多路 GPIO 的原因之一。3.3 供电策略与功耗估算整板用 3.3V 给 PIC32 和传感器供电PJ85718DM 静态功耗大概 1μA转换时的峰值电流到 1mA 级别几十个传感器加上去整体功耗也就是几十毫瓦。但如果系统里还有继电器、风阀执行器就要考虑分开供电模拟/数字小板用 3.3V执行器用 24V 或 12V 单独供电中间用光耦或继电器隔离。温度采集回路的地和功率回路的地要在单点连接防止大电流在地线上产生压差导致传感器读数偏移。4. 固件实现单总线时序、寻址和稳定读取的全套写法4.1 单总线协议的三层操作单总线协议从底层到上层分成三块时序层负责读写 0 和 1命令层负责复位、存在检测、ROM 命令、功能命令应用层负责启动温度转换、读取暂存器、计算 CRC。每条 PJ85718DM 都内置 64 位唯一序列号主机可以发起 Skip ROM 命令不对地址直接广播给总线上所有传感器也可以根据序列号 Match ROM 只唤醒某一个传感器。做多传感器采集必须用 Match ROM否则所有传感器同时应答数据线直接冲突。具体流程是复位脉冲主机拉低 480μs 以上释放后等待存在脉冲→ 发送 ROM 命令通常先 Search ROM 枚举总线上所有序列号→ 发送功能命令启动温度转换→ 延时等待转换完成 → 复位 → Match ROM 选中目标传感器 → 发送读暂存器命令 → 逐字节读取 9 字节数据。9 个字节包含温度低字节、温度高字节、报警上下限、配置寄存器、保留字节、CRC 校验字节。读取完成之后用 CRC8 多项式 x^8x^5x^41 做校验防止数据被干扰篡改。4.2 PIC32 上的时序实现与中断处理PIC32MX795F512L 没有硬件单总线控制器时序全靠 GPIO 翻转加延时。标准单总线时序要求如下12 位分辨率、外部供电模式复位低电平 480μs - 960μs复位后释放总线主机采样存在脉冲写时隙最少 60μs写 0 时拉低整个时隙写 1 时拉低 1-15μs 后释放读时隙主机拉低 1-15μs 后释放在时隙开始后 15μs 内采样总线状态。这些参数对 PIC32 来说非常宽松。工程上的关键是延时精度。用系统定时器做微秒级延时不要用软件空循环因为编译器优化等级变了、时钟频率变了空循环的时间就走样。我在项目里用 Timer1 做 1μs 基础时基读取时序时禁止全局中断每次读写时隙完成后再恢复中断。禁止中断的时间窗口只有 60-100μs对实时操作系统的影响很小。驱动代码的框架可以用这样的结构typedef struct { volatile uint32_t *port; uint32_t pin; uint32_t tris; } onewire_bus_t; uint8_t ow_reset(onewire_bus_t *bus) { uint8_t presence 0; OW_PIN_OUT_LOW(bus); delay_us(500); OW_PIN_OUT_HIGH(bus); delay_us(60); OW_PIN_IN(bus); presence OW_PIN_READ(bus); delay_us(420); return presence; // 0 表示存在1 表示无设备 } uint8_t ow_read_bit(onewire_bus_t *bus) { uint8_t bit 0; OW_PIN_OUT_LOW(bus); delay_us(2); OW_PIN_OUT_HIGH(bus); delay_us(8); bit OW_PIN_READ(bus); delay_us(50); return bit; } void ow_write_bit(onewire_bus_t *bus, uint8_t bit) { if (bit) { OW_PIN_OUT_LOW(bus); delay_us(5); OW_PIN_OUT_HIGH(bus); delay_us(60); } else { OW_PIN_OUT_LOW(bus); delay_us(60); OW_PIN_OUT_HIGH(bus); } }注意在这里对输入引脚操作时必须先切换方向再读值否则引脚方向配置还没生效就读到了错误电平。这个小问题坑过不少人尤其在 PIC32 上配置为模拟输入引脚时必须先把 ANSEL 位清掉否则读到的永远是 0。4.3 多传感器寻址与 CRC 校验上电后主机先发 Search ROM 命令依次枚举总线上所有传感器序列号把序列号保存在一个数组里。然后每轮采集循环里对每一个序列号发 Match ROM再发读暂存器命令读取温度。枚举过程要注意Search ROM 需要逐位读两次并判断分支代码复杂度不高但容易写错位序我建议直接用现成的已知逻辑实现不要自己造轮子。CRC8 校验不能省。HVAC 现场总线长度长、干扰源多CRC 错误并不罕见。如果 CRC 校验失败这一帧数据直接丢弃重新读一次不必立刻报故障连续三次失败才置传感器故障标志位。这个策略可以同时避免单次干扰导致的误报警和传感器真正断线时的漏报。4.4 温度数据换算与滤波策略读回来的温度数据是 16 位有符号数低 4 位是小数位。12 位分辨率时把原始值右移 4 位得到整数部分小数部分乘以 0.0625 得到小数。例如原始值 0x0191十进制是 401401 × 0.0625 25.0625℃。换算公式很简单难的是滤波。温度传感器本身噪声不大但由于单总线读取间隔长相邻两次读数的差值可能因为量化误差出现 0.0625℃ 的跳变这在 HVAC 温度控制中没必要所以我在工程里加了一阶低通滤波float filtered_temp 0; float alpha 0.2; // 滤波系数 float temp_filter(float new_sample) { filtered_temp alpha * new_sample (1.0f - alpha) * filtered_temp; return filtered_temp; }滤波系数的选择要看应用HVAC 房间温度控制用 0.2 比较合适滞后小如果做风管温度监测风管温度波动快用 0.1如果做冷冻水供水温度控制水系统惯性大用 0.3 到 0.5 都可以。需要注意的是滤波之后温度变化率会变慢如果程序里还做了超温报警判断要自己评估延迟是否可接受。4.5 固件任务调度与温度采集的时序安排PIC32MX795F512L 完全有能力跑一个简单的状态机调度。温度采集需要等待转换完成的 750ms这段时间 CPU 完全可以去处理显示刷新、通信报文、按键扫描。我的做法是把采集逻辑拆成状态机状态一发送转换命令状态二等待 750ms 倒计时状态三读取温度状态四校验和滤波。四个状态轮流执行主循环里每次只处理一个状态避免阻塞式延时把整个系统卡住。5. 本地显示与远程上报数据从传感器到最终用户的完整通道5.1 本地监控串口终端和按键菜单调试阶段用串口最方便。PIC32 的 UART1 接到 USB-TTL 转换器PC 端开串口工具波特率 1152008N1。系统启动时打印总线枚举结果每个传感器的序列号和当前温度都打出来。这个调试输出在项目初期价值极高所有匹配、寻址、CRC 问题基本都能通过串口日志定位。正式产品上做本地监控一般用 LCD 或 LED 数码管。LCD 无需讲太多主要是把温度值、传感器位置、状态标志显示清楚。我在项目里用一个 128x64 的 OLEDSPI 接口显示左右两栏左侧是本地温度右侧是远程温度中间分隔线用几个快速变化的字符做“心跳指示”。心跳指示很重要能让现场维护人员一眼看出系统还在跑没有死机。按键菜单可以做三到五个菜单项温度查看、传感器在线状态、温度阈值设置、报警历史、总线扫描。阈值设置功能在 HVAC 里经常用到调试完后直接现场设定回风温度范围不需要重新烧写固件。5.2 远程上报Modbus 协议与以太网通道远程温度上报最务实的方式是走 RS-485 加 Modbus RTU。RS-485 是差分信号抗干扰能力强HVAC 机房里变频器、接触器产生的电磁干扰对 RS-485 来说基本不构成威胁。PIC32 的 UART 加一个 RS-485 收发器芯片就能实现Modbus 从站逻辑也不复杂寄存器表做好地址分配上位机或者 PLC 通过读保持寄存器就能获取所有传感器温度。如果是自己定义协议建议用简单的帧格式帧头 设备地址 命令字 数据长度 CRC16。工程里见过的失败案例大多败在帧格式上要么没有长度字段导致无法判断帧边界要么缺校验导致乱码数据被当成有效值执行。别嫌帧格式多写几个字节麻烦多一个长度字段、多一个校验字能省掉一多半的远程通信排查时间。如果系统要求更高带宽或者需要接入楼宇以太网PIC32MX795F512L 内建以太网 MAC外接一颗 PHY 就能以轻量 TCP/IP 协议栈做 HTTP 或 MQTT 上报。实测下来温度上报这类低频小数据用 MQTT 走局域网是最灵活的订阅端可以实时看到温度变化趋势。不过以太网方案在 HVAC 现场有个注意点网络变压器和 PHY 之间要做好布线隔离避免把大功率设备的浪涌引到 MCU 上否则网口附近的主控芯片容易被打坏。5.3 HVAC 控制闭环的联动逻辑温度监测最终要落到 HVAC 控制闭环上。最基本的控制逻辑是当回风温度高于设定上限时开启制冷低于设定下限时停止制冷。但只有温度数据还不够因为 HVAC 系统惯性很大传感器位置又不可能刚好覆盖所有区域所以我在项目里做了两层控制逻辑。第一层是用远程风管温度做前馈控制当风管温度达到目标值附近时提前减小阀门开度等回风温度慢慢追上第二层是用本地回风温度做反馈控制采用简单的比例控制把温度稳定在设定点附近。比例系数不需要太大温度误差在 1℃ 以内时控制输出保持在上次值加一个死区防止执行器频繁动作。这样处理的直接好处是现场实测温度波动从 ±1.5℃ 减小到 ±0.4℃ 左右而且执行器动作次数明显减少。6. 常见问题与排查技巧实录6.1 总线上找不到任何设备延时降低甚至换传感器也不行如果复位后一直检测不到存在脉冲优先检查上拉电阻。示波器量总线电压正常空闲状态应稳定在 3.3V如果被拉低到 1V 以下说明总线上有设备短路或者 IO 配置错误。PIC32 的 GPIO 要确认方向寄存器设置正确并且把对应引脚的模拟功能关掉。另一个隐蔽的原因是引脚选错了PIC32 有些引脚默认复用为 JTAG 或者模拟输入不初始化就可能一直表现不正常。6.2 能枚举到传感器但温度偶尔跳变甚至读出固定 85℃85℃ 是传感器上电复位的默认温度值读到 85℃ 说明传感器没有完成温度转换就被读取了或者转换过程中供电中断。如果是寄生供电检查主机是否在转换期间把总线一直拉高如果是外部供电检查传感器 VDD 引脚是否接触不良。温度偶尔跳变则多因时序余量不足将读写时隙的延时各加 10μs连续读数做滤波即可。6.3 总线上的传感器顺序错乱分不清哪个是本地哪个是远程有两个办法。第一在 PCB 上给每路传感器预留一个“地址拨码”电路拨码状态通过 IO 读取后和序列号绑定成一张表。第二更省事的办法是现场调试时用串口把总线上所有序列号打印出来然后在探头上贴标签标注序列号后六位之后绑定工作在软件配置表里完成。千万别靠传感器物理顺序判断总线上电顺序和枚举顺序没有必然关系。6.4 现场干扰导致 CRC 错误率偏高先检查屏蔽层接地确认是单端接地再检查数据线是否和动力线走同一个线槽原则上必须分开。线槽条件不允许的话在传感器数据线上加 TVS 管和共模电感。还可以把总线速率拉低单总线协议允许加长时序读时隙从 60μs 放宽到 90μs 都行只要所有传感器都符合规格。6.5 两个传感器的读数相差超过 1℃校准方法如果同一个测温点两颗传感器读数相差明显先排除安装位置差异再确认传感器没有贴在金属面上的“导热桥”问题。传感器外壳和被测物体之间要涂导热硅脂不能只靠空气接触。如果确实是传感器本身偏差可以做两点校准把传感器放到冰水混合物0℃和沸水100℃中读取原始值算出斜率和偏移量在固件里对每个传感器单独补偿。这套校准流程在 HVAC 现场不太常用但在冷库、冷链监测里是刚需。7. 现场实施后的几点心得项目做完以后我最想说的是用 PJ85718DM 和 PIC32MX795F512L 做本地远程温度监测技术上真正难的往往不是单片机和传感器本身而是总线的物理层设计和现场的抗干扰处理。很多人一开始就把注意力放在固件协议上结果到了现场被长线缆、变频器干扰、地环路坑得连夜改版。先把供电和地处理干净再把线缆走向规划好单总线的时序做到标准规格整个系统在 HVAC 机房里就能长期稳定运行。另外一条经验是工程上永远要留调试出口。哪怕产品最终不需要串口我也建议在板子上留一个 UART 调试接口和 GND 测试点现场问题排查时插一个 USB-TTL 就能看日志这比拿着万用表猜快得多。还有一个细节是传感器数据的日志保存我在项目里用了一片 4MB SPI NOR Flash每小时记录一次温度保留最近一年的数据后期做能效分析时这些数据价值非常大。如果你也想做类似的系统我的建议是先用一块现成的开发板把单总线驱动跑通串口打印温度再考虑画 PCB。第一版 PCB 不要贪多先做两路传感器验证完时序、供电、滤波方案再扩展成八路十六路。温度监测看起来简单实际牵扯的细节却一点都不少稳扎稳打比一次到位靠谱得多。