企业官网建设流程全解析

做HVAC控制器时间长了，你会发现温度这件事远没有看上去那么简单。控制板上要防自己过热，风管那边又要盯回风温度，风机盘管后头还可能有第二路送风温度等着你去测。两路测点隔了十来米，中间又跑着接触器和变频器，随便哪路信号抖一抖，PID就跟着乱跳。PJ85718DM这类数字温度传感器加上PIC18F86J16这颗8位MCU，是我在模拟项目X里用来同时盯本地板温和远端风管温度的一套低成本测温方案。今天把这套方案的选型原因、硬件连接、软件状态机和踩坑记录一次说清楚，适合正在做嵌入式测温或者暖通控制器的人参考。

1. 整体设计：为什么把温度拆成“本地”和“远程”两路

1.1 先定义清楚你要测的是哪个温度

很多人拿到题目就开始选传感器，结果做着做着才发现“本地”和“远程”根本不是一回事。本地温度通常指主控设备自己所在位置的环境温度，比如电控柜内的空气温度、PCB表面温度、MCU周围温度。HVAC柜子里继电器密集、电源模块发热、变频器辐射热量，柜内温度很容易比外界高好几度。嵌入式设备还要格外关心处理器附近温度，因为过热会直接导致电解电容寿命缩短、晶振频率漂移，甚至程序死机。

远程温度则是指远离主控板的测量点，常见的有风管内的送风温度、回风温度、管道水温、室内空气温度。这类测点距离主控少则几米，多则几十米，线缆要穿过强电区域和金属机壳，现场干扰比板内复杂得多。HVAC系统真正用来做温度控制逻辑的反馈量，往往正是这些远程温度，而不是主控板旁边那颗本地温度。

所以在设计一开始就要把这两类温度分开对待。本地温度追求的是“稳定、防过热、趋势可见”，远程温度追求的是“准确、抗干扰、可长距离传输”。两个需求完全不同，采集通道自然也应该分开设计。我在项目里把本地传感器直接挂在MCU的I2C总线上，远程传感器则放到远端节点上，用RS-485总线把数据传回主控。这个结构从原理上就避免了一根I2C线硬拉到十几米外导致的信号崩塌问题。

1.2 传感器选型与总线选型的取舍

温度传感器的选择上，我优先考虑了PJ85718DM这类数字输出传感器，而不是NTC热敏电阻或者PT100加调理电路。原因是HVAC控制器要兼顾成本、体积和量产一致性。数字传感器内部已经集成了ADC和温度校准，MCU通过I2C接口直接读数值，既不需要额外的运放和基准电压源，也不需要每台设备出厂时逐点校准模拟链路。

PJ85718DM这类传感器的典型参数可以这样理解：12位分辨率，测量范围覆盖-55°C到+125°C，典型精度±0.5°C，I2C从设备地址可以通过引脚配置。对于HVAC应用来说，±0.5°C已经足够支撑PID控制和舒适度判断，0.0625°C的LSB也远高于控制需求。更关键的是，数字传感器的线性度出厂已经调好，即使板子经过回流焊、传感器封装存在应力，也只需要做简单的两点校准修正，不需要像NTC那样自己拟合B值公式。

总线选型的考虑更直白。I2C是单端开漏总线，靠上拉电阻产生高电平，线缆一长，寄生电容变大，波形上升沿变缓，超过两三米就很难稳定工作。这跟两个人面对面喊话一样，距离近了没问题，隔一个操场再喊就听不清了。RS-485不一样，它是差分传输，A和B两根线上的电压差决定逻辑电平，天然抗共模干扰，几十米线缆完全不在话下。所以在“远程”这一路上，我最终选择了RS-485总线，而不是强行把I2C拉长。这样本地一路走I2C，远程一路走RS-485，两路互不干扰，各自用合适的物理层，整个系统才稳。

1.3 主控选型：PIC18F86J16够用吗

选PIC18F86J16这颗芯片，首先看中的是8位MCU的成本和资源平衡。PIC18F系列自带硬件I2C模块和UART模块，还有多个定时器和丰富的GPIO。一颗芯片同时驱动本地I2C传感器和远程RS-485总线完全够用，不需要为了这个问题上32位MCU。其次，这颗MCU工作在3.3V，和PJ85718DM这类数字传感器供电电压一致，省去了电平转换电路，I2C上拉直接接3.3V即可。

