企业官网建设流程全解析

简介：面向51单片机开发者的OLED屏幕与DS18B20温度显示实践资源，以51单片机为核心，通过I2C接口驱动OLED实时展示环境温度与时间信息，适合正在学习嵌入式基础、准备课程设计或毕业设计的读者。压缩包共31个文件，约107KB，内含main.c、iic.c、temp.c等源程序，配套uvproj工程文件可直接编译，hex烧录文件可下载运行，obj、lst等中间文件便于检查编译细节与代码生成情况。已有2343人学习。项目重点演示了DS18B20一线总线协议的读取时序与温度解析，以及OLED的初始化、坐标定位和字符/数字显示方法，同时包含STC15W.h等头文件，帮助理解寄存器配置与模块化程序结构。对想从简单闪灯迈向综合性传感显示的开发者来说，这套代码提供了清晰可仿照的框架，也能辅助排查时序异常、显示不刷新等实际问题。 先说我为什么会折腾这个。前阵子翻出一个吃灰的OLED屏幕和几个DS18B20温度探头，想着正好桌面缺一个既能看时间又能看室温的小东西，就顺手做了个基于单片机的温度时间显示器。做完之后发现，网上关于OLED和DS18B20的资料虽然一大堆，但大多只讲了“怎么点亮”和“怎么读温度”，等到你真正想把这两个东西放在同一个工程里、还要稳定跑起来的时候，各种坑就冒出来了：温度偶尔跳成85度、OLED字模取出来是反的、时间一刷新屏幕就闪得厉害。这篇博文就把我从选型、连线、驱动到整合的完整过程捋一遍，重点讲那些容易卡住人的细节和排查思路。

1. 这个项目到底在做什么：系统构成与能力边界

先说清楚这个项目不是啥高深的东西。硬件上就三大件：一块0.96寸I2C接口的OLED屏幕，一颗DS18B20数字温度传感器，再加一块主控芯片（我用了STM32F103，但同样的思路搬到ESP32、Arduino上完全成立）。软件上做的事也很直白：DS18B20负责测环境温度，OLED负责把温度和时间显示出来，时间来源我选了DS3231硬件RTC芯片，这样断电后时间也不会丢。

很多人第一次做这种项目会犯一个规划错误——上来就写代码，写完发现三个模块打架。比如DS18B20读取一次温度最长要750毫秒，如果每次刷新屏幕都同步去读一次温度，OLED就会明显卡顿；再比如I2C总线上同时挂了OLED和RTC两个设备，地址如果冲突，屏幕直接就白屏。所以动手之前，先把系统的能力边界和资源消耗盘清楚：

• 温度测量范围：DS18B20支持-55℃到+125℃，精度在-10℃到+85℃之间是±0.5℃，家用场景完全够；
• 刷新策略：时间每秒刷新一次，温度每2秒读一次，读温度放在后台非阻塞流程里，屏幕就不会闪；
• 显示布局：屏幕分成上下区域，上面显示温度，下面显示时间，中间用一行横线分隔；
• 掉电保持：时间由DS3231独立供电维持，主控重启后直接从RTC读回时间，不需要重新设置。

这个项目适合谁来参考？如果你是刚接触单片机通信协议、想搞懂单总线时序和I2C驱动的新手，这篇可以当一份完整的手把手教程；如果你已经能点灯了、但不知道多个传感器怎么优雅地共用一个工程，文中的架构拆分和防阻塞思路也值得一看。

一个常见的误区是：把OLED、DS18B20、RTC各自点亮之后，就以为“组合”只是一条主循环的事。实际上真正的难点在于资源的协调——时间、温度、显示刷新这三者节奏不同，硬塞在一个顺序流程里，要么读温度的时候屏幕没反应，要么刷屏的时候CPU被占死，外设中断全部丢失。后面我会一步步展开讲我最终采用的调度方案。

2. 硬件选型与连线：每一步都有它的道理

2.1 OLED选型：先分清楚I2C还是SPI、SSD1306还是SH1106

