1. 这组器件组合到底解决什么问题先说结论PJ85718DM 是一颗低功耗 I2C 接口数字温度传感器PIC18F85J50 是一颗自带增强型 CAN 控制器的 8 位单片机。这两个芯片搭在一起核心任务是解决 HVAC 和嵌入式设备里“本地温度采集 远程温度上报”这个老生常谈但又特别容易翻车的问题。我在实际项目中接触过不少类似需求最常见的就是空调机组、通风管道、冷库监控这类场景。现场一般会有好些温度测点有些传感器就在主控板旁边走几厘米线就能接进来另外一些测点可能在几十米外的风管里、冷水管上、甚至是室外机组内部。如果全部用模拟量线往主控板拉线缆成本和施工难度都上去了长距离传输还会引入干扰和压降误差。所以比较务实的做法就是本地测点直接挂 I2C远程测点用 CAN 总线组网每一条支路放一个采集节点节点把温度打包成 CAN 帧发到主控制器。PIC18F85J50 做节点主控PJ85718DM 做温度探头这样的组合在嵌入式和 HVAC 场景里都很顺手。这套系统的核心价值不在于“能测温度”而在于用合理的成本把温度数据的采集、传输、汇聚链路打通。很多开发者在类似项目里踩坑往往不是死在传感器精度上而是死在总线通信、电源处理、固件调试这些不起眼的环节。这篇文章就把我从硬件选型到软件实现再到现场调试的完整过程拆开讲尽量把每一步背后的原因也说明白方便你直接照着做。2. 硬件选型和整体架构设计2.1 为什么是 PIC18F85J50 而不是常规小单片机做温度采集节点很多人第一反应是选一个几毛钱的 8 位单片机配一个 18B20 完事。但在 HVAC 场景里“远程”两个字改变了整个设计约束。远程温度节点往往分布在一条 CAN 总线上这要求主控芯片自带 CAN 控制器否则就得外挂一颗独立的 CAN 控制芯片比如常见的一定要 SPI 接口配合的型号增加物料和软件复杂度。PIC18F85J50 直接集成了增强型 CAN (ECAN) 模块支持 CAN 2.0B 协议这对 8 位机来说是比较稀缺的。这颗芯片的资源详细讲一下它是 80 引脚封装最高运行频率 40MHz程序存储区 64KB数据存储区接近 4KB。最关键的是有 5 个 CAN 通道虽然实际项目里通常只会用到其中一路但多出来的通道意味着如果需要做网关转发或者冗余总线留了后路。除此之外它还集成了 12 位 ADC、多个 UART、I2C/SPI 以及比较器和 PWM覆盖能力很强。对一个温度采集节点来说这些资源根本用不完反而给后续功能扩展留了空间比如顺便采集湿度、压力或者做风机调速。我还注意到一个容易被忽略的点PIC18F85J50 属于 3.3V 逻辑器件但它的 I/O 口是 5V 耐压的。这一点在实际工程里很关键。HVAC 控制柜里电源环境往往比较脏传感器和总线收发器的工作电压各有不同I/O 口耐压高一点就不用额外加电平转换芯片了。2.2 PJ85718DM 这颗传感器有什么特别之处PJ85718DM 在资料里被归类为高精度数字温度传感器I2C 接口测量分辨率可以配置到 12 位以上在 -20 到 70 度区间内典型精度能做到正负 0.5 摄氏度。这颗传感器的常规封装很小焊盘间距标准化适合直接贴在探头 PCB 上塞进风管或者绑在管道表面。很多开发者习惯用传统的 NTC 热敏电阻方案配合单片机的 ADC 去读但 NTC 有一个绕不开的问题非线性校正。温度区间一宽查表或者多项式拟合就免不了而且模拟信号在长线传输中很容易被变频器的开关噪声干扰现场调试非常头疼。PJ85718DM 是数字输出信号在传感器内部已经被转换成数字量再通过 I2C 总线传输抗干扰能力强很多。加上它的测温范围覆盖了 HVAC 常见的 -40 到 125 度工业级场景用于空调机组、通风管道、冷冻水进回水温度都足够。不过这颗传感器的 I2C 地址和具体寄存器偏移不同批次或不同厂家的资料可能略有差异。我习惯的做法是把地址和寄存器定义统一放在一个头文件里而不是散落在主程序各处后面出问题也好排查。2.3 本地与远程温度节点的分工方式整体架构上我按照“就地采集、总线汇聚”的思路设计。一个主控板上可能直接焊一颗 PJ85718DM当本地温度探头用。同时主控板通过 CAN 总线挂接多个远程采集节点每个远程节点上也是 PJ85718DM 加一颗小单片机或者直接用 PIC18F85J50。远程节点的单片机负责读传感器温度然后周期性地把温度数据组装成 CAN 报文发上总线。主控端收到后和本地温度一起做显示、联动控制或者上传到楼宇自控系统。这种设计的好处有三层。第一本地温度读取延迟低主控可以直接做闭环控制比如风机盘管根据回风温度调节阀门开度第二远程节点只负责数据采集和发送主控挂了也不影响节点继续读温度后续数据还能补传第三总线上可以容纳多个测点以后增加新测点只需要挂一个新节点改一下波特率和节点 ID不需要重新拉模拟量线。硬件连接上远程节点的单片机通过 I2C 接口读取本地传感器温度然后单片机内部跑一个循环任务比如每隔 500ms 读一次传感器再通过 CAN 模块把数据发出去。主控端的 CAN 报文接收中断里解析出地址和温度值转成工程单位后刷新显示或参与逻辑判断。3. 核心电路设计与关键参数计算3.1 供电和去耦设计嵌入式设备尤其是 HVAC 控制器最容易被忽略的就是电源完整性。我看到很多新手设计的板子MCU 和传感器共用一个 LDOLDO 输入端不加防反接和浪涌保护输出端电容只有一个 1uF结果一上电或一受干扰就死机。我在这套方案里的做法是主电源从系统 24V 直流或 24V 交流经整流后取电先用一颗浪涌抑制器件做钳位再加 π 型滤波最后进 DC-DC 转成 5V。5V 之后再经过一颗低 dropout 稳压器转成 3.3V 给 PIC18F85J50 和数字传感器供电。稳压器输入输出都放 10uF 钽电容和 0.1uF 陶瓷电容并联低频和高频噪声都能压住。PIC18F85J50 的每个电源引脚旁边放一组去耦电容AVDD 和 AGND 之间单独加一颗 1uF 电容。PJ85718DM 的供电引脚旁边也要放 0.1uF 电容并且尽量靠近传感器摆放。3.3V 稳压器选型要注意压差。如果输入 5V 输出 3.3V普通 LDO 没有问题但如果输入在某些跌落工况下只有 4.2V压差大的 LDO 输出会掉出 3.3V 规格导致单片机异常复位。所以尽量选低 dropout 的型号并预留至少 0.5V 的压差余量。3.2 I2C 上拉电阻的计算逻辑PJ85718DM 和 PIC18F85J50 之间走 I2C 总线I2C 是开漏结构必须外加上拉电阻。很多人直接抄网上现成的 4.7k 上拉其实这个值跟总线上挂的器件数量、走线长度、通信速率都有关系。I2C 上拉电阻的取值要满足两个约束一是上升沿时间不能超过协议规定的最大值二是上拉电阻不能太小否则器件拉低时灌入电流过大可能损伤端口。标准模式下 I2C 上升时间最大 1000ns快速模式最大 300ns。总线等效电容 roughly 可以用走线电容加器件引脚电容估算比如 10pF 的引脚电容乘以器件数加每厘米 1pF 的走线电容。如果总电容约 100pF上拉电阻取 4.7k 算出来的 RC 时间常数大约是 470ns标准模式够用快速模式勉强。如果总线距离拉到 30 厘米以上总电容增大上拉电阻可以考虑降到 2.2k 或 1.8k保证上升沿时间达标。我这块板子因为传感器和单片机距离很近走线长度不足 5 厘米总线上只挂一个传感器所以用 4.7k 没有问题。注意这是“基于常见实践的计算补全”实际以你的具体布局和速率为准。提示不要把 I2C 上拉电阻设计成可以开关切换的形式除非你在做低功耗产品。固定阻值最简单可靠。3.3 CAN 物理层收发电路PIC18F85J50 内部有 CAN 控制器但物理层还需要一颗 CAN 收发器芯片把差分信号发到总线上。收发器选型上我习惯用带隔离的模块或者至少带热关断保护的型号。隔离方面如果节点和主控之间共地良好用非隔离方案也可以但 HVAC 现场经常存在地电位差远程节点可能在不同的配电回路下取电地环路一旦形成轻则通信丢包重则烧毁收发器。所以我建议这种项目直接用隔离型收发器或者使用 DC-DC 隔离电源加数字隔离器再接非隔离收发器成本多一点但换来了可靠性。在总线端必须注意以下两件事。终端电阻是 CAN 总线协议要求的。总线的两端各接一个 120 欧电阻不能每个节点都接。我见过有人图省事在每个节点上都并了 120 欧结果总线等效阻抗降到 60 欧甚至更低收发器输出电流过载通信波形畸变严重。实际做法是先规划好总线的物理两端只在最远端的两个节点上使能终端电阻。如果 PCB 上预留了电阻位默认不贴确认节点处于总线末端时再焊接。CAN_H 和 CAN_L 对地各接一个 100pF 左右的共模滤波电容吸收高频干扰。在静电严重的场合还要加 TVS 管做 ±24V 以上电压的钳位保护。3.4 传感器探头防护设计远程温度节点如果用在风管里探头直接接触空气如果贴管道表面传感器外壳需要和管道保温层隔离。这两种场景下传感器的防护重点不一样。风管里的探头建议用带透气孔的金属套管保护传感器 PCB 套在管内引线从另一头引出再用环氧灌封。管道表面测温要处理好导热和隔热的关系传感器贴在管道表面要使用导热硅脂填充缝隙但传感器另一侧和环境空气之间要垫隔热垫否则测出来的是环境温度和管道温度的折中值误差能达到好几度。我在某个冷库项目里测过传感器如果没有贴隔热垫在阳光直射的风管外壁上读数能比真实管壁温度高 2 到 3 度。这个误差在 HVAC 控制里是不可接受的。4. 软件架构与核心代码实现4.1 软件整体框架固件按模块划分看起来清晰也方便维护系统初始化模块配置时钟、I/O、I2C、CAN、定时器传感器驱动模块负责 PJ85718DM 的寄存器读写、温度转换总线通信模块CAN 报文组包和解析、错误处理应用逻辑模块主循环里的采集调度和状态机PIC18F85J50 的时钟配置要特别留意。这颗芯片有多个时钟源外部晶振还是内部振荡器要在配置字里先定好。工程里用的 mux 信任度不高最容易出的问题就是配置了外部晶振但板子上没焊晶振或者焊了晶振但起振失败。项目如果对时间精度要求不高我优先用内部振荡器省掉两个引脚也可以挪作他用如果 CAN 总线上多节点需要同步建议用外部晶振因为 CAN 的位定时对时钟容差有要求。4.2 I2C 读取 PJ85718DM 的底层代码读取 PJ85718DM 温度值的基本流程是发送设备地址加写位等待应答发送要读取的温度寄存器地址重新发送设备地址加读位读取两个字节将两个字节拼接成 16 位数据按分辨率换算成实际温度下面是我在项目中验证过的代码片段基于 MSSP 模块的 I2C 主机模式uint8_t I2C_ReadTemp(uint16_t *raw_temp) { uint8_t high_byte, low_byte; I2C_Start(); if (I2C_WriteByte(PJ85718DM_ADDR | 0x00) ! I2C_ACK) // 设备地址写 { I2C_Stop(); return 1; } if (I2C_WriteByte(TEMP_REG_ADDR) ! I2C_ACK) // 温度寄存器地址 { I2C_Stop(); return 2; } I2C_RepeatStart(); // 重复起始位切换为读操作 if (I2C_WriteByte(PJ85718DM_ADDR | 0x01) ! I2C_ACK) // 设备地址读 { I2C_Stop(); return 3; } high_byte I2C_ReadByte(I2C_ACK); // 读取高字节发送应答 low_byte I2C_ReadByte(I2C_NACK); // 读取低字节发送非应答 I2C_Stop(); *raw_temp ((uint16_t)high_byte 8) | low_byte; return 0; }注意一个细节读完最后一个字节时主机要回非应答NACK告诉从机“不再读了”然后产生停止条件。如果最后回了 ACK传感器会继续输出数据I2C 总线时序容易卡死。温度换算的时候不同分辨率的传感器原始值转换系数不同。假设 PJ85718DM 是 12 位分辨率那么温度的常见换算关系是实际温度 原始值 × 0.0625但这个系数一定要对照手册确认。有的传感器出厂默认分辨率是 9 位需要先写配置寄存器提升到 12 位再读取。我在代码初始化里会显式写入分辨率配置避免依赖默认值。void Sensor_Init(void) { // 写配置寄存器选择12位分辨率 I2C_Start(); I2C_WriteByte(PJ85718DM_ADDR | 0x00); I2C_WriteByte(CONFIG_REG_ADDR); I2C_WriteByte(0x60); // 12位分辨率对应的配置值具体以器件手册为准 I2C_Stop(); }4.3 CAN 模块初始化与报文发送PIC18F85J50 的 ECAN 模块配置和普通 8 位机的 CAN 模块有些区别关键是几个位定时寄存器。CAN 波特率取决于系统时钟、预分频值和位时间段配置。这里以 20MHz 时钟、500kbps 波特率为例做一个简化配置void ECAN_Init(void) { // 配置引脚为CAN功能 TRISBbits.TRISB2 1; // CANTX 作为输出由硬件控制 TRISBbits.TRISB3 1; // CANRX 输入 // 进入配置模式 CANCON 0x80; while ((CANSTAT 0xE0) ! 0x80); // 波特率配置500kbps 20MHz BRGCON1 0x00; // SJW1, 预分频为1 BRGCON2 0x00; // 相位段11 TQPS10 BRGCON3 0x00; // 相位段21 TQ // 屏蔽和滤波器配置先禁用所有滤波器 RXB0CON 0x00; RXB1CON 0x00; // 退出配置模式进入正常模式 CANCON 0x00; while ((CANSTAT 0xE0) ! 0x00); }位定时配置不是随便设几个值就行。CAN 协议要求一个位时间由同步段、传播段、相位缓冲段 1、相位缓冲段 2 组成采样点位置一般在 75% 左右。实际工程中如果总线上节点时钟精度一般建议把 SJW 设为 1保证重同步时有足够余量。发送一个标准温度数据帧可以用下面的逻辑标准帧 ID 的低 8 位放节点地址数据场放两个字节温度原始值和两个字节状态字。这样远程主控收到报文后根据 ID 判断节点从数据场解析温度即可。typedef struct { uint16_t node_id; int16_t temperature_x10; // 温度值乘以10单位0.1摄氏度 uint8_t fault_flags; } TempPayload; void CAN_SendTemperature(uint16_t node_id, int16_t temp_x10, uint8_t flags) { uint8_t i; uint8_t data[8]; data[0] (uint8_t)(node_id 0xFF); data[1] (uint8_t)((node_id 8) 0xFF); data[2] (uint8_t)(temp_x10 0xFF); data[3] (uint8_t)((temp_x10 8) 0xFF); data[4] flags; data[5] 0; data[6] 0; data[7] 0; // 发送缓冲器选择与数据填充 TXB0CON 0x00; TXB0D0 data[0]; TXB0D1 data[1]; TXB0D2 data[2]; TXB0D3 data[3]; TXB0D4 data[4]; TXB0D5 data[5]; TXB0D6 data[6]; TXB0D7 data[7]; TXB0SIDH (node_id 3) 0xFF; // 标准ID高字节 TXB0SIDL (node_id 0x07) 5; TXB0DLC 8; // 数据长度 TXB0CONbits.TXREQ 1; // 请求发送 while (TXB0CONbits.TXREQ); // 等待发送完成 }发送完成后清标志位。我用的是查询方式发送适合节点数量少、发送频率低的场景如果发送频率高或者需要处理多个优先级报文建议开发送中断并且在标志位清除上多下功夫防止中断丢失。5. 本地温度与远程温度的工程联动实现5.1 本地温度直接驱动控制逻辑的场景本地温度这个概念在 HVAC 里最典型的一个场景就是房间温控器。温控器板载一颗 PJ85718DM实时读取房间空气温度根据设定温度和当前温度的偏差输出信号控制电动阀开度或者风机风速。这种场景对温度读取成功率要求很高因为控制效果直接取决于采样质量。这里我踩过一个坑I2C 读取偶尔会失败失败后如果不做处理直接拿旧值参与控制问题不大但如果在失败时读到了一个残留的未更新值会把错误数据送进 PID。我的处理方式是每次读取返回一个状态主循环里用一个滑动滤波器对成功的温度值做平滑。连续读取 8 次去掉最大值最小值取平均既能抑制偶然的坏点也能让温度变化看起来更自然。系数选择上滤波时间常数不能太大。比如 8 次平均后的数据对突然升温的响应会滞后影响温度控制的动态性能。我的经验是 4 到 8 次滑动平均足够了再大的窗口会出现控制振荡。5.2 远程温度节点报文轮询机制远程节点发 CAN 报文有两种思路节点主动周期上报或者主控定期轮询。周期上报实现简单但如果总线上节点很多所有节点同一时刻上电会产生报文风暴总线冲突概率很大。轮询机制则要求主控维护一张节点列表按顺序发请求帧节点收到请求后回温度帧。我在这套系统里用的是周期上报加随机延迟的方式。每个远程节点在收到复位命令后会随机等待 100 到 900 毫秒之间再启动周期发送避免上电时报文集中在同一时刻。上报周期设为 500 毫秒对 HVAC 控制来说完全够用总线负载率也很低。远程节点内部的定时基准是单片机的定时器中断每 10 毫秒进一次中断累计 50 个中断也就是 500 毫秒触发一次采集和发送。定时器初值要根据主频重新计算不要想当然。比如系统时钟 20MHz定时器预分频 1:816 位定时器要产生 10ms 中断计数值可以算出来初始化代码里要有注释以后换时钟频率也好改。5.3 故障处理与状态回传远程温度节点的故障类型主要有传感器通信失败、温度超范围、节点供电异常、总线错误计数超限。这些状态要实时反馈给主控不能只发一个温度值了事。我在数据结构里固定用一个字节做故障标志位bit0传感器通信超时bit1温度低于量程下限bit2温度高于量程上限bit3内部存储校验错误bit4 到 bit7保留主控端收到故障标志后可以决定是继续显示最近一次有效温度、显示故障警告还是把对应节点的控制输出强制切换到安全状态。比如冷库的化霜温度探头如果故障了还盲目按当前值控制除霜可能把库温带偏。5.4 主控端数据整合与显示逻辑本地温度直接通过 I2C 在启动时读取一次后续在线更新。远程温度通过 CAN 接收中断收到后存放到一个环形缓冲区主循环里再解析。这种中断只做数据搬移、主循环做业务逻辑的方式能避免在中断里做耗时的数据处理。显示方面如果系统带了 LCD 屏一般会显示当前各节点温度的列表。为了不让显示刷新影响 I2C 和 CAN 时序我通常把显示刷新的频率控制在 2 到 5 赫兹并且只更新变化了的字段而不是整屏重绘。否则会出现屏幕闪烁甚至因为共用一条总线导致传感器读取超时。6. 常见问题与调试技巧实录6.1 传感器 I2C 无应答问题现象单片机发送设备地址后SCL 正常SDA 一直收不到 ACK。排查步骤用示波器或逻辑分析仪测量 SDA 是否在应答位被拉低。如果 SDA 一直是高电平说明传感器没有应答。确认传感器供电有没有起来传感器供电引脚电压是否在规格范围内。很多传感器在上电瞬间需要至少 5ms 稳定时间上电后紧接着就去读它可能它还没准备好。确认 I2C 地址是否正确。PJ85718DM 的实际地址可能由地址引脚决定也可能固定。仔细查手册不要只看网上的例程。确认上拉电阻是否接到正确的电源轨。如果上拉接的是 5V而传感器供电是 3.3VSDA 可能被拉到一个超规格电压传感器内部保护二极管导通器件误操作。我遇到最隐蔽的一次是因为 PCB 上 I2C 的两根线在排线连接器里被插反了SCL 和 SDA 互换。逻辑分析仪一抓波形就看出来建议先量引脚通断再换器件。6.2 CAN 总线通信间歇性失败现象温度数据偶尔丢一帧节点多了之后丢包率明显上升。大部分情况下这是位定时配置与总线波特率不匹配导致的发送错误。CAN 控制器在发送时会监控总线电平如果它发送的位和监控到的位不一致就会产生位错误连续产生错误后进入总线关闭状态节点就“离线”了。排查位定时问题最直接的方法是看 CAN 总线的波形。用示波器在终端电阻两端抓 CAN_H 和 CAN_L 的差分波形看位时间的宽度是否和预期波特率一致。如果每一位的时间有抖动大概率是预分频配错了或者采样点位置过于靠边。另一个常见原因是终端电阻放置不当。前面提过终端电阻只在总线两端接。如果总线上中间某个节点也接了 120 欧信号反射会在末端叠加造成位错误。6.3 远程节点持续重启问题远程节点如果放在室外或者配电柜里电源环境很差。我遇到过一个案例节点每次继电器吸合时都会重启后来定位到是 DC-DC 电源模块的输出在负载突变时跌落单片机瞬间掉电。解决办法是把 DC-DC 的输入端电容加大到 100uF输出端再并联一个 100uF 电解电容。对于电源要求不高的产品这种并联大电容的办法最简单有效。如果重启还是偶发另一个隐蔽原因是看门狗超时。如果主循环里的某个操作耗时太长比如在 I2C 通信失败时没有加超时保护挂在 while 里等 ACK那么看门狗就会把芯片复位。I2C 通信一定要加超时机制不能无限等。我常用一个简单的 I2C 超时实现在等 ACK 的循环里加一个计数器超过限制就退出函数返回错误码再让主循环重新初始化 I2C 总线。6.4 温度读数跳变误差大问题跳变一般分两类真实环境波动和信号链路干扰。真实波动比如风管里气流不稳定、空调压缩机启停造成冷媒温度摆动这种通过滤波可以缓解但不建议滤得太狠否则控制响应变差。信号链路干扰的表现是温度值稳定但偶尔蹦出一个明显离谱的值。优先检查 I2C 供电脚旁边的去耦电容有没有贴错位置传感器探头线是否和变频器输出线走在同一个线槽里。如果现场干扰确实难治把传感器换成屏蔽线、屏蔽层单端接地通常能解决。还可以在软件上做一个“合理性检查”温度原始值转换后如果超过设定的上下限或者和上一次有效值相差超过一个阈值就丢弃这次数据用上一次的值顶上。阈值我会根据具体应用设定比如室内温度变化速率一般不超过每分钟 2 度管道温度变化可能更快一点这个参数要现场根据实际情况微调。6.5 传感器探头线束长度限制与对策PJ85718DM 走的是 I2CI2C 本身不适合长距离传输。如果你的远程节点和传感器之间隔着几十厘米以上建议把传感器放在节点板上通过总线与主控通信而不是把 I2C 拉长线。I2C 长线的电容会导致上升沿变缓通信速率不得不降下来。我在一个项目里把 I2C 线拉到 2 米多标准模式 100kbps 勉强能通但温度读数偶尔出错。后来改走传感器节点模式彻底解决。如果你确实要在节点板上外接探头线长控制在 20 厘米以内比较稳妥并且用双绞线传输 SCL 和 SDA。7. 从这套方案里沉淀下来的几点经验这套温度和通信方案我在几个不同项目里反复用过每次都会积累一些小经验最后再整理几条确实有参考价值的。第一尽量在原理图阶段就把测量点标清楚。这个测点是本地还是远程走 I2C 还是 CAN探头放在什么环境这三件事决定了后面所有设计和成本。等到 PCB 做出来才发现某个测点离主控太远再改就很被动了。第二通信协议的帧格式要留足扩展余地。温度数据帧里留几个保留字节以后故障标志、节点固件版本、在线状态这些信息都能往里面塞总线协议不用大改。第三在软件里把“温度采集”和“温度使用”解耦。采集任务只管把温度读到缓冲区控制逻辑只管从缓冲区取数。这样后续想换传感器、改采样频率都不需要动控制代码。第四调试时优先用逻辑分析仪抓 I2C 和 CAN 波形不要靠猜。很多所谓“灵异问题”按下脚一看波形就清清楚楚了。I2C 抓 ACK、CAN 抓帧格式这两样工具调试效率最高。这套方案的可扩展性不错。如果后续项目需要把远程温度数据接入以太网或者无线模块只需要在 PIC18F85J50 的 UART 口接一个网关模块把 CAN 数据解析后转成 JSON 格式上报即可。8 位机的性能和资源足够应付这类简单协议转换。我在实际操作中体会最深的一点是好用的方案不一定要最先进能把成熟可靠的芯片组合用好解决现场的温差测控问题就已经达成了项目目标。