我在实际项目里评估过资源占用情况。整个测温任务以500ms为周期运行，本地I2C读取一次耗时不到10ms，远程RS-485查询一个从节点需要发送请求帧、等待响应、解析数据，整个过程大概30ms到100ms。加上中值滤波和滑动平均计算，CPU真正忙活的时间加起来不超过50ms，占有率很低。剩下的大把CPU时间还可以用来跑风扇控制、按键扫描、显示刷新和通信协议栈。

还有一个容易被忽略的选型理由是调试便利性。PIC18F86J16的I2C模块支持多主模式和中断，UART模块支持发送完成标志位，这些在写RS-485方向切换时序时非常关键。很多MCU虽然也有串口，但发送寄存器空和移位寄存器空两个标志位分得不够清楚，导致RS-485收发方向切换时丢最后一个字节。PIC18系列这两个标志位是分开的，能让我们精确控制方向切换时机。这个细节在后面章节会展开讲。

2. 核心细节拆解：I2C读温度与RS-485远程通信

2.1 PJ85718DM 的数据读取流程

不管传感器具体型号是什么，I2C接口的温度传感器读法都遵循一个固定套路：先写入寄存器指针，再读取数据寄存器。PJ85718DM这类器件一般有配置寄存器、温度寄存器高字节、温度寄存器低字节，以及ID寄存器。温度寄存器是两个字节，高字节在前，低字节在后，12位有效数据靠左对齐或靠右对齐，具体以手册为准。我用的是最常见的右对齐方式：高低字节拼成一个16位整数后右移4位，得到12位有效数据。

读温度的I2C时序如下：主机发START，发送传感器地址加写位，然后发送温度寄存器指针地址；接着发重复起始，再发送传感器地址加读位，依次读取高字节和低字节。这里特别要注意的是，读最后一个字节时主机必须回NACK，告诉传感器“不要再发了”，然后才发STOP。如果漏了这步，传感器会继续把下一个寄存器的数据发出来，总线时序就会错乱。

数据拼接的代码可以写成下面这样：