市面上的小尺寸OLED模块，绝大多数是SSD1306或SH1106驱动芯片，接口有I2C和SPI两种。这个项目我强烈建议选I2C版本，理由只有一个：省引脚。STM32F103用PB8做SCL、PB9做SDA，两根线就搞定了显示，剩下的引脚可以留给按键、RTC和后续扩展。SPI版虽然刷新速度更快，但至少要占用5个引脚，对这个应用场景来说没必要。

这里有个新手特别容易踩的坑：SSD1306和SH1106的驱动代码并不完全通用。0.96寸的OLED基本都是SSD1306，128x64分辨率；1.3寸的很多用的SH1106，也是128x64，但显存寻址方式有差异。你在淘宝买的模块，详情页如果不写芯片型号，直接问客服要资料包，确认是SSD1306还是SH1106，再决定用哪份驱动代码。我最初直接拿SSD1306的代码去驱动一块1.3寸的SH1106屏，结果画面错位加闪烁，排查了半小时才反应过来是驱动库不匹配。

另一个需要确认的参数是I2C地址。SSD1306的七位地址默认是0x3C，但有一部分模块把地址引脚拉高了，变成了0x3D。代码里如果写死了0x3C，屏幕就会一直不亮。我习惯在初始化里加一个地址探测函数，扫描I2C总线上的所有设备地址，这样OLED和RTC分别在哪一目了然，调试的时候能少走很多弯路。

2.2 DS18B20的接线与供电方式

DS18B20是单总线器件，数据引脚DQ需要接一个4.7kΩ的上拉电阻到VCC，这个电阻是必须的，不是可选项。单总线协议要求总线在空闲时是高电平，器件靠拉低总线来发起通信，没有上拉电阻，通信根本无法建立。

供电方式有两种，一种是外部供电给VDD引脚，另一种是寄生供电——VDD和GND接在一起，全靠数据线上的寄生电容供电。桌面温度计这种固定场景，我建议直接外部供电，稳定省心。寄生供电在长线传输和低温环境时容易出问题，读出来的数据经常会跳成-0.5或85，排查起来非常头疼。

连线方案如下：

从表格能看出来，I2C总线上挂了OLED和RTC两个设备，它们的地址一个是0x3C（或0x3D），一个是0x68，不冲突，可以安全共用。DS18B20单独占一个GPIO，用普通的推挽输出加开漏读入的模式来操作。

2.3 主控平台选择：STM32和ESP32该怎么选

如果只是做一个桌面温度计，STM32F103C8T6这种入门级MCU足够了，成本低、资料多，网上随便一搜就是HAL库的工程模板。但如果你是做带WiFi的桌面天气站，或者嫌设置RTC时间麻烦，想开机自动联网对时，那就直接上ESP32——它内部自带WiFi，用SNTP协议从网络获取时间，把DS3231都省了。

我最终选了STM32F103 + DS3231的组合，是因为我想做一个完全不依赖网络的离线设备，让它安安静静摆在桌面上，不掺和任何联网的事情。用ESP32也能做，但对我来说“能联网”反而成了一种干扰，而且ESP32的Deep Sleep低功耗玩法在这个项目里也用不上，得不偿失。

3. DS18B20驱动：单总线时序从底层到HAL库实现

3.1 为什么DS18B20的时序不能直接用HAL_Delay

DS18B20的单总线协议，本质上是用精确的延时来控制总线上的电平持续时间。初始化复位、写0、写1、读0、读1，每个操作都有严格的时间窗口。早期的51单片机教程喜欢用软件延时（就是空循环）来凑这些时间，移植到STM32的HAL库之后问题就来了——HAL_Delay的参数单位是毫秒，而DS18B20需要的是微秒级延时，15微秒、60微秒、480微秒，毫秒级别的延时根本没法用。

所以第一步要准备一个微秒级延时函数。最简单可靠的办法是用SysTick，把系统时钟配置成1微秒tick一次，在延时函数里循环查询计数寄存器。另一个方案是用TIM定时器做延时，原理类似，但多占一个外设。DWT（Data Watchpoint and Trace）也是个好工具，它有专门的CYCCNT寄存器记录CPU周期数，延时精度很高且不打断中断，适合对时序要求比较苛刻的场合。

