企业官网建设流程全解析

做了多年温控类项目，从单片机点个灯到完整把一套嵌入式测温链路跑通，中间踩过的坑比写过的代码还多。这次整理的是一个典型的本地加远程双通道温度监测方案，核心器件是 PJ85718DM 这个带数码管显示的测温模块，搭配微芯 PIC18F67K40 作为主控，用在了嵌入式设备和一个小型 HVAC 风柜监控场景里。整个项目做下来最大的感受是：硬件选型不难，难的是把传感器数据、显示刷新、远程上报这三件事揉进一个 MCU 里还不打架。这篇博文就从需求拆解、硬件原理、通信协议、固件设计到调试实录，把这些内容完整过一遍，给正在做类似温度采集项目的朋友一个可参考的样本。

1. 项目拆解：PJ85718DM 与 PIC18F67K40 能做什么

1.1 标题背后的真实需求

先说清楚这个项目到底在解决什么问题。很多温度监测场景并不是“测一个点”那么简单，尤其是 HVAC 风柜、冷水机组、嵌入式的功率模块散热监测，这类场合往往同时存在两个维度的需求：设备本地的实时温度需要直观可见，运维人员的远程监控终端又需要定期拿到数据。传统做法是在设备面板装一个温控表头，再接一个 RS485 网关往上层转发，成本高、接线多，而且两套系统数据可能不一致，维护起来相当头疼。

这个项目想做的事，是用一块 PJ85718DM 模块完成本地温度采集与数码管显示，再用 PIC18F67K40 作为主控制器，把温度数据读取出来、做滤波处理、重新组帧，通过 UART 转发给远端的 HMI 或上位机。这样本地显示和远程上报共用同一个传感器源头，彻底避免了“本地一个值、远程一个值”的尴尬。

适合参考这套方案的人，我大致列三类：

• 做嵌入式设备散热监控，需要在本机面板上显示温度，同时预留数据上报接口的开发者；
• 做 HVAC 机组、风柜、恒温箱等设备控制，想用低成本方案替代专业温控表的工程师；
• 正在选型 PIC18F 系列，想了解它的外设配置和中断调度该怎么落地的学习者。

1.2 核心器件选型逻辑

PJ85718DM 这个模块，市面上常被称为数码管温度显示模块，它本身集成了测温传感器和四位 LED 数码管，上电就能独立工作显示当前温度。模块对外引出的引脚里，有一根单总线数据引脚，可以直接取出原始传感器数据，这意味着它不只是“能看”，还能被外部 MCU “读走”。这一条特性是这个项目选它的核心理由：模块既能独立完成本地显示，又愿意把数据权交出来。很多成品温控表不具备这个能力，数据封闭在表内，外部主控只能干瞪眼。

PIC18F67K40 这边，选择它主要看重三点：

• 8 位 MCU，成本低、货源稳定，在工业温控场景里生命周期长；
• 内置多路 UART 硬件模块，远程通信不需要软件模拟波特率，抗干扰能力强；
• 自带 16 位定时器、ADC、比较器等外设，后续从“只测温度”扩展成“温度加湿度加风扇转速监测”，资源也够用。

我之前用普通 51 系列跑过类似的显示与通信任务，本地显示刷新一频繁，UART 中断就丢数据，代码里大量关中断开中断，逻辑一片混乱。换到 PIC18F67K40 之后，硬件外设分担了大量实时性压力，代码复杂度下降非常多。这也是这篇博文标题把两个芯片放在一起的原因——模块负责“感知”，主控负责“调度”，各干各的，各司其职。

2. 硬件底层：PJ85718DM 模块与 PIC18F67K40 的配合方式

2.1 PJ85718DM 模块内部结构与引脚定义

PJ85718DM 模块从外观上看很简单：四位数码管、四个按键或者没有按键、一排排针。但拆开看构成就明白它为什么好用。模块内部有一片小 MCU 专门负责驱动数码管动态扫描，同时与一颗数字温度传感器通信。温度传感器输出的原始数据，被模块 MCU 解析成十进制温度值，转换成数码管的段码去点亮对应数字。

对外引脚上，比较关键的是两路信号：

