前阵子接了个不大不小的活儿一台HVAC控制柜既要采集回风口的温度又要知道自己控制板卡附近的温度数据还得汇总到同一颗单片机里做控制逻辑。按老思路两颗模拟温度传感器、两路运放、两路ADC再加一堆分压电阻和标定系数电路板画起来不痛快代码里还得为每路单独做校准。最后我把方案换成了 PIC18F46K20 加两颗 PJ85718DM 数字温度传感器一条单总线就解决了本地和远程两个测点硬件省了大半代码量还更少。这篇东西就是把这套方案的硬件连接、总线时序、软件流程、调试过程和那些我实际踩过的坑全部摊开讲。适合正在做嵌入式温度采集的朋友也适合想把HVAC系统里的多点测温做得更省事的开发者。你不一定要用同一颗MCU这套思路换成其他单片机同样成立关键是把接口协议和工程取舍看明白。1. 需求与整体架构为什么值得用一条总线去测两个温度1.1 项目要解决的真实问题做HVAC相关设备的人都清楚温度测点从来不是一个两个就能解决问题的。空调箱需要知道送风温度、回风温度、混合段温度热泵机组要盯进出水温度控制柜内部还要防止元器件过热。测点一多传统模拟方案的问题就暴露出来了每个测点至少占用一个ADC通道信号小的时候还得加放大电路导线一长又会引入压降和干扰每个传感器的个体差异还得单独校准。一套下来PCB面积和调试工时全花在这些地方了。嵌入式设备里的情况稍微好一些但也有自己的麻烦。机箱内部温度和环境温度往往需要同时监测——比如功率器件附近的温升和外壳进风口的温度。这两者相差可能不大但对散热策略和降频保护很关键。我这次要做的就是这么一台设备控制器本地温度加上远端风管温度两个测点要求低成本、高稳定、不占用太多MCU资源。数字温度传感器插入这个场景之后方案立刻变得清爽。PJ85718DM 这类单总线器件把测温、ADC、校准、通信全做在了一颗芯片里MCU只需要一根IO线就能挂多个传感器每个传感器还有唯一序列号硬件上几乎不用为它额外的外围电路操心。一颗这样的传感器替代一整套模拟前端省下来的东西肉眼可见。1.2 芯片选型的考量PIC18F46K20为什么够用选 PIC18F46K20 不是因为它多先进恰恰因为它在8位机里足够成熟、足够耐用。40引脚封装、64KB程序Flash、3.8KB RAM、1KB数据EEPROM这些资源做多点温度采集和控制逻辑完全够用。它内部有多个通信外设但真正的关键是它有丰富的PORT引脚、良好的IO驱动能力和稳定的内部振荡器用GPIO模拟单总线协议一点压力都没有。这颗MCU的工作电压是2.0V到3.6V我直接给3.3V供电和 PJ85718DM 的供电电压完美对齐省掉了电平转换。内部振荡器也值得一提PIC18F46K20 不需要外部晶振就能跑到比较高的主频省两个电容和一个晶振这在空间紧张的HVAC控制板上很实在。当然如果你对时钟精度有更高的要求比如做串口通信波特率误差敏感的应用也可以外接一个16MHz晶振代码上改动不大。我后来复盘为什么不用一颗带丰富模拟外设的MCU或者干脆上Cortex-M。结论很简单这里不需要跑算法不需要高频采样也不需要复杂操作系统。8位机足够成本更低文档和例程也成熟一个工程师闭着眼都能把它调明白。对于长期供货、稳定性优先的工控和HVAC产品来说这种“够用”的选择往往是最优的。1.3 拓扑方案一条单总线串起本地与远程传感器整个架构其实非常简单。PIC18F46K20 的某一个IO引脚作为单总线数据线DQ所有 PJ85718DM 传感器的DQ脚全部并联在这根线上线再通过一个上拉电阻接到3.3V。本地传感器就近焊在主板上远程传感器用双绞线延长到风管或者远端机箱内部一根总线搞定全部通信。单总线的美妙之处在于每个传感器出厂时都有一串64位ROM序列号。MCU在初始化时扫描总线把挂载在上面的传感器全部枚举出来给它们分别起好“本地”“远程”的身份之后每次都通过ROM寻址精确读取某一个传感器。这样即使总线上以后再多挂两个测点也只需要在软件里增加一次枚举硬件电路完全不用动。这种拓扑还有一个隐藏优势IO资源极其节省。一个测点传统方案最少占一个ADC通道三个测点就得三路单总线方案不管几个传感器始终只占一根IO线。温度数据本身就是数字信号线缆传输的抗干扰能力也远比模拟小信号强这在HVAC现场环境里非常讨喜。3.3V ──┬─────────────── │ [4.7kΩ] ← 上拉电阻 │ PIC18F46K20.IO ─────┤ │ │ ┌┴──────┐ ┌┴──────┐ │ 本地传感器 │ │ 远程传感器 │ ← 双绞线延伸 └────────┘ └────────┘2. 硬件设计与连接细节2.1 PJ85718DM特性速览我把这颗传感器的基础参数单列出来方便后面讲原理和计算。它的基本行为是上电之后默认工作在12位分辨率输出16位二进制补码温度数据测量范围覆盖-55°C到125°C在-10°C到85°C这个HVAC最常用的区间精度可以做到±0.5°C。单总线器件内置唯一64位ROM但没有高低电平之外的专用接口不需要时钟线所以它的引脚极少。参数典型值说明供电电压3.0V ~ 5.5V本项目统一3.3V测温范围-55°C ~ 125°C覆盖HVAC常规区间测量精度±0.5°C-10°C ~ 85°C范围分辨率9 / 10 / 11 / 12位默认12位LSB0.0625°C转换时间750ms 12位低分辨率可降至94ms通信接口单总线64位ROM唯一寻址工作电流约0.75mA转换时约1.5mA这里有一个容易被新手忽略的点单总线器件的“分辨率”和“转换时间”是一对矛盾。12位分辨率下读一次要等750ms如果系统有快速刷新的要求可以把分辨率配置成9位转换时间降到94ms左右精度则退到0.5°C以上。对HVAC这种温度变化本来就很慢的场景我直接锁12位分辨率慢一点无所谓精度和稳定性更重要。2.2 引脚分配与最小系统搭建PIC18F46K20 的最小系统真的非常小。电源脚附近放0.1μF瓷片电容去耦复位脚接一个10kΩ上拉电阻烧录接口留出PGD/PGC两根线就够了。内部振荡器方案不需要晶振这让PCB布局变得很自由。我实际分配引脚时把一个PORT引脚留给单总线另外分配一个引脚给状态LED一个引脚作为UART输出剩下的留给HVAC控制逻辑里的继电器或PWM输出。单总线IO我选在带电平中断功能的PORT上具体引脚编号不重要关键是确保这个引脚能配置为推挽输出和输入两种模式。用PORT的LAT寄存器置高拉低用PORT方向寄存器切换输入输出读写逻辑很清楚。如果把数据线接到一个长期被其他外设占用的引脚后面调试会非常痛苦所以一上来就单独给它留一条路。本地传感器和MCU之间的连线尽量短。如果距离不超过几厘米可以直接把传感器的DQ脚引线出来和MCU的IO之间不需要任何缓冲。远程传感器那边就不一样了线缆长度可能到几米甚至二十米这时候需要认真考虑上拉电阻、线缆类型和屏蔽策略不能想当然地照搬短距离的接法。2.3 上拉电阻选型与计算单总线协议要求数据线在空闲时为高电平传感器和MCU通过拉低来产生信号。这个“空闲高电平”靠的就是上拉电阻。电阻选多大核心考虑是总线RC时间常数和传感器漏电流之间的平衡。上拉电阻和总线寄生电容组成一个RC充电回路。如果电阻太大总线从低电平回到高电平的时间会变长读取时易出现误码如果电阻太小传感器拉低总线时压降对地电流太大可能导致信号拉不到足够低。常见的经验值是1kΩ到4.7kΩ之间。我最初在短距离测试时用4.7kΩ一切正常。之后把远程传感器拉到十几米的双绞线上发现偶尔读错数据用示波器看总线波形上升沿明显变圆了。原因很简单双绞线线缆电容不小十几米下来总线电容可能有800pF到1000pF4.7kΩ乘以这个电容时间常数已经到了几微秒的量级。虽然单总线一位时隙是60μs理论上还有余量但现场还有外部干扰叠加最后我把上拉电阻换成了2.2kΩ波形立刻恢复利索。如果要给一个工程经验公式可以这样粗算先估算总线总电容线缆大致按50pF/米估算每颗传感器输入电容再算几十pF然后用RC时间常数不高于位时隙的十分之一来反向推算电阻值。当然实际操作中直接用示波器看波形是最快的办法。上升沿时间 t 0.8 × R_pullup × C_total设总线电容为 800pF2.2kΩ 时的上升沿约为 1.4μs完全够用4.7kΩ 时约为 3μs也能跑但余量小了些。若线缆更长我建议优先考虑降低线缆电容、采用屏蔽层接地等方式而不是一味把上拉电阻往下压。2.4 远程布线的抗干扰处理HVAC环境里最大的干扰源是变频器、继电器触点、感性负载启停。这些干扰一旦串进单总线轻则某个位读错重则传感器直接不响应。远程线缆我推荐用双绞线如果现场干扰严重再用双层屏蔽线。双绞线的作用是让两根线上的共模干扰尽量一致从而被差分方式抵消。单总线虽然只有一根信号线、一根地线但把信号线和地线双绞仍然能显著降低环路天线效应。屏蔽层只在远端单点接地不要在两端都接地否则地环路电流会把更大的干扰引进来。还要提醒一个容易踩的坑不要把单总线信号线当作低压直流电源给传感器供电后再和强电电缆走同一个线槽。别看只是几伏的数字信号感应出来的高压可能直接击穿传感器内部电路。哪怕不击穿干扰脉冲也会让总线时序彻底错乱。现场布线时尽量分开线槽实在分不开就给数据线加一个TVS二极管到地保护传感器IO。另外远程传感器如果装在金属管道或金属外壳上还要考虑绝缘安装。金属管道的电位不一定和控制器地线一致万一有电位差长时间运行容易出现不明原因的偶发故障。用塑料卡套或绝缘垫片把传感器与金属件隔开能省掉很多后面排查的麻烦。3. 软件实现让MCU正常读取温度3.1 时钟初始化与IO配置软件部分的第一步是把MCU的时钟和IO方向配置好。我使用内部振荡器并把PLL打开让系统时钟跑到32MHz。单总线时序对微秒级的延时要求比较高更快的CPU只是让CPU少等真正的延时还是靠阻塞延时函数来实现。#pragma config FOSC INTIO67 #pragma config PLLCFG ON #pragma config WDTEN OFF #pragma config MCLRE ON void system_init(void) { OSCCON 0x70; // 内部振荡器 8MHz while (!OSCCONbits.IOFS); // 等待振荡器稳定 // PLL启用后系统时钟为 32MHz TRISDbits.TRISD0 1; // 单总线IO先设为输入 ANSELDbits.ANSD0 0; // 关闭模拟功能确保数字IO }IO配置这里有个很容易被忽略的动作PIC18F46K20 的很多引脚默认可能是模拟输入如果不把对应的数字输入使能位关闭读上来的电平永远不对。我用的是 PORTD但如果你换用了其他PORT一定要去查数据手册里哪些引脚带模拟输入功能逐一关闭。另外延时函数的精度直接决定单总线能不能正常通信。使用XC8编译器时延时函数是基于_XTAL_FREQ宏展开的所以一定要把这个宏设置成和实际系统时钟一致的频率否则所有延时全部按比例不对传感器要么不响应要么读出来是乱码。#define _XTAL_FREQ 32000000UL3.2 单总线时序复位、读写位的实现单总线的通信基础是严格的时隙波形。先讲复位时序MCU把总线拉低至少480μs然后释放传感器在检测到这个复位信号后会在60μs到240μs之间拉低总线产生一个存在脉冲。MCU通过这个脉冲确认总线上有设备。读和写一位的方式也很有意思。无论是写0还是写1MCU都必须先拉低总线区别在于低电平持续多久。写1是一位里的大部分时间维持高电平写0则是整个时隙都维持低电平。读一位则是MCU先拉低一小段时间然后立刻释放在很短的时间窗口内去采样电平。void dq_low(void) { LATDbits.LATD0 0; TRISDbits.TRISD0 0; } void dq_high(void) { LATDbits.LATD0 1; TRISDbits.TRISD0 0; } uint8_t dq_read(void) { TRISDbits.TRISD0 1; return PORTDbits.RD0; } uint8_t onewire_reset(void) { uint8_t presence; dq_low(); __delay_us(500); // 复位低电平 dq_high(); __delay_us(70); // 等待存在脉冲起始 presence dq_read(); // 0表示有设备应答 __delay_us(450); // 等待复位时隙结束 return presence; }写一位的实现如下。这里有个经验值写1时低电平持续5μs左右就释放之后维持高电平到整个60μs时隙结束写0时直接拉低60μs。这样能保证传感器在正确的时间窗口内采样。void onewire_write_bit(uint8_t bit) { dq_low(); if (bit) { __delay_us(5); dq_high(); __delay_us(55); } else { __delay_us(60); dq_high(); __delay_us(5); } } void onewire_write_byte(uint8_t byte) { for (uint8_t i 0; i 8; i) { onewire_write_bit(byte 0x01); byte 1; } }读一位的代码类似区别是MCU拉低后要更早释放然后延迟一小段时间再采样输入总共也要保证60μs的读时隙。uint8_t onewire_read_bit(void) { uint8_t bit; dq_low(); __delay_us(6); dq_high(); __delay_us(9); bit dq_read(); __delay_us(50); return bit; } uint8_t onewire_read_byte(void) { uint8_t byte 0; for (uint8_t i 0; i 8; i) { if (onewire_read_bit()) byte | (1 i); } return byte; }在写代码时我们要记住一条铁律单总线的这些时序全是在微秒级别任何中断都可能破坏时序。在完整的复位、读写过程中务必关掉全局中断或者确保中断服务程序的延时严格可控。我一般是在每个传感器完整通信期间关闭中断整个过程也就几毫秒对系统影响可以忽略。3.3 温度转换与读取的完整流程单总线的通信流程分两类指令。一类是ROM指令用于选择总线上某个设备另一类是功能指令用于让传感器执行温度转换或读取数据。标准的转换流程是先复位然后发送Skip ROM跳过ROM广播给所有设备再发送Convert T指令让所有传感器同时开始转换。因为总线上所有传感器可以并行转换等一段时间后再分别通过Match ROM精确读取每个传感器的缓存。// 让总线上所有传感器开始温度转换 void start_all_conversion(void) { onewire_reset(); onewire_write_byte(0xCC); // Skip ROM onewire_write_byte(0x44); // Convert T }读取某个传感器的数据时复位后先发送Match ROM指令0x55然后跟着该传感器的64位ROM序列号传感器才会响应最后发送Read Scratchpad指令0xBE连续读出多个字节。我们只需要前两个字节分别代表温度的LSB和MSB。int16_t read_sensor_temp(uint8_t *rom) { int16_t raw; onewire_reset(); onewire_write_byte(0x55); // Match ROM for (uint8_t i 0; i 8; i) { onewire_write_byte(rom[i]); } onewire_write_byte(0xBE); // Read Scratchpad raw onewire_read_byte(); raw | (onewire_read_byte() 8); return raw; }但这里有个前提MCU必须提前知道每个传感器的ROM序列号。最稳妥的方法是在设备上电或者首次校准时枚举总线。如果总线上只有一个传感器可以用Read ROM指令一次读出ROM如果有多个传感器就需要用单总线搜索算法。完整的搜索算法本质上是一种二进制树遍历逐位比较传感器的ROM值网上的例程很多我建议直接移植成熟代码不要自己发明简化版本容易漏设备。我的实际做法是首次运行时把总线上扫描到的所有ROM打印出来在代码里用数组把这些ROM编号存进EEPROM然后定义好哪些ROM是“本地”、哪些是“远程”。这样运行阶段不需要频繁做全总线扫描每次直接按EEPROM里的ROM表去Match读取速度和稳定性都更好。3.4 温度数据处理分辨率、负温度与滤波PJ85718DM 返回的原始数据是16位带符号数12位分辨率下最低位的权重是0.0625°C。换算成温度很简单正数时把原始值右移4位就得到摄氏度整数部分小数部分在低4位里。负数使用补码表示不能直接右移先取反加一恢复绝对值再除以16。float raw_to_celsius(int16_t raw) { float temp; if (raw 0x8000) // 负温度 { temp -((~raw 1) 4); } else { temp (raw 4); } temp (raw 0x0F) * 0.0625f; return temp; }实际工程里用浮点不是不行但8位MCU上浮点运算比较慢。若只是做控制逻辑更推荐直接用整数运算。比如把返回值乘以16保留小数点后一位或者后两位的精度全部用整数完成加法、比较、滤波最后再输出。软件滤波我建议分两级。第一级是剔除异常值如果相邻两次采集的温度差值超过比如2°C就认为这次数据异常丢弃并沿用上次值。第二级是滑动平均取最近4次到8次的有效数据做算术平均能有效压掉远程线缆偶发干扰引起的跳变。HVAC的温度变化本来就慢这种滤波不会滞后太多。还有一点传感器本身会有微弱自发热。单总线传感器在转换时工作电流会变大如果环境散热不好测量值会比实际偏高零点几度。这个误差一般不用管如果非要高精度可以让传感器在上电转换几次后再进入正式采样或者做一次常态校准在软件里加一个校准偏移量。4. 联调、验证与数据输出4.1 用UART把温度数据传到上位机调数据最直接的输出通道就是串口。PIC18F46K20 的EUSART模块配置为9600或115200波特率连接USB转串口小板把温度数据打出来看。配置波特率时记得考虑系统时钟频率我用32MHz时想要115200BRGH位设为1分频寄存器SPBRGL大约取69。void uart_init(void) { TXSTA1bits.BRGH 1; SPBRGL1 69; // 115200 32MHz BAUDCON1bits.BRG16 1; TXSTA1bits.TXEN 1; RCSTA1bits.SPEN 1; } void putch(char data) { while (!TXSTA1bits.TRMT); TXREG1 data; }XC8编译器在开启printf后会自动调用putch有了这个函数就能直接使用printf打印格式化文本。我把本地温度和远程温度分别打印出来每秒更新一次方便观察两个测点的实时变化和波动范围。4.2 整机实测与结果分析实测的时候本地传感器贴在控制板功率器件附近远程传感器用两米双绞线延伸到空调出风口。上电后先观察一组数据本地温度从26.3°C缓慢上升到31.8°C远程温度从24.9°C波动到26.1°C。曲线没有跳变读数稳定在±0.1°C以内符合预期。我也故意做了一次破坏性测试在远程传感器旁边开启了一把工业电扇同时还让同一个电源插座上的变频设备启动。未做屏蔽前读数偶尔出现85°C之类的异常值那是干扰导致的高位误码给双绞线加屏蔽层并把屏蔽层单端接地后异常值消失滑动滤波也兜住了最后的毛刺。整机功耗也让人满意。MCU加两颗传感器正常工作电流不到15mA如果进入休眠并定期唤醒采样电池供电也完全可以长时间运行。这套方案的实用价值正在于此硬件简洁、功耗可控、调试直观。4.3 多个温度测点的数据管理实际HVAC系统往往不止两个测点可能一组冷媒管上要贴四个温度传感器。这时软件上需要引入“温度对象”的概念把每个ROM和它的逻辑角色、物理位置绑定。我在代码里定义了一个很简单的结构体把身份、原始值、转换后的温标和启用状态都打包在一起主循环只管遍历这个结构体数组。另一个容易被忽视的是寄存器配置。PJ85718DM 的配置寄存器可以设置分辨率如果不同测点对刷新率要求不同可以通过Match ROM单独给每个传感器写配置寄存器。但如果不是特别有必要我不建议做这种差异化配置因为每多一种状态代码和测试就要多覆盖一层边际收益很小。5. 常见问题排查与避坑记录5.1 读回全0xFF或者设备不响应这是单总线调试里最经典的问题。现象是复位后存在脉冲读不到或者读回来的字节全是0xFF。原因绝大多数出在硬件或者IO配置上总线没有接上拉、IO被配置成模拟输入、传感器的供电引脚接反、地线没共地单独一个原因就足以让通信完全不工作。排查顺序建议是先用万用表量传感器供电电压确保3.3V真的到脚上了再量数据线空闲电压应该接近3.3V而不是0V然后用逻辑分析仪或示波器抓复位波形看MCU释放总线后有没有传感器拉低的存在脉冲。如果一切波形正常但还是读不到数据再去看代码延时参数尤其是_XTAL_FREQ是否和实际时钟一致。时序不对是最隐蔽的故障。还有一个容易被忽略的细节PIC18F46K20 的IO引脚默认状态可能不是高阻输入也可能是弱上拉或模拟输入功能。写初始化代码时一定要在早期就把引脚方向、数字功能一次性配置好不要等到中途才改。5.2 远程传感器读数漂移或偶发跳变远程传感器和本地传感器的区别本质上是总线上多了一段线缆。线缆电容会让上升沿变慢线缆本身又是一个天线会接收外部的电磁干扰。表现就是读数不稳定时而正常时而跳变到异常值。处理办法我在硬件部分已经说了一部分降低上拉电阻、使用双绞屏蔽线、屏蔽层单端接地、远离强电电缆。软件方面除了滤波还有一个方法适当降低单总线通信速率比如把读写时隙从标准的60μs放宽到90μs甚至120μs给信号建立留更多时间。多数传感器对时隙宽度是有容忍范围的放宽一点不影响功能却能提高长线稳定性。另一个经验是把温度转换命令发完后等待时间留足够。如果程序在传感器还没转换完就急忙去读读回来的可能是上一次的旧数据看起来就像“不更新”或“跳变”。标准做法是发完Convert T后等待750ms以上除非你把分辨率调低了。5.3 读数精度达不到标称值数字温度传感器的精度标称是芯片裸测的结果装进系统后会受到很多外部因素影响。最直接的是自发热传感器供电后内部电路工作即便静态电流很小如果PCB散热条件差、外壳密封不透气读数就会偏高。其次是热耦合。传感器引脚如果大面积焊在大铜皮上而铜皮连接着功率器件温度读数会偏向板温而不是环境温度。要测环境温度就要让传感器尽量远离热源引脚不要贪大焊盘要测板温反而要把传感器贴近被测器件。如果发现系统性偏差比如读数总是比标准温度计高0.8°C不要怀疑传感器坏了绝大多数是安装和散热问题。实在抹不平就在软件里做个两点校准分别在0°C和50°C的恒温源里记录偏差然后线性补偿。5.4 多传感器识别混乱总线上挂两个以上传感器时如果枚举ROM的算法写得不对会出现扫描不到某个设备或者两个传感器地址重叠的假象。真实世界里两个传感器ROM完全相同的概率极低除非买到劣质复制品。所以出现地址重复时先怀疑程序扫描逻辑再怀疑硬件虚焊导致个别传感器间歇性掉线。我建议在上电初始化阶段做一次完整扫描把每个设备的ROM打印出来存档。如果发现扫描结果和上一批不一致多半是某个传感器接触不良而不是算法问题。现场安装的传感器如果用的是插接端子热胀冷缩后很容易出现半接触状态建议对远程传感器用焊接或者压接接线端子再打胶固定。6. 这套方案的适用边界与扩展方向6.1 方案的优点与局限这套“PIC18F46K20 PJ85718DM单总线测温”方案的优点很突出成本极低、占用资源少、布线简单、传感器即插即用。尤其适合测点数量中等但分布距离不远的中小型HVAC设备、电控柜、商用厨电、农业环境监控等场景。单总线的天然广播特性也方便以后在系统不变的前提下增加测点。但有局限也心里要有数。单总线是半双工低速协议温度传感器转换时间动辄几百毫秒不适合高速动态测温。总线长度受电容和干扰制约超过几十米就要考虑其他方案。另外单总线的时序由软件模拟完成CPU在通信期间基本被占住如果系统同时要跑复杂的控制算法要合理安排调度。6.2 远程测温的替代路径如果距离超过单总线能承受的范围比如要测一栋楼里不同区域的温度可以考虑在传感器侧加简单的采集节点通过RS-485总线或者Modbus协议上传这在中大型HVAC系统里非常常见。RS-485是差分信号抗干扰能力和传距都远强于单总线代价是每个节点要多一颗收发器和更复杂的协议。如果现场不方便布线也可以用无线采集节点。通用的做法是每个温度传感器配一颗低功耗无线模块星形组网中心节点通过串口接回PIC18F46K20。这种方式布局灵活但设备成本和故障点也会相应增加适合改造项目。6.3 把方案往产品化方向打磨从开发板跨到产品有几个事情需要补。第一是电源的稳波处理HVAC控制板上的12V、24V电源从开关电源出来时纹波不小给MCU和传感器供电的3.3V要加足够容量的电容和磁珠。第二是接插端子选型远程传感器的端子只要松动一次就是一次售后优先选带锁扣的端子。还有一个我自己的小习惯在PCB上留一组测试点把单总线信号、地、电源引出来。平时生产测试或者现场排查时夹上逻辑分析仪就能看波形不用拆机器找线。这个测试点成本几乎为零却能让调试效率翻倍强烈建议保留。这套方案做完之后我又在另一个项目里复用了同一套代码只是把传感器从两个加到了四个改动量也就是数组和ROM表扩一下而已。如果你也正在为多点温度采集发愁从单总线数字传感器入手大概率会比你在模拟方案里继续折腾省下不少工夫。 PIC18F46K20与PJ85718DM：单总线多点测温方案解析
前阵子接了个不大不小的活儿一台HVAC控制柜既要采集回风口的温度又要知道自己控制板卡附近的温度数据还得汇总到同一颗单片机里做控制逻辑。按老思路两颗模拟温度传感器、两路运放、两路ADC再加一堆分压电阻和标定系数电路板画起来不痛快代码里还得为每路单独做校准。最后我把方案换成了 PIC18F46K20 加两颗 PJ85718DM 数字温度传感器一条单总线就解决了本地和远程两个测点硬件省了大半代码量还更少。这篇东西就是把这套方案的硬件连接、总线时序、软件流程、调试过程和那些我实际踩过的坑全部摊开讲。适合正在做嵌入式温度采集的朋友也适合想把HVAC系统里的多点测温做得更省事的开发者。你不一定要用同一颗MCU这套思路换成其他单片机同样成立关键是把接口协议和工程取舍看明白。1. 需求与整体架构为什么值得用一条总线去测两个温度1.1 项目要解决的真实问题做HVAC相关设备的人都清楚温度测点从来不是一个两个就能解决问题的。空调箱需要知道送风温度、回风温度、混合段温度热泵机组要盯进出水温度控制柜内部还要防止元器件过热。测点一多传统模拟方案的问题就暴露出来了每个测点至少占用一个ADC通道信号小的时候还得加放大电路导线一长又会引入压降和干扰每个传感器的个体差异还得单独校准。一套下来PCB面积和调试工时全花在这些地方了。嵌入式设备里的情况稍微好一些但也有自己的麻烦。机箱内部温度和环境温度往往需要同时监测——比如功率器件附近的温升和外壳进风口的温度。这两者相差可能不大但对散热策略和降频保护很关键。我这次要做的就是这么一台设备控制器本地温度加上远端风管温度两个测点要求低成本、高稳定、不占用太多MCU资源。数字温度传感器插入这个场景之后方案立刻变得清爽。PJ85718DM 这类单总线器件把测温、ADC、校准、通信全做在了一颗芯片里MCU只需要一根IO线就能挂多个传感器每个传感器还有唯一序列号硬件上几乎不用为它额外的外围电路操心。一颗这样的传感器替代一整套模拟前端省下来的东西肉眼可见。1.2 芯片选型的考量PIC18F46K20为什么够用选 PIC18F46K20 不是因为它多先进恰恰因为它在8位机里足够成熟、足够耐用。40引脚封装、64KB程序Flash、3.8KB RAM、1KB数据EEPROM这些资源做多点温度采集和控制逻辑完全够用。它内部有多个通信外设但真正的关键是它有丰富的PORT引脚、良好的IO驱动能力和稳定的内部振荡器用GPIO模拟单总线协议一点压力都没有。这颗MCU的工作电压是2.0V到3.6V我直接给3.3V供电和 PJ85718DM 的供电电压完美对齐省掉了电平转换。内部振荡器也值得一提PIC18F46K20 不需要外部晶振就能跑到比较高的主频省两个电容和一个晶振这在空间紧张的HVAC控制板上很实在。当然如果你对时钟精度有更高的要求比如做串口通信波特率误差敏感的应用也可以外接一个16MHz晶振代码上改动不大。我后来复盘为什么不用一颗带丰富模拟外设的MCU或者干脆上Cortex-M。结论很简单这里不需要跑算法不需要高频采样也不需要复杂操作系统。8位机足够成本更低文档和例程也成熟一个工程师闭着眼都能把它调明白。对于长期供货、稳定性优先的工控和HVAC产品来说这种“够用”的选择往往是最优的。1.3 拓扑方案一条单总线串起本地与远程传感器整个架构其实非常简单。PIC18F46K20 的某一个IO引脚作为单总线数据线DQ所有 PJ85718DM 传感器的DQ脚全部并联在这根线上线再通过一个上拉电阻接到3.3V。本地传感器就近焊在主板上远程传感器用双绞线延长到风管或者远端机箱内部一根总线搞定全部通信。单总线的美妙之处在于每个传感器出厂时都有一串64位ROM序列号。MCU在初始化时扫描总线把挂载在上面的传感器全部枚举出来给它们分别起好“本地”“远程”的身份之后每次都通过ROM寻址精确读取某一个传感器。这样即使总线上以后再多挂两个测点也只需要在软件里增加一次枚举硬件电路完全不用动。这种拓扑还有一个隐藏优势IO资源极其节省。一个测点传统方案最少占一个ADC通道三个测点就得三路单总线方案不管几个传感器始终只占一根IO线。温度数据本身就是数字信号线缆传输的抗干扰能力也远比模拟小信号强这在HVAC现场环境里非常讨喜。3.3V ──┬─────────────── │ [4.7kΩ] ← 上拉电阻 │ PIC18F46K20.IO ─────┤ │ │ ┌┴──────┐ ┌┴──────┐ │ 本地传感器 │ │ 远程传感器 │ ← 双绞线延伸 └────────┘ └────────┘2. 硬件设计与连接细节2.1 PJ85718DM特性速览我把这颗传感器的基础参数单列出来方便后面讲原理和计算。它的基本行为是上电之后默认工作在12位分辨率输出16位二进制补码温度数据测量范围覆盖-55°C到125°C在-10°C到85°C这个HVAC最常用的区间精度可以做到±0.5°C。单总线器件内置唯一64位ROM但没有高低电平之外的专用接口不需要时钟线所以它的引脚极少。参数典型值说明供电电压3.0V ~ 5.5V本项目统一3.3V测温范围-55°C ~ 125°C覆盖HVAC常规区间测量精度±0.5°C-10°C ~ 85°C范围分辨率9 / 10 / 11 / 12位默认12位LSB0.0625°C转换时间750ms 12位低分辨率可降至94ms通信接口单总线64位ROM唯一寻址工作电流约0.75mA转换时约1.5mA这里有一个容易被新手忽略的点单总线器件的“分辨率”和“转换时间”是一对矛盾。12位分辨率下读一次要等750ms如果系统有快速刷新的要求可以把分辨率配置成9位转换时间降到94ms左右精度则退到0.5°C以上。对HVAC这种温度变化本来就很慢的场景我直接锁12位分辨率慢一点无所谓精度和稳定性更重要。2.2 引脚分配与最小系统搭建PIC18F46K20 的最小系统真的非常小。电源脚附近放0.1μF瓷片电容去耦复位脚接一个10kΩ上拉电阻烧录接口留出PGD/PGC两根线就够了。内部振荡器方案不需要晶振这让PCB布局变得很自由。我实际分配引脚时把一个PORT引脚留给单总线另外分配一个引脚给状态LED一个引脚作为UART输出剩下的留给HVAC控制逻辑里的继电器或PWM输出。单总线IO我选在带电平中断功能的PORT上具体引脚编号不重要关键是确保这个引脚能配置为推挽输出和输入两种模式。用PORT的LAT寄存器置高拉低用PORT方向寄存器切换输入输出读写逻辑很清楚。如果把数据线接到一个长期被其他外设占用的引脚后面调试会非常痛苦所以一上来就单独给它留一条路。本地传感器和MCU之间的连线尽量短。如果距离不超过几厘米可以直接把传感器的DQ脚引线出来和MCU的IO之间不需要任何缓冲。远程传感器那边就不一样了线缆长度可能到几米甚至二十米这时候需要认真考虑上拉电阻、线缆类型和屏蔽策略不能想当然地照搬短距离的接法。2.3 上拉电阻选型与计算单总线协议要求数据线在空闲时为高电平传感器和MCU通过拉低来产生信号。这个“空闲高电平”靠的就是上拉电阻。电阻选多大核心考虑是总线RC时间常数和传感器漏电流之间的平衡。上拉电阻和总线寄生电容组成一个RC充电回路。如果电阻太大总线从低电平回到高电平的时间会变长读取时易出现误码如果电阻太小传感器拉低总线时压降对地电流太大可能导致信号拉不到足够低。常见的经验值是1kΩ到4.7kΩ之间。我最初在短距离测试时用4.7kΩ一切正常。之后把远程传感器拉到十几米的双绞线上发现偶尔读错数据用示波器看总线波形上升沿明显变圆了。原因很简单双绞线线缆电容不小十几米下来总线电容可能有800pF到1000pF4.7kΩ乘以这个电容时间常数已经到了几微秒的量级。虽然单总线一位时隙是60μs理论上还有余量但现场还有外部干扰叠加最后我把上拉电阻换成了2.2kΩ波形立刻恢复利索。如果要给一个工程经验公式可以这样粗算先估算总线总电容线缆大致按50pF/米估算每颗传感器输入电容再算几十pF然后用RC时间常数不高于位时隙的十分之一来反向推算电阻值。当然实际操作中直接用示波器看波形是最快的办法。上升沿时间 t 0.8 × R_pullup × C_total设总线电容为 800pF2.2kΩ 时的上升沿约为 1.4μs完全够用4.7kΩ 时约为 3μs也能跑但余量小了些。若线缆更长我建议优先考虑降低线缆电容、采用屏蔽层接地等方式而不是一味把上拉电阻往下压。2.4 远程布线的抗干扰处理HVAC环境里最大的干扰源是变频器、继电器触点、感性负载启停。这些干扰一旦串进单总线轻则某个位读错重则传感器直接不响应。远程线缆我推荐用双绞线如果现场干扰严重再用双层屏蔽线。双绞线的作用是让两根线上的共模干扰尽量一致从而被差分方式抵消。单总线虽然只有一根信号线、一根地线但把信号线和地线双绞仍然能显著降低环路天线效应。屏蔽层只在远端单点接地不要在两端都接地否则地环路电流会把更大的干扰引进来。还要提醒一个容易踩的坑不要把单总线信号线当作低压直流电源给传感器供电后再和强电电缆走同一个线槽。别看只是几伏的数字信号感应出来的高压可能直接击穿传感器内部电路。哪怕不击穿干扰脉冲也会让总线时序彻底错乱。现场布线时尽量分开线槽实在分不开就给数据线加一个TVS二极管到地保护传感器IO。另外远程传感器如果装在金属管道或金属外壳上还要考虑绝缘安装。金属管道的电位不一定和控制器地线一致万一有电位差长时间运行容易出现不明原因的偶发故障。用塑料卡套或绝缘垫片把传感器与金属件隔开能省掉很多后面排查的麻烦。3. 软件实现让MCU正常读取温度3.1 时钟初始化与IO配置软件部分的第一步是把MCU的时钟和IO方向配置好。我使用内部振荡器并把PLL打开让系统时钟跑到32MHz。单总线时序对微秒级的延时要求比较高更快的CPU只是让CPU少等真正的延时还是靠阻塞延时函数来实现。#pragma config FOSC INTIO67 #pragma config PLLCFG ON #pragma config WDTEN OFF #pragma config MCLRE ON void system_init(void) { OSCCON 0x70; // 内部振荡器 8MHz while (!OSCCONbits.IOFS); // 等待振荡器稳定 // PLL启用后系统时钟为 32MHz TRISDbits.TRISD0 1; // 单总线IO先设为输入 ANSELDbits.ANSD0 0; // 关闭模拟功能确保数字IO }IO配置这里有个很容易被忽略的动作PIC18F46K20 的很多引脚默认可能是模拟输入如果不把对应的数字输入使能位关闭读上来的电平永远不对。我用的是 PORTD但如果你换用了其他PORT一定要去查数据手册里哪些引脚带模拟输入功能逐一关闭。另外延时函数的精度直接决定单总线能不能正常通信。使用XC8编译器时延时函数是基于_XTAL_FREQ宏展开的所以一定要把这个宏设置成和实际系统时钟一致的频率否则所有延时全部按比例不对传感器要么不响应要么读出来是乱码。#define _XTAL_FREQ 32000000UL3.2 单总线时序复位、读写位的实现单总线的通信基础是严格的时隙波形。先讲复位时序MCU把总线拉低至少480μs然后释放传感器在检测到这个复位信号后会在60μs到240μs之间拉低总线产生一个存在脉冲。MCU通过这个脉冲确认总线上有设备。读和写一位的方式也很有意思。无论是写0还是写1MCU都必须先拉低总线区别在于低电平持续多久。写1是一位里的大部分时间维持高电平写0则是整个时隙都维持低电平。读一位则是MCU先拉低一小段时间然后立刻释放在很短的时间窗口内去采样电平。void dq_low(void) { LATDbits.LATD0 0; TRISDbits.TRISD0 0; } void dq_high(void) { LATDbits.LATD0 1; TRISDbits.TRISD0 0; } uint8_t dq_read(void) { TRISDbits.TRISD0 1; return PORTDbits.RD0; } uint8_t onewire_reset(void) { uint8_t presence; dq_low(); __delay_us(500); // 复位低电平 dq_high(); __delay_us(70); // 等待存在脉冲起始 presence dq_read(); // 0表示有设备应答 __delay_us(450); // 等待复位时隙结束 return presence; }写一位的实现如下。这里有个经验值写1时低电平持续5μs左右就释放之后维持高电平到整个60μs时隙结束写0时直接拉低60μs。这样能保证传感器在正确的时间窗口内采样。void onewire_write_bit(uint8_t bit) { dq_low(); if (bit) { __delay_us(5); dq_high(); __delay_us(55); } else { __delay_us(60); dq_high(); __delay_us(5); } } void onewire_write_byte(uint8_t byte) { for (uint8_t i 0; i 8; i) { onewire_write_bit(byte 0x01); byte 1; } }读一位的代码类似区别是MCU拉低后要更早释放然后延迟一小段时间再采样输入总共也要保证60μs的读时隙。uint8_t onewire_read_bit(void) { uint8_t bit; dq_low(); __delay_us(6); dq_high(); __delay_us(9); bit dq_read(); __delay_us(50); return bit; } uint8_t onewire_read_byte(void) { uint8_t byte 0; for (uint8_t i 0; i 8; i) { if (onewire_read_bit()) byte | (1 i); } return byte; }在写代码时我们要记住一条铁律单总线的这些时序全是在微秒级别任何中断都可能破坏时序。在完整的复位、读写过程中务必关掉全局中断或者确保中断服务程序的延时严格可控。我一般是在每个传感器完整通信期间关闭中断整个过程也就几毫秒对系统影响可以忽略。3.3 温度转换与读取的完整流程单总线的通信流程分两类指令。一类是ROM指令用于选择总线上某个设备另一类是功能指令用于让传感器执行温度转换或读取数据。标准的转换流程是先复位然后发送Skip ROM跳过ROM广播给所有设备再发送Convert T指令让所有传感器同时开始转换。因为总线上所有传感器可以并行转换等一段时间后再分别通过Match ROM精确读取每个传感器的缓存。// 让总线上所有传感器开始温度转换 void start_all_conversion(void) { onewire_reset(); onewire_write_byte(0xCC); // Skip ROM onewire_write_byte(0x44); // Convert T }读取某个传感器的数据时复位后先发送Match ROM指令0x55然后跟着该传感器的64位ROM序列号传感器才会响应最后发送Read Scratchpad指令0xBE连续读出多个字节。我们只需要前两个字节分别代表温度的LSB和MSB。int16_t read_sensor_temp(uint8_t *rom) { int16_t raw; onewire_reset(); onewire_write_byte(0x55); // Match ROM for (uint8_t i 0; i 8; i) { onewire_write_byte(rom[i]); } onewire_write_byte(0xBE); // Read Scratchpad raw onewire_read_byte(); raw | (onewire_read_byte() 8); return raw; }但这里有个前提MCU必须提前知道每个传感器的ROM序列号。最稳妥的方法是在设备上电或者首次校准时枚举总线。如果总线上只有一个传感器可以用Read ROM指令一次读出ROM如果有多个传感器就需要用单总线搜索算法。完整的搜索算法本质上是一种二进制树遍历逐位比较传感器的ROM值网上的例程很多我建议直接移植成熟代码不要自己发明简化版本容易漏设备。我的实际做法是首次运行时把总线上扫描到的所有ROM打印出来在代码里用数组把这些ROM编号存进EEPROM然后定义好哪些ROM是“本地”、哪些是“远程”。这样运行阶段不需要频繁做全总线扫描每次直接按EEPROM里的ROM表去Match读取速度和稳定性都更好。3.4 温度数据处理分辨率、负温度与滤波PJ85718DM 返回的原始数据是16位带符号数12位分辨率下最低位的权重是0.0625°C。换算成温度很简单正数时把原始值右移4位就得到摄氏度整数部分小数部分在低4位里。负数使用补码表示不能直接右移先取反加一恢复绝对值再除以16。float raw_to_celsius(int16_t raw) { float temp; if (raw 0x8000) // 负温度 { temp -((~raw 1) 4); } else { temp (raw 4); } temp (raw 0x0F) * 0.0625f; return temp; }实际工程里用浮点不是不行但8位MCU上浮点运算比较慢。若只是做控制逻辑更推荐直接用整数运算。比如把返回值乘以16保留小数点后一位或者后两位的精度全部用整数完成加法、比较、滤波最后再输出。软件滤波我建议分两级。第一级是剔除异常值如果相邻两次采集的温度差值超过比如2°C就认为这次数据异常丢弃并沿用上次值。第二级是滑动平均取最近4次到8次的有效数据做算术平均能有效压掉远程线缆偶发干扰引起的跳变。HVAC的温度变化本来就慢这种滤波不会滞后太多。还有一点传感器本身会有微弱自发热。单总线传感器在转换时工作电流会变大如果环境散热不好测量值会比实际偏高零点几度。这个误差一般不用管如果非要高精度可以让传感器在上电转换几次后再进入正式采样或者做一次常态校准在软件里加一个校准偏移量。4. 联调、验证与数据输出4.1 用UART把温度数据传到上位机调数据最直接的输出通道就是串口。PIC18F46K20 的EUSART模块配置为9600或115200波特率连接USB转串口小板把温度数据打出来看。配置波特率时记得考虑系统时钟频率我用32MHz时想要115200BRGH位设为1分频寄存器SPBRGL大约取69。void uart_init(void) { TXSTA1bits.BRGH 1; SPBRGL1 69; // 115200 32MHz BAUDCON1bits.BRG16 1; TXSTA1bits.TXEN 1; RCSTA1bits.SPEN 1; } void putch(char data) { while (!TXSTA1bits.TRMT); TXREG1 data; }XC8编译器在开启printf后会自动调用putch有了这个函数就能直接使用printf打印格式化文本。我把本地温度和远程温度分别打印出来每秒更新一次方便观察两个测点的实时变化和波动范围。4.2 整机实测与结果分析实测的时候本地传感器贴在控制板功率器件附近远程传感器用两米双绞线延伸到空调出风口。上电后先观察一组数据本地温度从26.3°C缓慢上升到31.8°C远程温度从24.9°C波动到26.1°C。曲线没有跳变读数稳定在±0.1°C以内符合预期。我也故意做了一次破坏性测试在远程传感器旁边开启了一把工业电扇同时还让同一个电源插座上的变频设备启动。未做屏蔽前读数偶尔出现85°C之类的异常值那是干扰导致的高位误码给双绞线加屏蔽层并把屏蔽层单端接地后异常值消失滑动滤波也兜住了最后的毛刺。整机功耗也让人满意。MCU加两颗传感器正常工作电流不到15mA如果进入休眠并定期唤醒采样电池供电也完全可以长时间运行。这套方案的实用价值正在于此硬件简洁、功耗可控、调试直观。4.3 多个温度测点的数据管理实际HVAC系统往往不止两个测点可能一组冷媒管上要贴四个温度传感器。这时软件上需要引入“温度对象”的概念把每个ROM和它的逻辑角色、物理位置绑定。我在代码里定义了一个很简单的结构体把身份、原始值、转换后的温标和启用状态都打包在一起主循环只管遍历这个结构体数组。另一个容易被忽视的是寄存器配置。PJ85718DM 的配置寄存器可以设置分辨率如果不同测点对刷新率要求不同可以通过Match ROM单独给每个传感器写配置寄存器。但如果不是特别有必要我不建议做这种差异化配置因为每多一种状态代码和测试就要多覆盖一层边际收益很小。5. 常见问题排查与避坑记录5.1 读回全0xFF或者设备不响应这是单总线调试里最经典的问题。现象是复位后存在脉冲读不到或者读回来的字节全是0xFF。原因绝大多数出在硬件或者IO配置上总线没有接上拉、IO被配置成模拟输入、传感器的供电引脚接反、地线没共地单独一个原因就足以让通信完全不工作。排查顺序建议是先用万用表量传感器供电电压确保3.3V真的到脚上了再量数据线空闲电压应该接近3.3V而不是0V然后用逻辑分析仪或示波器抓复位波形看MCU释放总线后有没有传感器拉低的存在脉冲。如果一切波形正常但还是读不到数据再去看代码延时参数尤其是_XTAL_FREQ是否和实际时钟一致。时序不对是最隐蔽的故障。还有一个容易被忽略的细节PIC18F46K20 的IO引脚默认状态可能不是高阻输入也可能是弱上拉或模拟输入功能。写初始化代码时一定要在早期就把引脚方向、数字功能一次性配置好不要等到中途才改。5.2 远程传感器读数漂移或偶发跳变远程传感器和本地传感器的区别本质上是总线上多了一段线缆。线缆电容会让上升沿变慢线缆本身又是一个天线会接收外部的电磁干扰。表现就是读数不稳定时而正常时而跳变到异常值。处理办法我在硬件部分已经说了一部分降低上拉电阻、使用双绞屏蔽线、屏蔽层单端接地、远离强电电缆。软件方面除了滤波还有一个方法适当降低单总线通信速率比如把读写时隙从标准的60μs放宽到90μs甚至120μs给信号建立留更多时间。多数传感器对时隙宽度是有容忍范围的放宽一点不影响功能却能提高长线稳定性。另一个经验是把温度转换命令发完后等待时间留足够。如果程序在传感器还没转换完就急忙去读读回来的可能是上一次的旧数据看起来就像“不更新”或“跳变”。标准做法是发完Convert T后等待750ms以上除非你把分辨率调低了。5.3 读数精度达不到标称值数字温度传感器的精度标称是芯片裸测的结果装进系统后会受到很多外部因素影响。最直接的是自发热传感器供电后内部电路工作即便静态电流很小如果PCB散热条件差、外壳密封不透气读数就会偏高。其次是热耦合。传感器引脚如果大面积焊在大铜皮上而铜皮连接着功率器件温度读数会偏向板温而不是环境温度。要测环境温度就要让传感器尽量远离热源引脚不要贪大焊盘要测板温反而要把传感器贴近被测器件。如果发现系统性偏差比如读数总是比标准温度计高0.8°C不要怀疑传感器坏了绝大多数是安装和散热问题。实在抹不平就在软件里做个两点校准分别在0°C和50°C的恒温源里记录偏差然后线性补偿。5.4 多传感器识别混乱总线上挂两个以上传感器时如果枚举ROM的算法写得不对会出现扫描不到某个设备或者两个传感器地址重叠的假象。真实世界里两个传感器ROM完全相同的概率极低除非买到劣质复制品。所以出现地址重复时先怀疑程序扫描逻辑再怀疑硬件虚焊导致个别传感器间歇性掉线。我建议在上电初始化阶段做一次完整扫描把每个设备的ROM打印出来存档。如果发现扫描结果和上一批不一致多半是某个传感器接触不良而不是算法问题。现场安装的传感器如果用的是插接端子热胀冷缩后很容易出现半接触状态建议对远程传感器用焊接或者压接接线端子再打胶固定。6. 这套方案的适用边界与扩展方向6.1 方案的优点与局限这套“PIC18F46K20 PJ85718DM单总线测温”方案的优点很突出成本极低、占用资源少、布线简单、传感器即插即用。尤其适合测点数量中等但分布距离不远的中小型HVAC设备、电控柜、商用厨电、农业环境监控等场景。单总线的天然广播特性也方便以后在系统不变的前提下增加测点。但有局限也心里要有数。单总线是半双工低速协议温度传感器转换时间动辄几百毫秒不适合高速动态测温。总线长度受电容和干扰制约超过几十米就要考虑其他方案。另外单总线的时序由软件模拟完成CPU在通信期间基本被占住如果系统同时要跑复杂的控制算法要合理安排调度。6.2 远程测温的替代路径如果距离超过单总线能承受的范围比如要测一栋楼里不同区域的温度可以考虑在传感器侧加简单的采集节点通过RS-485总线或者Modbus协议上传这在中大型HVAC系统里非常常见。RS-485是差分信号抗干扰能力和传距都远强于单总线代价是每个节点要多一颗收发器和更复杂的协议。如果现场不方便布线也可以用无线采集节点。通用的做法是每个温度传感器配一颗低功耗无线模块星形组网中心节点通过串口接回PIC18F46K20。这种方式布局灵活但设备成本和故障点也会相应增加适合改造项目。6.3 把方案往产品化方向打磨从开发板跨到产品有几个事情需要补。第一是电源的稳波处理HVAC控制板上的12V、24V电源从开关电源出来时纹波不小给MCU和传感器供电的3.3V要加足够容量的电容和磁珠。第二是接插端子选型远程传感器的端子只要松动一次就是一次售后优先选带锁扣的端子。还有一个我自己的小习惯在PCB上留一组测试点把单总线信号、地、电源引出来。平时生产测试或者现场排查时夹上逻辑分析仪就能看波形不用拆机器找线。这个测试点成本几乎为零却能让调试效率翻倍强烈建议保留。这套方案做完之后我又在另一个项目里复用了同一套代码只是把传感器从两个加到了四个改动量也就是数组和ROM表扩一下而已。如果你也正在为多点温度采集发愁从单总线数字传感器入手大概率会比你在模拟方案里继续折腾省下不少工夫。