我直接用SysTick的微妙延时，够用，代码也不复杂：

void delay_us(uint32_t us) { uint32_t start = DWT->CYCCNT; uint32_t ticks = us * (SystemCoreClock / 1000000); while ((DWT->CYCCNT - start) < ticks); }

注意DWT要手动使能：

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

这段配置放在主函数初始化里执行一次即可。有了可靠的微秒延时，后面跟DS18B20通信就顺手多了。

3.2 复位时序、ROM指令与温度读取的完整流程

单总线的通信流程分几步，顺序不能乱：

1. 主机拉低总线480微秒（典型值范围480-960），释放总线；
2. DS18B20检测到复位脉冲后，等待60-240微秒，然后拉低总线60-240微秒作为应答脉冲；
3. 主机检测到应答脉冲，说明器件在线，可以继续通信；
4. 主机发送ROM指令，这里只用到跳过ROM（0xCC），因为是单点测温，不需要寻址多个器件；
5. 主机发送功能指令，启动温度转换（0x44），然后等待转换完成；
6. 转换完成后，主机发送跳过ROM（0xCC）+ 读暂存器指令（0xBE），连续读9个字节；
7. 取第1、2字节拼成16位温度数据，根据分辨率移位得到实际温度值。

写时序和读时序的差异在于总线拉低的时间。写0：主机拉低总线60-120微秒；写1：主机先拉低1-15微秒，然后释放总线让上拉电阻把电平拉高，持续60-120微秒。读时序：主机拉低总线1微秒后释放，然后在15微秒内采样总线电平。采样太晚就会等到下一个读时隙，数据就错了。

一个很隐蔽的细节是：在两个读时隙之间，主机必须保证总线恢复高电平至少1微秒，否则DS18B20的输出驱动会和上拉电阻打架，读回来的数据全是0。

3.3 温度数据解析与85度“魔数”的处理

DS18B20返回的16位数据，高字节在高位，低位字节的低4位是小数部分，中12位是整数部分。我的设置是12位分辨率，所以温度值等于原始数据右移4位再乘以0.0625。

代码逻辑：

int16_t raw = (temp[1] << 8) | temp[0]; float temperature = raw * 0.0625f;

如果读到的温度一直是85度，基本可以断定是DS18B20没有完成初始化复位，或者器件根本没有应答。85这个值其实是DS18B20内部寄存器上电默认值，你读到的不是真实温度，而是器件还没开始转换时的原始寄存器状态。排查思路我放在最后一节专门讲。

4. OLED驱动：SSD1306的显存机制与汉字显示

4.1 先弄懂SSD1306内部是怎么“记”画面的

SSD1306内部有一块128x64的GRAM，本质上每个像素对应一个bit，1代表点亮，0代表熄灭。问题在于这个GRAM不是按“行-列”的常规思路排列的，而是把64行分成了8页（Page），每页对应8行像素，1列正好是1个字节。也就是说，第0页覆盖第0到7行，第1页覆盖第8到15行，以此类推。

向SSD1306写入数据时，先要通过命令设置目标页地址和列地址，然后连续发送字节，每个字节的8个bit会垂直排列到当前页的当前列上。这就引出了汉字取模的关键规则：一个字模的每一行数据，实际上代表的是8行像素中某一行的横向点阵，不是我们人眼从左往右读的“行”。

我用的取模方式是“列行式、阴码”。列行式即先从左到右取16列，每列取上下两个字节，正好覆盖16x16点阵；阴码是1表示点亮、0表示熄灭，我直接把取到的字节数组拷贝进显存即可，不用做任何反转。如果你用PCtoLCD2002取模，设置里选“阴码 + 列行式 + 前低位在前”，取出来的数组就能直接灌进SSD1306的GRAM。

4.2 I2C控制字节与数据写入流程

OLED在I2C总线上的写操作，每次通信的第一个字节是控制字节。控制字节为0x00表示后面跟的是命令，0x40表示后面跟的是数据。这个规则记住就行，驱动库内部会反复用到。