• 单总线数据脚（DQ）： 直连模块内部的温度传感器数据线，外部 MCU 可以按单总线协议读取传感器的原始 12 位温度结果。注意，这路信号和模块内部 MCU 是并行的，两边同时访问传感器时会有总线冲突，实际操作中建议要么断开模块显示更新，要么控制读取频率，后面我会详细讲这个坑。
• 串口输出脚（TXD/RXD）： 部分版本 PJ85718DM 会直接输出一组串口报文，周期性发送温度值。这个功能对快速原型验证很有用，直接接 USB-TTL 就能在上位机看到温度流，但正式项目我基本不用它，而是用 DQ 读取原始数据，因为原始数据可以自己做滤波、校准和单位换算，链路更可控。

电源上模块支持 3.3V 和 5V 两种供电，但要注意数码管驱动电流较大，尽量由独立电源供电，不要从 MCU 的 LDO 上取电，否则温度显示一刷新，MCU 供电电压会被拉低，ADC 参考都会飘。

2.2 PIC18F67K40 的核心外设准备

PIC18F67K40 的引脚资源很充足，我这里只列出本项目的实际使用情况：

调试时我会把 UART1 接到 MAX485 芯片做 RS485 远程传输，UART2 留在板子上接蓝牙串口或者 USB-TTL，方便自己观察内部状态。

这里特别提醒一个硬件细节：单总线 GPIO 必须配置成开漏输出。DS18B20 这一类的单总线传感器是漏极开路结构，主机拉低总线时靠内部或外部上拉电阻恢复高电平。如果配成推挽输出，传感器拉低总线时，主机也在输出高电平，两个器件直接对抗，轻则读取错误，重则烧传感器。实测中最稳的做法：RD0 配置为数字输出开漏，同时使能内部弱上拉，外部再并一个 4.7kΩ 电阻到 VDD，双保险。

2.3 本地与远程的温度链路设计

整个系统链路可以从信号流的角度来看：

本地链路是指传感器数据进入模块 MCU 后直接驱动数码管显示。这一路不需要主控制器参与，PJ85718DM 上电自启动就能工作。好处是设备断电情况下，只要给模块单独供一组电，面板温度依然可读。很多设备运维人员有这种习惯，打开机柜第一眼看面板，而不是去翻上位机。

远程链路则是主控制器主动参与的路径：PIC18F67K40 通过 DQ 引脚重新读取传感器原始数据，在固件里完成 CRC 校验、格式转换、滤波后，打包成自定义协议帧，通过 UART1 发送到 RS485 总线。链路结构如下：

模块本地显示：传感器 -> 模块MCU -> 数码管 远程数据上报：传感器 -> PIC18F67K40(DQ读取) -> 数据处理 -> UART1 -> RS485 -> HMI/上位机

两条链路共用一个传感器物理采样点，不存在“两个传感器两个温度值”的偏差问题。我这个项目在风柜出风口实测，本地数码管显示 24.8℃ 时，远程上位机收到的 24.8℃ 或 24.9℃，差异只是因为两者的读取时间点不同，数据源头完全一致。这种一致性，在工程验收时非常重要。

3. 通信协议与数据解析的技术细节

3.1 单总线协议下的温度读取流程

单总线（1-Wire）协议是 DS18B20 系列传感器最常见的数据接口，它只有一根数据线，所有通信都由主机发起时序。读一次完整温度，标准流程分四步：

1. 总线复位：主机拉低总线 480μs 以上，然后释放，传感器会回复一个存在脉冲；
2. 跳过 ROM（0xCC）：系统里只挂了一颗传感器，用跳过指令省去寻址过程；
3. 启动温度转换（0x44）：传感器开始内部 ADC 转换，默认 12 位分辨率下需要 750ms；
4. 读取暂存器（0xBE）：连续读出 9 个字节，其中前两个字节就是温度值。

PIC18F67K40 的主频我配置为 64MHz，内部指令周期 62.5ns，单总线要求 1μs 级精度的时序延时。写代码时我用了一个专门的延时函数，实测校准后用示波器看波形，时序是稳定的。下面这段是核心读取函数的骨架：