uint16_t read_temperature(uint8_t sensor_addr) { uint8_t hi, lo; uint16_t raw; i2c_start(); i2c_write((sensor_addr << 1) | 0); // 写地址 i2c_write(0x00); // 温度寄存器指针 i2c_restart(); i2c_write((sensor_addr << 1) | 1); // 读地址 hi = i2c_read(1); // 主机读字节，返回ACK lo = i2c_read(0); // 读最后一个字节，返回NACK i2c_stop(); raw = ((uint16_t)hi << 8) | lo; raw >>= 4; // 取12位有效数据 return raw; }

拿到12位原始值后，换算成摄氏度的公式很简单：摄氏温度等于原始值乘以0.0625。比如原始值是0x1A6也就是422，那么温度就是422乘以0.0625等于26.375°C。如果是负温度，原始数据以12位补码形式表示，要先做符号扩展再换算，否则会得到一个很大的正数。代码里可以先判断最高位，如果为1就把raw或上0xF000，得到16位补码再做乘法。

2.2 PIC18F86J16 硬件I2C初始化与波特率计算

PIC18F系列通过MSSP模块实现硬件I2C。初始化I2C主模式需要设置SSPCON1和SSPSTAT寄存器，配置时钟源、I2C使能、SDA和SCL引脚方向。波特率由SSPADD寄存器控制。在I2C标准模式下，主时钟与I2C时钟的关系是I2C时钟等于主时钟除以4倍的SSPADD加1，也就是：

Fclk = Fosc / (4 * (SSPADD + 1))

举例来说，如果主时钟是8MHz，目标I2C时钟是100kHz，那么SSPADD加1等于8MHz除以400kHz等于20，SSPADD就是19。这个计算在项目里我反复核对过，PIC18F系列主模式就是这个公式。如果使用内部振荡器8MHz，直接设置CPUDIV和振荡器配置字就行。

初始化代码框架大致是：

void i2c_master_init(void) { SSPCON1 = 0x28; // 使能I2C主模式，时钟源为Fosc/4 SSPCON2 = 0x00; SSPADD = 19; // 100kHz @ 8MHz SSPSTAT = 0x00; // 标准模式，位移位速率 TRISBbits.TRISB0 = 1; // SCL TRISBbits.TRISB1 = 1; // SDA }

这里有一个值得提醒的细节：I2C的SDA和SCL引脚必须配置为输入方向，因为MSSP模块会自己控制开漏输出。如果你图省事把引脚配置成普通推挽输出，硬件I2C就没法正常工作。这个坑我见过不少同行踩，表现为I2C总线一直忙或者读取数据完全不对。排查方法也很简单，看一下规格书里I2C引脚方向配置要求，改一行TRIS就行。

上拉电阻选择上，板内传感器用4.7kΩ比较稳。如果I2C总线上挂了多个传感器，或者线缆稍微长一点，可以降到2.2kΩ。上拉电阻太大，信号的上升沿会变缓；太小，传感器输出低电平时的灌电流会过大。如果发现I2C波形上升沿太缓，优先检查上拉电阻而不是直接降波特率。

2.3 RS-485物理层与Modbus轮询

远程温度传输我采用的是RS-485总线加Modbus RTU协议。RS-485是差分信号，A线和B线之间的电压差决定逻辑电平，即使两条线上同时叠加了共模干扰，只要接收器的共模输入范围没被超出，差分信号依然有效。这就是它能长距离传输的根本原因。HVAC现场变频器多、继电器通断频繁，共模干扰非常大，如果不用差分传输，远端读数很容易在设备启停的瞬间突然跳变。

RS-485通信需要一颗收发器芯片。收发器芯片的DE引脚控制发送使能，RE引脚控制接收使能，很多芯片把这两个引脚合并成一个。实际使用时把这个合并的方向引脚接到MCU的一个GPIO上，发送数据前拉高电平，发送完成后拉低电平切回接收模式。方向切换的时机是重中之重，必须在最后一个字节的发送移位寄存器完全清空之后才能拉低方向引脚，否则最后一个字节会被截断，远端设备收到的帧不完整，回复就永远不会来。

Modbus RTU协议的请求帧格式是：从机地址、功能码、起始寄存器地址高字节、起始寄存器地址低字节、寄存器数量高字节、寄存器数量低字节、CRC16低字节、CRC16高字节。读取远程温度一般用功能码0x03读保持寄存器或0x04读输入寄存器。我习惯把温度值放在输入寄存器里，语义上更符合“测量值”的定位。远程节点收到请求后，校验地址和CRC，然后读取本地连接的PJ85718DM传感器，组织响应帧返回。

主机轮询远程节点的流程是：发送查询帧，启动超时计时，等待响应帧，校验CRC，解析温度值。整个流程放在状态机里执行，超时时间设置为100ms。如果超时，重试两次，仍然失败就把该节点标记为故障，下一轮再试。采用这样的重试策略之后，现场偶发干扰导致丢帧的情况就不容易影响整体控制了。波特率方面，HVAC现场我建议优先选择9600bps或者19200bps，不要盲目上38400。虽然RS-485带宽足够，但现场线缆质量参差不齐，波特率越高越容易在过长的总线末端出现反射误码。稳定比速度重要得多。

3. 实操过程：从硬件连接到软件联调

3.1 硬件连接与最小系统搭建

主控板和远程节点板的硬件连接其实不复杂。主控板上的核心器件包括PIC18F86J16、一颗PJ85718DM作为本地传感器、一颗RS-485收发器、电源电路和复位电路。远程节点板上放一颗低成本MCU、一颗PJ85718DM和另一颗RS-485收发器。主控作为总线主机，远程节点作为从机。

连接信号可以用下面这张表快速对照：

电源方面，传感器和MCU统一使用3.3V。RS-485收发器需要注意供电电压，如果能找到3.3V供电的型号最省事，可以避免MCU和收发器之间的电平不匹配。如果只能用5V供电的收发器，就要确认MCU的UART输出高电平是否满足收发器的输入高电平门限，通常还需要加电平转换或者用电阻分压。建议直接选3.3V版收发器，少一个环节就少一类问题。

PCB布局的时候尽量让本地传感器离开继电器、变压器、开关电源和功率电阻这些发热大户。不要把传感器贴在这些器件旁边，否则测出来的不是环境温度而是板子自己的焦耳热。我在项目里吃过这个亏，第一版PCB把传感器放在电源IC附近，读数一直比实际环境温度高2°C左右，后来把传感器挪到板边缘，温度才恢复正常。加长PCB走线并开槽隔离热源，效果更明显。

3.2 软件状态机与轮询时序

软件结构是整个方案里最值得花时间设计的地方。如果直接用一个for循环，先读本地传感器，再发送远程查询，然后等待响应，最后更新显示，代码看起来简单，但实际运行中远程节点一旦无响应，整个系统就会卡在等待函数里，风扇控制、按键扫描全部停摆。这个在HVAC设备上是不可接受的，因为主控不仅要测温，还要持续控制继电器和风机。

我采用的方案是状态机加超时计时器。主循环周期固定为10ms，每次循环只执行当前状态对应的动作，然后立刻返回。状态机定义大致是这样的：

typedef enum { ST_IDLE, ST_LOCAL_READ, ST_LOCAL_FILTER, ST_REMOTE_SEND, ST_REMOTE_WAIT, ST_REMOTE_PROCESS, ST_ERR_HANDLE } app_state_t; void main_loop(void) { static app_state_t state = ST_IDLE; uint32_t tick = get_tick_ms(); switch (state) { case ST_IDLE: if (tick - last_cycle >= 500) { last_cycle = tick; sensor_read_count = 0; state = ST_LOCAL_READ; } break; case ST_LOCAL_READ: // 读取PJ85718DM原始值并保存到数组 // 连续读取8次后进入滤波状态 break; case ST_LOCAL_FILTER: // 中值滤波 + 滑动平均 // 计算得到本地温度 // 如果没有远程节点，则回到ST_IDLE break; case ST_REMOTE_SEND: // 组装Modbus RTU查询帧，发送到RS-485总线 // 切换方向引脚，启动100ms超时 state = ST_REMOTE_WAIT; break; case ST_REMOTE_WAIT: // 等待串口接收完成或超时 // 若收到一帧完整数据，转ST_REMOTE_PROCESS // 若超时，重试计数加1，重试2次后标记故障 break; case ST_REMOTE_PROCESS: // 校验CRC，解析温度寄存器值，更新全局温度变量 state = ST_IDLE; break; } }

这个状态机的好处是，不管远程节点是否响应，主控最多等100ms就继续跑其他代码。500ms的周期里，有差不多400ms是空闲的，足够跑风扇控制、继电器逻辑和显示刷新。实测下来，整个HVAC控制器的整体响应速度比之前用阻塞延时方式快得多，而且反复插拔远程节点都不会造成主控卡死。

3.3 温度滤波与校准

数字温度传感器虽然比模拟传感器干净，但在HVAC现场还是会出现偶发的跳变。比如继电器吸合的瞬间，电源电压抖动一下，传感器读数就可能突跳0.5°C甚至1°C。如果把这部分突跳直接送进控制逻辑，风阀就会跟着乱动。我的做法是双层滤波：先做中值滤波，再做滑动平均。

中值滤波的做法是连续采集8个原始值，去掉最大值和最小值，对剩下6个值取平均。这样的好处是能一次性剔除粗大误差，比如雷击或继电器电弧造成的极小概率尖峰，不会被平均运算摊薄到正常数据里。滑动平均则是把最近几次中值滤波结果做加权平均，抑制周期性低频波动。实测下来，原始数据波动大约±0.5°C，经过中值加平均之后能压到±0.1°C以内，对HVAC控制来说已经完全够用。

校准流程是这类传感器方案里最容易忽略的部分。PJ85718DM这类数字传感器出厂时虽然做过校准，但焊接应力、PCB走线阻抗、传感器封装散热条件都会引入轻微误差。所以我在每台设备量产后做两点校准。0°C校准点用冰水混合物，把传感器探头完全浸入并等待热稳定；50°C校准点用恒温水浴，同样等足够时间。记录两个点的测量误差，计算斜率和偏移，公式是真实温度等于测量温度乘以斜率再加偏移。校准参数存到MCU的EEPROM里，上电时加载。这个流程看起来简单，实际效果很明显，校准前整机误差可能到±1°C，校准后能控制在±0.3°C以内。

3.4 上位机联调与波形验证

联调阶段我习惯在固件里固定一个调试串口，输出格式类似这样的日志：

[T+0000] LOCAL RAW=0x01A6 TEMP=26.375C [T+0100] REMOTE1 RAW=0x0150 TEMP=21.000C CRC=OK [T+0500] LOCAL RAW=0x01A5 TEMP=26.312C

日志里必须带时间戳，这样排查现场问题时能判断数据跳变发生在什么时机，比如是继电器动作的瞬间还是压缩机启动的瞬间。很多同行调试时不打印时间戳，出问题后完全无法还原时间线，效率非常低。

硬件波形验证方面，I2C信号用逻辑分析仪看，采样率24MHz以上就够。主要确认START条件、传感器地址、寄存器指针、ACK位和数据字节的顺序。RS-485信号最好用示波器配合差分探头看A-B线间电压。总线空闲时的正常状态是A线比B线高200mV以上，这是偏置电阻在起作用。发送数据时A-B差分幅度应该在1.5V到5V之间，具体取决于收发器型号和总线负载。如果波形幅度很小或者边沿有振铃，优先检查终端电阻和总线拓扑结构。我最近一次实测，从主控到10米外的远程节点，9600bps下波形依然干净，读数稳定在20.9±0.125°C，整个500ms周期内CPU占用率不到10%。

4. 常见问题与排查技巧实录

4.1 I2C读回全FF或者全00

这是I2C测温最容易遇到的现象，其实原因就那么几个。第一个是传感器地址不对。PJ85718DM类传感器的I2C地址由地址引脚决定，引脚接法不同，地址就不同。排查时先写一个I2C扫描函数，枚举0x00到0x7F所有地址，看看实际能应答的地址是什么，比对规格书确认接线是否正确。

第二个原因是上拉电阻没焊或者焊错。I2C总线上没有上拉电阻，SDA和SCL就无法产生高电平，读出全是0。飞线连接时尤其容易漏焊上拉，因为很多评估板自带内部上拉，移植到自己板子时就把这个细节忘了。

第三个原因是传感器上电后还没准备好。有些传感器上电后需要几十毫秒完成内部初始化，如果MCU上电比传感器快，MCU启动后立刻读传感器就会读到全FF。解决办法是在I2C读取之前加50ms延时，让传感器完成内部状态准备。这个坑在快速启动要求高的项目里特别常见，加一个上电等待标志就解决了。

最后一个原因是SDA引脚方向配置错误。硬件I2C模式下，SDA和SCL必须配置成输入方向，由MSSP模块控制开漏输出。如果配置成普通推挽输出，模块无法正常拉低总线，读取就会一直失败。用示波器抓一下SDA和SCL波形就能看出来，波形上只有高电平没有低电平翻转，基本就是这个问题。

4.2 远程读数时有时无，一长线就丢包

RS-485丢包在HVAC现场属于高频问题，几乎每个做远程通信的人都会遇到。最常见的丢包原因是收发方向切换时序不对。很多UART模块发送完成后，数据已经被移出发送缓冲，但移位寄存器可能还没完全送出最后一个停止位。如果这时候立刻把方向引脚拉低，最后一个字节的停止位就会被截断，对端收到的是一个不完整帧，自然不回响应。

解决方法是发送完最后一个字节后，等待UART模块的发送移位寄存器空标志位置位，再延时1ms，然后才切换方向引脚。也就是“发完缓冲→等移位完成→延时→切方向”这个固定顺序。这个1ms延时的经验值非常重要，太短了可能没等到底层彻底发送完，太长了又浪费轮询周期。

第二个常见原因是总线缺少偏置电阻。RS-485总线空闲时，如果没有偏置，A和B之间电压差可能接近0，接收端会把噪声当成数据，产生大量乱码。解决方式是加偏置电阻，比如A线上拉到电源，B线下拉到地，让空闲状态稳定在A高B低。终端电阻也需要检查，总线的物理两端各放一个120欧姆终端电阻，线上信号才不会反射。注意只有两个节点时，终端电阻加在两端即可，中间的节点不要加。

第三个原因是现场布线问题。RS-485双绞线如果和变频器输出线、220V电源线绑在同一个线槽里，变频器开关瞬间会产生强烈的电磁干扰，直接耦合到总线上。解决办法是双绞线单独走线，尽量远离动力线，条件允许时加上磁环和TVS管。

4.3 温度值乱跳

温度值跳来跳去，首先怀疑传感器自热。数字传感器本身工作电流很小，但如果距离电源IC、功率电阻太近，电源发热会通过PCB铜皮传导到传感器上，读数会比真实环境温度偏高2到3°C。正确处理是让传感器远离热源，PCB上可以开槽阻断铜皮导热路径。如果传感器必须要放在发热器件旁边，那就改用探头式传感器，让封装离开板面。

电源纹波也会导致温度波动。PJ85718DM这类数字传感器的内部ADC参考电压可能直接取自电源，如果3.3V纹波太大，转换结果就会抖动。解决办法是在传感器电源引脚旁边加100nF陶瓷电容和10uF钽电容搭配退耦。不要图省事只放一个100nF，低频纹波还是需要大容量电容去吸收。

软件层面的滤波也很关键。如果只做单次平均，偶发尖峰依然会拉高平均值。我最终使用的方案是先做中值滤波剔除粗大误差，再做滑动平均平滑趋势，两层滤波叠加后，异常值的权重被大幅削弱。可以这样理解：中值滤波是给数据装了一个“保险丝”，滑动平均是给数据加了一个“阻尼器”，两者配合才既快又稳。

4.4 校准完仍然偏

校准后温度还是不准，最常见的问题是校准点没泡够时间。冰水混合物的温度虽然是0°C，但传感器封装有热阻，探头插进去立刻读数，测的其实是探头外壳的温度而不是内部芯片的温度。正确做法是把探头完全浸入冰水混合物中，等待1分钟以上，让传感器内部完全达到热平衡再记录校准值。50°C水浴同理，不要看着温度计到位就开始校准，要给传感器足够缓冲时间。

第二个问题是校准只修偏移没修斜率。两点校准的正确做法是同时计算斜率和偏移，只做单点偏移校准只能在某个温度附近准确，温度一拉远误差又回来了。数据传感器出厂线性度已经不错，两点校准主要修焊接应力和PCB带来的系统误差，这个误差表现为近似线性，所以一个斜率加一个偏移就能很好修正。

第三个问题是校准参数在MCU上电时被默认值覆盖。有些工程把校准参数放在EEPROM里，但初始化代码里用了固定默认值给校准变量赋值，导致每次上电都跳回未校准状态。排查时直接看初始化函数里有没有从EEPROM读取校准参数的逻辑即可。

4.5 现场排查工具与方法

现场排查温度问题时，工具不需要多贵，关键是方法要对。万用表可以测RS-485总线的A-B差分电压，正常空闲时A比B高0.2V以上，发送数据时显示跳动电压。逻辑分析仪适合抓I2C时序，8通道的就能用，重点看ACK位和数据字节排列。如果怀疑RS-485收发器方向切换问题，可以拿示波器同时抓MCU的TX引脚和方向引脚，对比发送结束时刻和方向切换时刻之间的延时。

我在每个项目的固件里都会预留一个诊断命令，通过调试串口发送特定字符就能输出所有传感器的原始寄存器值、滤波后的温度值、RS-485重试次数和CRC校验结果。这个功能在现场问题排查时太有用了，很多时候只需要让现场人员把串口日志发回来，就能判断是传感器硬件问题还是总线通信问题，不用专程跑一趟现场。这个诊断功能代码量很小，但长期维护设备时价值极高。

我个人在实际操作中的体会是，测温系统的稳定性其实不是靠某一个环节实现的，而是传感器选型、物理层布线、软件状态机、滤波算法和校准管理这些环节共同作用的结果。其中任何一环偷懒，最终都会在现场表现为某个莫名其妙的温度跳变。最后再分享两个小技巧：第一，所有日志和时间戳绑定，遇到间歇性故障时能迅速定位是在哪个事件前后出现的异常；第二，远程节点板上预留拨码开关和跳线位置，后期增加测点节点时不需要改主控程序，直接把地址拨好插上总线就行。这套“本地I2C加远程RS-485”的结构，后续想扩成四路、八路温度采集也很直接，把远程节点复制几份、地址错开即可，不需要推倒重来。