初始化SSD1306的序列比较固定，核心几行：

oled_write_cmd(0xAE); // 关闭显示 oled_write_cmd(0xD5); // 设置时钟分频因子 oled_write_cmd(0x80); oled_write_cmd(0x8D); // 开启电荷泵 oled_write_cmd(0x14); oled_write_cmd(0xAF); // 开启显示

注意有些模块带RES引脚，上电后需要拉低再拉高复拉一下；如果是不带RES的纯I2C四针模块，靠0xAE和0xAF控制开关。还有热词里有人问“OLED屏连上电源就亮吗”，答案是：如果不发送0xAE关闭显示命令，屏上电后驱动芯片默认就是开显示状态，显示内容是初始化前的随机噪声，这是正常现象，不是坏了。

4.3 中文字库与ASCII怎么共存

OLED要显示汉字，核心工作就两件：准备好点阵数据（字模），准备好字模的索引表。我建了一个结构体数组，每个元素包含汉字的内码（用两个字节表示GBK编码）和对应的字模指针：

typedef struct { uint16_t index; const uint8_t *font_data; } FontIndex;

ASCII字符我用了两种规格：8x16的用于显示时间数字，12x12或16x16的用于标题栏汉字。8x16字符在取模时是逐行取模，一行两个字节，正好横向8像素；汉字16x16则是上面说的列行式。显示函数内部先判断字符是ASCII还是汉字，根据编码范围走不同的取模读取逻辑，这样同一个显示接口就能统一处理英文、数字和中文。

这里有一个容易翻车的地方：字符串里同时出现中英文时，字符宽度不一致，逐字符刷新会让光标位置错乱。我的处理是先把整行要显示的内容用sprintf拼好，再逐字符判断宽度并推进光标，确保中英文混排不乱。

4.4 局部刷新和全屏刷新的取舍

SSD1306不读回显存，只支持写入。如果你有一块完整的显存缓冲（1KB的uint8_t数组），每次要刷新时把整块缓冲推送到屏上，就是“全屏刷新”。这种方式的优点是代码简单、不容易错位，缺点是1KB数据走I2C，在400kHz速率下也需要约20毫秒——如果每秒刷10次，屏幕就会肉眼可见地闪烁。

我的做法是缓冲+区域刷新结合：显存缓冲保留1KB全量数组，但每次只把变化的那一小块区域打包发送。比如时间每秒变化只需要刷新右下角的时间区域，温度每2秒变化只需要刷新左上角温度区域。这样既保证了画面稳定，又减轻了I2C总线压力，后续如果再挂别的I2C外设也不至于抢带宽。

5. 时间从哪来：RTC方案对比与校准经验

5.1 三选一：内部RTC、DS3231还是WiFi对时

做带时间的显示项目，时间来源通常有三种：

我最终选了DS3231，核心原因是省心。STM32内部RTC的32.768kHz晶振起振问题是个老大难，尤其是低成本无源晶振负载电容匹配不当的时候，LSE振荡器经常不工作或者工作时快时慢，排查起来特别折腾。DS3231内部集成了温补晶振和晶体，一上电就稳，完全不用管起振问题。

5.2 I2C挂两个设备：地址冲突和读写时序的仲裁

OLED和DS3231都挂在I2C1上，地址固定为0x68，OLED是0x3C或0x3D，没有冲突。但要注意的是，I2C总线上的设备地址是7位，读写时最低位表示方向，所以读DS3231时发送的从机地址是0xD1（0x68<<1 | 1），写是0xD0。初学者经常在这里晕。

DS3231的读写流程是先写入寄存器地址，再连续读写数据。时间寄存器从0x00开始，依次是秒、分、时、日、月、星期、年，全部是BCD码。把读出来的BCD转成十进制：

uint8_t bcd_to_dec(uint8_t bcd) { return (bcd >> 4) * 10 + (bcd & 0x0F); }

反过来写入也是先转成BCD。我封装了一个底层驱动，上层只跟“年”“月”“日”“时”“分”“秒”这些变量打交道，不用关心BCD还是I2C。