float read_temperature() { uint8_t data[9] = {0}; float temp = 0.0f; if (!ow_reset()) { return -999.0; } // 复位并检测存在脉冲 ow_write_byte(0xCC); // 跳过ROM ow_write_byte(0x44); // 启动转换 delay_ms(750); // 等待12位转换完成 if (!ow_reset()) { return -999.0; } ow_write_byte(0xCC); ow_write_byte(0xBE); // 读取暂存器 for (int i = 0; i < 9; i++) { data[i] = ow_read_byte(); } if (crc8_check(data, 8, data[8]) == 0) { // CRC校验 int16_t raw = (data[1] << 8) | data[0]; temp = raw * 0.0625f; // 12位分辨率为0.0625℃/LSB } return temp; }

这段代码在循环中跑，每次读取耗时约 1 秒左右。实际项目里我通常不会每个循环都等待 750ms，而是把“启动转换”和“读取结果”拆成两个时间片，中间去干别的事，比如刷新数码管状态或者处理远程命令。这个调度思路后面会展开。

3.2 CRC 校验是怎么保护温度数据的

工业现场的强电环境里，数字信号也免不了受干扰。DS18B20 的暂存器读取自带 8 位 CRC 校验，这正是它比模拟温度传感器可靠的原因之一。CRC 的计算方式是多项式 X^8 + X^5 + X^4 + 1，也就是 0x31。我代码里用的是查表法，表生成一次后固化在 Flash 里。校验逻辑很简单：对前面 8 个数据字节重新计算 CRC，和读到的第 9 个字节对比，一致才认为数据有效。

刚开始做这个项目时我偷懒没做 CRC 校验，结果在风柜启停瞬间偶尔会读到跳变的温度值，比如从 24℃ 直接跳到 -55℃。排查了很久，最后锁定是数据线上的毛刺干扰导致读取字节错误。加上 CRC 校验值之后，错误的帧直接丢弃，温度为保持上一次的有效值，系统稳定性大幅提升。这一点我建议每个做传感器读取的人都别省。

3.3 远程帧格式设计：稳定比花哨重要

远程上报我用的是自定义协议，结构简单，便于在 HMI 上解析和后续扩展：

帧头(2字节) 地址(1字节) 命令(1字节) 长度(1字节) 数据区(N字节) 校验(1字节) 0xAA 0x55 0x01 0x01 0x02 温度高字节+低字节 异或校验

帧头固定为 0xAA 0x55，识别到完整帧头后才开始按协议解析。地址字段用于区分不同设备，我这个项目只接了一个从站，所以固定 0x01。命令 0x01 表示温度上报。长度字段表示数据区字节数。校验用的是单字节异或，覆盖地址到数据区末尾的所有字节功。虽然异或校验强度不如 CRC16，但作为状态监测上报已经足够，而且计算开销小。如果数据要用于控制闭环而不仅仅是监测，建议换成 CRC16-MODBUS。

串口波特率我设成了 9600，8 位数据、无校验、1 位停止位。9600 比特率在 RS485 的 1000 米传输距离要求下比较稳妥，同时数据量也完全够用。每 10 秒主动上报一次温度帧。除了周期上报，系统还响应上位机的查询命令，实现按需读取，方便现场调试人员一按键就拿到当前值。

4. 固件设计与实操要点

4.1 系统时钟与定时任务调度

PIC18F67K40 内部振荡器经过 PLL 倍频到 64MHz，作为 CPU 和大多数外设时钟。这个配置的好处是整个指令周期足够快，单总线读写延时可精确控制。定时器调度我采用了一个固定 1ms 的时基中断：

volatile uint8_t tick_1ms; volatile uint8_t flag_display_update; volatile uint16_t counter_remote_report; volatile uint16_t counter_sensor_convert; void __interrupt() global_ISR(void) { if (PIR0bits.TMR0IF) { PIR0bits.TMR0IF = 0; tick_1ms++; if (++counter_sensor_convert >= 750) { flag_sensor_convert_done = 1; counter_sensor_convert = 0; } if (++counter_remote_report >= 10000) { flag_remote_report = 1; counter_remote_report = 0; } } }

主循环就是一个大状态机：没有任务时进入睡眠或者空转，有任务标志就处理对应事务。这种设计的好处是各个功能模块互不阻塞，单总线等待转换的 750ms 时间里，远程帧照样发、按键照样扫。

需要注意的是：中断服务函数里别做耗时操作。我的中断里只置标志位，具体的组帧、CRC 计算、读传感器全部放主循环处理。如果中断里直接挤入几十上百微秒的延时，整个系统的实时性都会受影响，UART 接收很容易错位。

4.2 温度采集与滤波

传感器读回来的温度值，我做了三重处理：

第一重是 CRC 校验，这层过滤确保每个进入系统的数据都是合法的单总线数据。但凡校验失败，直接丢弃。

第二重是范围合理性判断：如果读取到的温度超出 -20℃ 到 120℃ 这个物理范围，视为异常数据丢弃。这个范围要根据项目实际工况设定，风柜进出风口的正常温度区间就是 5℃ 到 40℃，所以也可以把判断范围进一步收紧。

第三重是一阶滞后滤波，算法非常简单但效果很好：

filtered_temp = filtered_temp + alpha * (new_temp - filtered_temp);

alpha 取 0.2 到 0.3 之间。alpha 越大，响应越快，但噪声抑制能力弱；alpha 越小，曲线越平滑，但对真实变化的响应变慢。HVAC 场景下温度变化率本来就慢，我取了 0.2，大概 5 次循环才能跟上真实值，换来的是远程曲线上看不到毛刺。

用这个滤波方法，当传感器从 25℃ 环境突然被放到 40℃ 的水中时，显示值大概需要 5 到 8 秒才能稳定到 39℃ 左右。如果是风机盘管的出风口温度监测，这种滞后完全可接受，曲线看着舒服也不会产生误报警。

4.3 数码管本地显示策略

PJ85718DM 模块的数码管在上电后默认显示温度，模块板载的小 MCU 会自动循环扫描刷新，正常情况下几乎看不到闪烁。但当外部 MCU 读取总线的频率比较高时，模块自身的读取时序会被干扰，典型表现是数码管出现缺笔画或者数值停顿。

我实测了两个方案的差异：

方案一：外部 MCU 每隔 750ms 读一次温度，模块本地显示严重异常，偶尔还会花屏； 方案二：外部 MCU 每 10 秒才读一次温度，在读取瞬间模块显示也会轻微闪烁，但整体可用。

最终项目采用让我比较满意的方案三：外部 MCU 通过模块的串口接口获取温度转存值，不直接触碰单总线。模块通过其内部解析后，既驱动数码管显示，又把同一份数据转存到外部接口寄存器中。PIC18 通过 UART 读取这份转存值，完全不影响本地显示。这个方案在项目实际运行中表现稳定，数码管显示一直正常。当然如果你的模块版本没有串口透传接口，只能用 DQ 读原始数据，那就建议控制读取频率，并且避开模块自身刷新周期。

4.4 遥感命令与数据上报实现

远程命令规律并不复杂，PIC18 侧收到上位机查询帧后，需要及时回复。串口接收我用环形队列缓存，中断服务函数只负责把字节放入队列，主循环从队列取出进行帧解析。这样即使上位机连发 10 帧查询指令，MCU 也不会漏。

上报温度帧的组帧代码：

void build_report_frame(uint16_t temp_raw, uint8_t addr) { uint8_t frame[8]; frame[0] = 0xAA; frame[1] = 0x55; frame[2] = addr; frame[3] = 0x01; // 命令：温度上报 frame[4] = 0x02; // 数据长度 frame[5] = temp_raw >> 8; // 温度高字节 frame[6] = temp_raw & 0xFF; // 温度低字节 frame[7] = frame[2] ^ frame[3] ^ frame[4] ^ frame[5] ^ frame[6]; uart1_send_buffer(frame, 8); }

这里温度值我用的是扩大 10 倍后的整数，比如 24.8℃ 存储为 248（0x00F8）。上位机拿到后自己除以 10，既保留一位小数精度，又避免了浮点数在串口传输和不同上位机语言之间的格式不一致问题。这个细节在 C/S 两端联调时能省很多事。

4.5 掉电保存、标志位与异常处理

我的系统还做了一项增强功能：周期上报时长和传感器地址这两项配置，写好放进 Flash 数据区。设备重新上电后，MCU 先读取配置，再决定上报周期，不用每次重新编译固件。PIC18F67K40 的 Flash 数据区支持字节写入，但我建议不要频繁写，只在配置有变化时才擦写。这类似于 HVAC 现场如果换了一台风柜，调试人员可以通过上位机下发变更地址，设备自己记住新地址并重新上电生效，不用打开机箱改跳线。

异常处理方面，我做了传感器离线检测。代码里连续三次总线复位检测不到存在脉冲，就判定传感器掉线。此时数码管由模块自己显示仍能正常工作，但远程上报帧把温度数据区打成一个特定特殊值 0x7FFF，上位机识别到这个值后显示“传感器错误”，而不会显示一个看起来像正常但其实是随机错误的温度。这个 0x7FFF 约定在需求文档里写清楚，联调时两家不至于为错误值争论半天。

5. 常见问题与调参经验实录

5.1 数码管花屏和显示错位

新板子第一次上电时出现数码管乱码，很常见。原因我不是说 MCU 程序有问题，而是 PJ85718DM 模块初次上电自检时对供电电流要求比较高。如果你用同一个稳压器同时给模块和 PIC18F67K40 供电，模块点亮的瞬间大电流把电压拉低，MCU 可能复位，数码管显示就会错乱。

解决思路分两步：

• 模块的电源单独从主电源大电解电容后引一路，不要和 MCU 的数字电源串在一起。PCB 上最好做一个星型接地，避免大小电流混杂环路。
• 如果板上空间有限只能共用电源，则在模块供电脚加一颗 220μF 的电解电容就近布局，并保证电源走线宽度不小于 1mm。

这个故障发生率很高，尤其是初次打样时，排查优先级可以排在所有通信问题之前。

5.2 单总线读取 CRC 频繁失败

CRC 失败通常是时序问题，而不是数据线问题。如果你在代码里看到读取结果时好时坏，先检查几个位置：

• 硬件 GPIO 是否配置为开漏输出。用推挽输出时，总线被拉低后恢复时间不受外部上拉控制，波形上升沿过缓，传感器发送的位流会被误判；
• 延时函数是否被优化影响。比如编译器开高优化等级，循环延时被改变长度，导致读时序的采样点落在错误的时隙。我在高优化等级下做了一次全时序示波器比对，把整个读写时序和预想的规格做了一一对应后才放心定稿；
• 是否满足总线速度要求。传感器工作时对时序窗口的要求比较严格，建议延时函数用 volatile 变量控制循环，保证每个微周期固定。

排查单总线问题时，最好先把自己代码里的时序逻辑整个过一遍，再去怀疑外接线路。我遇到过最诡异的情况是，用调试器单步执行时 CRC 从不失败，全速运行时失败率超过 50%，最终定位到中断服务函数里有一个 50ms 的消抖延时，它在主线读取数据的过程中抢占了 CPU，导致位时序被拉长。去掉这个中断耗时代码后，问题立即消失。

5.3 远程 RS485 通信偶发丢帧

远程通信用的 RS485，需要在 A/B 差分线两端各接一个 120Ω 终端电阻，这个电阻的目的是匹配传输线阻抗，减少信号反射。如果只有单端接或者不接，总线末端会产生振铃信号，在长线传输时导致 UART 采样错误。

丢帧还有一个常被忽略的瓶颈：485 芯片的收发切换时间。使用 MAX485 这类半双工芯片时，从发送模式切换到接收模式需要至少几十微秒的转换时间。如果你的代码刚发完数据立刻切回接收并等待回应，对方可能还在发数据，你的芯片却已经处于接收状态，但其实总线还在被对方驱动。稳妥的做法是在切换模式后延时 1 到 2 个字节时间，然后再发下一个动作。9600 波特率下，1 字节约 1.04ms，所以切换延时我留了 5ms，实测系统稳定无冲突。

5.4 温度值跳变和滤波参数取舍

如果不加滤波，原始温度值在上位机上画出来的曲线会有很多锯齿。特别是强电设备启动时，电流冲击造成的电磁干扰会通过电源线耦合到传感器数据线上，读数瞬间跳变十几度也是可能的。我最终确认过滤波参数 alpha=0.2 合适后，还把连续 5 次过滤后的平均温度作为上报值。这样做远程曲线的平滑度很好，但代价是温度出现真实突变时，报警响应会慢几秒。如果你需要较快的报警响应，可以设计两套滤波参数：平时用强滤波，检测到温差超过 3℃/秒时，临时切换成 alpha=0.8 的快速跟随模式，既保证稳定性又兼顾实时性。

6. 现场调试过程拾遗

6.1 本地测温能力验证

在实验室阶段，我先将自己手上的一只 PJ85718DM 模块通电预热 10 分钟，然后与水银温度计同步测量同一块恒温铝块表面温度。模块数码管显示值与水银温度计误差在 ±0.3℃ 以内，这个精度在 HVAC 场景已经够用。接下来把模块放到 45℃ 恒温干燥箱里，持续工作 8 小时，数码管亮度没有明显衰减，读数稳定在 45.0℃ 附近，传感器和模块长期工作的可靠性验证通过。

这个验证过程看似简单，但建议所有项目都做一遍，否则你排查问题时永远不知道是算法问题还是传感器自身漂移。

6.2 远程传输距离与误码率测试

用 100 米长的屏蔽双绞线模拟 RS485 线路，系统持续进行远程上报，运行 3 小时无一次丢帧。之后把波特率提高到 38400，100 米下误包率约 0.1%，说明 9600 波特率在长距离传输下完全可靠。

现场实测时，设备离上位机大约 50 米，中间经过两个接线端子排，接地电位存在轻微差异，但 485 差分信号完全免疫这种共模干扰。PIC18F67K40 的 UART1 加了 TVS 管和共模电感，进一步提升了浪涌防护能力。如果项目现场是变频器较多的工况，TVS 管和共模电感不能省，否则雷击或变频器干扰有可能打坏 485 芯片。

6.3 上位机展示与联动验证

远程数据到达上位机后，我用一个简易的工控组态软件做了块界面：实时温度曲线、历史数据表格、超温报警灯。阈值设定为 40℃，当风柜出风口实际温度升高时，数码管和上位机几乎同时刷新数值，上位机弹出报警提醒。验证了整套链路从硬件到软件端的完整闭环。

如果想在 PC 端快速验证数据帧结构，可以直接用串口助手发送查询指令，观察 MCU 回复的字节流。这个阶段不需要写任何上位机代码，能最快确认通信链路和协议帧是否正常。我习惯在代码里加一个出厂测试模式，上电时如果检测到特定调试引脚被拉低，就进入固定发送测试帧的循环，配合串口助手做联调非常方便。

7. 实用建议与后续扩展方向

最后聊几个我认为对实际项目有价值的小经验。

线材选择上，DS18B20 这类传感器配普通双绞线即可，但要留意传输距离。如果延长线超过 10 米，建议使用屏蔽双绞线并将屏蔽层单端接地，否则干扰会直接叠加在数据信号上。我在一个项目中用 30 米普通跳线连接传感器，读取异常频繁，换成屏蔽线故障立刻消失。

抗干扰布局上，数码管模块尽量远离供电模块的开关变压器。之前遇到一例数码管显示抖动，开始怀疑芯片问题，最终发现是板载 24V 转 5V 的 DC-DC 模块磁场干扰了数码管驱动芯片的振荡电路，重新调整了布局方向后复位。

扩展方向上，PIC18F67K40 的 ADC 通道目前还有空闲，可以扩展采集风柜回风湿度传感器，把温湿度同时上报。硬件定时器也可以加 PWM 输出，实现温度控制逻辑而不只是监测——温度过高时直接调节风机转速。这些扩展都不需要大改硬件，把代码的模块化接口留好就能实现。

如果想把远程上报改为无线方式，把这套帧格式通过 LoRa 或 4G DTU 透传即可，帧结构本身不需要改动。我有一次接过物联网模块，就是把 UART1 的输出既连接到 485 芯片，又通过一个跳线帽连接到 LoRa 模块的串口，在示波器上一眼看出去两边的数据完全一致，省了不少调试时间。

这套项目里最值得反复体会的，其实是“数据流”的设计思维。从传感器到数码管、从数码管到 MCU、再从 MCU 到上位机，每一层都有明确的数据格式和权限边界，各层之间既有独立性又能互相补充。PJ85718DM 和 PIC18F67K40 的搭配并不算稀罕，但把读取、校验、滤波、显示、组帧、上报这些环节一个个调顺，整个系统就会非常踏实。我在现场盯着数码管跳动的数字和上位机曲线重合的那一刻，觉得之前那些加 CRC 校验、挡中断干扰、调滤波系数的琐碎功夫全都值了。