5.3 时间校准：小程序辅助还是手动按键

DS3231出厂时内部时钟就已经在跑，但默认时间和真实时间对不上，必须校准。我的做法是先用USB转TTL串口连到STM32，通过串口助手发送设定时间指令，比如发送字符串“2025-02-15 20:30:00”，MCU的串口中断解析后写入DS3231。这种方式的优点是校准过程可控，缺点是必须在开发状态下进行。

如果是成品设备，更合理的方案是在外壳上留两个按键：一个进入设置模式，一个调整数值。但我不想在桌面上放一台按钮很多的设备，所以只留了串口校准，平时也不动它。

6. 软件架构：把温度、时间、显示三个“节奏”揉进一个主循环

6.1 非阻塞主循环：设计一个简单的调度器

项目规模不大，用不上RTOS，但在主循环里裸奔容易出问题。我设计了一个非常轻量的时间片调度机制：

volatile uint32_t tick_ms; void SysTick_Handler(void) { tick_ms++; } uint32_t get_tick(void) { return tick_ms; } // 主循环 while (1) { if (get_tick() - last_temp_read >= 2000) { last_temp_read = get_tick(); request_temp_conversion(); // 启动转换，不等待结果 } if (get_tick() - last_temp_result >= 1000) { last_temp_result = get_tick(); temperature = read_temp_result(); // 读取上次转换的结果 } if (get_tick() - last_display >= 1000) { last_display = get_tick(); update_display(); // 刷新时间与温度显示区域 } }

这样设计的好处是：DS18B20的750毫秒转换时间完全被“吸收”了。每次我先发启动转换的命令，然后继续干别的事，等下一轮主循环再来的时候，转换大概率已经完成了，直接读结果即可。屏幕刷新也不会因为等待温度转换而被卡住。

6.2 显示缓冲与I2C传输的层次划分

我把代码分成了三层：

• 底层：I2C读写函数，直接操作HAL库的HAL_I2C_Mem_Write；
• 中间层：OLED的显存缓冲区操作，包括画点、画线、画字符、画汉字、清屏；
• 应用层：把温度、时间、状态栏组合成具体的界面布局。

应用层只关心“在哪里画什么”，完全不用管I2C协议。这样如果将来换SPI接口的OLED，只需要替换中间层的发送函数，界面逻辑一行都不用动。

6.3 内存开销与优化

STM32F103C8T6只有20KB RAM，SSD1306的1KB显存缓冲看着不多，但加上字模数组、串口缓冲、堆栈开销，还是得稍微规划一下。我的字模数组放在const区，直接进Flash，不占RAM；全局变量尽量少用，能局部就不全局；堆栈大小在启动文件里调到4KB，避免在深层函数调用时栈溢出。

实测下来，整个工程RAM占用大约8KB多一点，Flash占用30KB左右，对这块芯片来说非常宽裕。如果用的ESP32，那内存就更不是问题了。

7. 实测中的坑：症状、排查链路与最终结论

7.1 温度恒为85度：不是没焊好就是没复位成功

我在调试过程中至少遇到三次“温度直接读85度”的情况，每次原因都不同，整理成排查链路如下：

1. 先排除硬件连接：DS18B20的三个引脚有没有接反，VDD和GND千万不能反；DQ引脚的上拉电阻是不是4.7kΩ，如果用的10kΩ在某些环境也可能不稳定；
2. 用逻辑分析仪或示波器看复位时序：主机拉低480微秒后，总线上有没有出现DS18B20的应答低脉冲。如果没有应答，说明器件没在总线上响应——检查供电电压是否在3.0-5.5V之间，低于3.0V器件不工作；
3. 如果应答正常但读出来还是85，大概率是复位后的时序间隔有问题。DS18B20要求主机在复位后等待一段时间再发ROM命令，常规做法是复位后延时240微秒，确保器件从复位状态恢复过来；
4. 最后检查温度转换是否真的执行了。发出0x44之后，要等待转换完成，12位分辨率时最长750毫秒。如果主机在转换没完成时就去读暂存器，读到的还是上一次转换的旧值，而旧值如果恰好是上电默认的0x0550（即85.0度），看起来就像“永远卡在85度”。

7.2 OLED花屏、白屏、错位：大多是初始化和缓存的问题

花屏最常见的原因是I2C速率过高。STM32的I2C外设配置成400kHz标准快速模式，但如果OLED模块的走线较长、或者用了杜邦线连接，信号质量会变差，导致数据传输出错。把I2C速率降到100kHz，通常能解决一大半问题。

白屏，只亮不显示内容，优先怀疑显存初始化没成功。SSD1306上电后要完整执行一遍初始化序列，很多人漏掉了0x8D电荷泵命令，屏就是白的。还有一种情况是I2C地址错误，代码里写0x3C，实际模块是0x3D，数据根本没送到目标设备。用我前面说的I2C地址扫描函数，一秒钟就能定位。

错位、画面整体偏移，往往和页地址、列地址设置有关。SSD1306的列地址是7位（0-127），但设置列地址的命令要分两次：0x00-0x0F的低四位用0x00到0x0F直接发送，高三位用0x10到0x17发送。如果驱动库把这部分搞错，画面整体会往左或往右偏一段，且所有内容都是乱的。

7.3 汉字取模反了或者位置不对：分清楚“列行式”和“行列式”

汉字取模的坑太经典了。取模软件默认设置五花八门，有逐行式、逐列式、列行式、行列式，还有阴码阳码的区别。用错了一种，显示出来的汉字就是镜像的、旋转的，甚至完全看不清。

最稳妥的办法是固定一套自己熟悉的取模设置，写进项目注释里。我的固定配置是：

取模软件：PCtoLCD2002；点阵格式：阴码；取模走向：列行式；每行显示数：16；前导零：自动补齐；字节内：低位在前。

只要所有汉字和ASCII字符都按这套配置取模，显示函数里统一处理，基本不会出错。如果换了一台电脑、换了一个取模软件，先拿一个“中”字验证设置对不对，再批量取模。

7.4 I2C总线上RTC读写偶发失败：电气特性与通信错误处理

DS3231和OLED共用I2C总线，偶尔会出现读写超时或数据错误。一开始我以为是代码问题，后来查了下拉电阻，发现开发板上I2C已有上拉电阻，但OLED模块上可能还自带上拉，相当于两个上拉并联，总阻值变小。阻值太小会让总线拉高的驱动能力不足，导致信号上升沿变缓，高频通信下出错概率大增。

处理办法是：总线上所有设备模块如果有板上拉，就不要在MCU侧再重复外接上拉，或者统一算好并联后的等效阻值（一般在2.2kΩ到4.7kΩ之间都是可接受的）。另外，I2C通信代码里加一个简单的错误重试机制，读RTC超时后延时1毫秒重试一次，实际用下来很少重试成功，但多这层保险心里踏实。

8. 还能怎么玩：这个项目的扩展余地

硬件上原封不动，软件层面可以做不少有趣的事情。最简单的是把温度曲线记录下来：MCU内部Flash足够存几百组数据，每隔十分钟存一次温度和对应的时间戳，OLED上加一个简易波形页面，就能看最近几小时的温度变化趋势。

如果换ESP32做主控，显示内容可以瞬间丰富起来——从网上拉天气数据，同时显示室内温度和城市天气。DS3231都能省掉，改成SNTP对时，整机成本还会降一些。

再进一步，可以把DS18B20换成防水探头版本，放到冰箱、鱼缸、温室里做远程温度监控，OLED显示本机温度，另一个小无线模块把数据发到手机。这个项目的核心价值就在于：把单总线传感和I2C显示这两套最基础的通信路径吃透，后面无论接什么传感器、换什么屏，都只是换个驱动函数的事。

我做这个项目最大的体会是：不要一上来就想做“大而全”的系统，先让一个温度准确显示在屏幕上，再让时间稳定走动，然后再考虑怎么让它们互不干扰地共处。每一步都验证过了，后续的扩展就是搭积木了。

本文还有配套的精品资源，点击获取