STM32F407驱动DS18B20单总线温度传感器：时序与避坑指南

简介：一份基于STM32F407与DS18B20温度传感器的完整嵌入式实践工程，面向物联网、智能家居及温度监测场景的开发者，重点演示单总线通信协议、GPIO开漏模式配置以及TFT图形界面（GUI）显示温度数据。包内共248个文件，核心由55个h头文件、44个c源码文件、Keil工程配置（uvprojx/uvoptx）及编译输出（axf/map/lst等）构成，压缩包仅10.96MB，方便快速查看代码与固件结构。已有1006人学习使用。工程清晰划分Library、Project、User、Listing、Output目录，既包含标准外设库与DS18B20驱动，也包含ILI9341等TFT显示驱动，可直接在Keil中编译烧录。对想掌握单总线时序、外设驱动与GUI整合的初学者或中级开发者，这是一份结构完整、可运行可参考的实战样例。

1. 一个 168MHz 的 M4 与一根单总线：这个组合到底碰出了什么

STM32F407 + DS18B20 这个组合，第一眼看上去是性能过剩：168MHz 的 Cortex-M4 内核，去伺候一根用微秒级电平宽度传数据的单总线温度传感器。但实际工程里，这恰恰是低成本测温最可靠的搭配之一——一个 GPIO、两根线、几十行核心时序代码，就能把 -55℃ 到 +125℃ 的范围测到 ±0.5℃ 精度。标题里说的“碰出不一样的火花”，不是超频噱头，而是把 F407 的 DWT 周期计数器、开漏输出这些底层能力，和单总线协议按微秒级时序耦合，做出一套片片可复现的采集方案。这篇笔记只写能落地的部分：最小硬件怎么搭、时序怎么写、参数怎么设、坑在哪，新手照着走能出数，熟手可以直接抄边界参数。

2. 单总线协议与 DS18B20 内部机制：为什么 F407 是合适的搭档

2.1 从一根线看懂 DS18B20 的通信规则

DS18B20 用的是 1-Wire（单总线）协议，数据线 DQ 既要传命令又要传数据，总线上没有时钟线，所有时序全靠主机拉低电平的持续时间来表达。所以驱动 DS18B20 的本质，是精确控制 GPIO 的电平翻转时刻，而不是波特率、时钟极性这类常规通信参数。

器件内部的数据组织分两块：一块是 64 位 ROM，包含 8 位家族码 0x28、48 位序列号和 8 位 CRC，用来在总线上唯一标识每一只传感器；另一块是 9 字节暂存器，温度值存在第 0、1 字节（LSB 在前），第 2、3 字节是告警阈值 TH/TL，第 4 字节是配置寄存器，第 8 字节是 CRC。温度寄存器是 16 位带符号扩展的格式，12 位分辨率下每个 LSB 代表 0.0625℃，这个换算系数后面会用到。

主机常用指令只有几条：0x44 启动温度转换，0xBE 读取暂存器，0xCC 跳过 ROM 匹配（总线上只有一只传感器时用），0x55 匹配 ROM，0xF0 搜索 ROM。单设备场景下，一次完整采样流程是“复位—0xCC—0x44—等待转换完成—复位—0xCC—0xBE—读 9 字节—CRC 校验”，中间每一步的时序宽度都有硬性要求，我习惯把关键参数记成一张表：

这张表是调试时最重要的参照。大多数通信异常，最终都能归因到某一行的参数没落在容差里。后面第 4 章的代码，每一处延时都能对应回这张表的某个数，所以先记住一个结论：单总线的可靠性不取决于主频多高，而取决于每一个时隙的宽度是否稳定、是否落在器件规格书给的窗口内。

2.2 F407 驱动单总线的三个底层优势

为什么选 F407 而不是更低端的芯片？第一是 DWT 内核周期计数器。空循环延时和主频强绑定，开了编译优化后循环可能被优化掉，延时直接失真；而 F407 的 DWT->CYCCNT 是内核内的自由运行计数器，168MHz 下一个 tick 约 5.95ns，用它实现微秒级延时，不占定时器、不怕编译器优化，这是 M4 内核对比低端 M0/M3 最实用的时序优势。

第二是开漏输出模式。F407 的 GPIO 可以配置成开漏输出，写 1 时引脚呈高阻态，总线电平完全由外部上拉电阻决定；读引脚时直接读输入数据寄存器即可，不用在输入和输出模式之间来回切换。这比推挽输出 + 切换方向的做法少了两行代码，也从根本上避免了推挽输出和传感器开漏输出打架的问题。

第三是资源余量。一个 GPIO 就能挂一路 DS18B20，F407 引脚多，8 路温度采集可以直接用 8 个 GPIO，不需要做复杂的总线复用；如果后续要加 LCD、Wi-Fi 模块、SD 卡，主频和外设资源都还有富余。另外 DS18B20 供电范围 3.0–5.5V，F407 的 3.3V IO 电平可以直接驱动，逻辑电平兼容，不需要额外转换。

3. 硬件连接与工程初始化：把最小系统搭起来

拿到一个解压后是 HAL 库工程的压缩包，第一件事不是急着烧录，而是先核对两处：芯片型号是不是 F407、主频配的多少。主频错了，所有延时函数全部失效，这是这类工程最常见的“拿到手跑不通”的原因。硬件连接本身很简单，但有几处细节会在后面变成大坑。

3.1 最小电路：上拉电阻和供电方式怎么选

DS18B20 是三脚封装：VDD、GND、DQ。最省心的接法是外部供电，VDD 接 3.3V，GND 共地，DQ 接 F407 的一个 GPIO，同时在 DQ 上接一个上拉电阻到 3.3V。单总线空闲时需要高电平，传感器输出是开漏结构，只能拉低，不能主动拉高，所以上拉电阻是必须的，不是可选项。

上拉电阻的选型不用算得太复杂，我一般按线长和设备数来定：线短、单设备用 4.7k；线长、设备多或环境有干扰，换成 2.2k。F407 GPIO 内部有上拉，但阻值在 30–50kΩ 量级，对单总线来说太弱，只适合实验板上几厘米走线、且只有一只传感器的情况，不推荐依赖内部上拉。

供电方式上，外部供电优先级最高。寄生供电（VDD 接地，靠 DQ 供电）在 3.3V 系统里能用，但转换期间总线必须被强上拉，否则电压跌落会导致转换结果异常，一般需要 MOS 管切换强上拉，电路复杂度上去一截，收益不明显。另外注意：如果板子上有 5V 电源，想把 VDD 接 5V，DQ 的高电平也会是 5V，F407 的引脚不是 5V tolerant，会损伤引脚或导致误判，必须分压或统一降到 3.3V，最好的做法就是所有供电都用 3.3V。

3.2 GPIO 配置：开漏输出与读引脚的正确姿势

GPIO 配置用 HAL 库，核心是开漏输出、不启用内部上下拉、速度选 HIGH。引脚选择我习惯用 GPIOG 的第 11 脚这类空闲引脚，避开 JTAG、高速外设和晶振引脚，具体用哪个口，跟着压缩包里板级配置走就好。

#define DS18B20_PORT GPIOG #define DS18B20_PIN GPIO_PIN_11 #define DS18B20_LOW() HAL_GPIO_WritePin(DS18B20_PORT, DS18B20_PIN, GPIO_PIN_RESET) #define DS18B20_HIGH() HAL_GPIO_WritePin(DS18B20_PORT, DS18B20_PIN, GPIO_PIN_SET) #define DS18B20_READ() HAL_GPIO_ReadPin(DS18B20_PORT, DS18B20_PIN) void ds18b20_gpio_init(void) { __HAL_RCC_GPIOG_CLK_ENABLE(); // 使能 GPIOG 时钟 GPIO_InitTypeDef gpio = {0}; gpio.Pin = DS18B20_PIN; gpio.Mode = GPIO_MODE_OUTPUT_OD; // 开漏输出 gpio.Pull = GPIO_NOPULL; // 外部已有 4.7k 上拉 gpio.Speed = GPIO_SPEED_FREQ_HIGH; // HIGH 级别压摆率足够 HAL_GPIO_Init(DS18B20_PORT, &gpio); DS18B20_HIGH(); // 初始化为空闲高电平 }

这里有两个容易被误解的点。第一，开漏模式下读引脚不需要切换方向，因为写 1 时引脚是高阻，外部电平由传感器和上拉电阻决定，读输入数据寄存器拿到的是真实总线状态。第二，速度等级选 HIGH 而不是 VERY_HIGH，单总线频率很低，HIGH 的边沿足够陡，而且能减少一点 EMI；VERY_HIGH 在长线上反而可能加剧振铃。

4. 核心时序代码：复位、读写时隙与温度读取

时序代码是整个工程的核心，也最容易被“玄学”问题纠缠。用 F407 做 DS18B20 驱动，正确顺序是先把微秒延时做准，再写复位函数，最后写读写时序。我没有用 SysTick 来做延时，因为 SysTick 通常被操作系统或应用代码占用，而且它做微秒延时时需要频繁开关中断，成本高。DWT 是更干净的选择。

4.1 用 DWT 实现微秒级延时：F407 的时序基础

DWT 是内核调试组件里的一个周期计数器，使能后每个时钟周期加一。它的好处是纯硬件计数、不占定时器、不依赖中断，延时函数可以做成阻塞式但不会被编译器优化掉。

void dwt_delay_init(void) { CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; // 使能 DWT 访问 DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; // 启动周期计数 } void delay_us(uint32_t us) { uint32_t start = DWT->CYCCNT; uint32_t ticks = us * (SystemCoreClock / 1000000U); // 每微秒所需的周期数 while ((DWT->CYCCNT - start) < ticks); }

注意几个细节。SystemCoreClock 在 F407 正常配置下是 168000000，如果板子改了外部晶振或 PLL 分频，这个变量会自动更新，不需要手动改。DWT->CYCCNT 是 32 位递增计数器，会回绕，但用(DWT->CYCCNT - start)做无符号减法时，回绕不影响结果，这是这种写法能长期稳定工作的原因。这个延时函数的误差在纳秒级，远小于 DS18B20 时序窗口的微秒级容差。

4.2 复位与存在检测

复位是每一次通信的开始，作用是让总线上所有 DS18B20 知道主机要发起一次操作。复位完成后，传感器会拉低总线一段时间，作为“我在这里”的存在脉冲。

uint8_t ds18b20_reset(void) { uint8_t presence = 0; DS18B20_LOW(); delay_us(480); // 复位脉冲：拉低至少 480us DS18B20_HIGH(); // 释放总线 delay_us(70); // 等待 15-60us 后采样存在脉冲 presence = DS18B20_READ(); // 读到 0 表示有传感器拉低总线 delay_us(410); // 补齐整个复位时隙，约 960us return (presence == 0) ? 1 : 0; }

这里把采样点放在释放后的 70μs，而不是刚过 15μs 就采样。原因是存在脉冲会持续 60–240μs，采样点靠中间一点更稳定，不容易被边沿噪声误判。后面的 410μs 延时是让整个复位时隙走完，避免紧接着的写时序和复位时序重叠。返回 1 表示检测到设备，返回 0 表示总线上没有设备，这个逻辑我习惯在调用处判断。

4.3 写时序与读时序的代码细节

写一个 bit 的核心差异在于：写 0 是拉低整个时隙，写 1 是短暂拉低后释放。读一个 bit 则是主机拉低启动时隙，然后释放，在 15μs 窗口内采样传感器给出的电平。

void ds18b20_write_bit(uint8_t bit) { if (bit) { DS18B20_LOW(); delay_us(6); // 写 1：拉低 6us 后释放（1-15us 窗口内） DS18B20_HIGH(); delay_us(60); // 保证整个时隙 >= 60us } else { DS18B20_LOW(); delay_us(60); // 写 0：拉低整个时隙 DS18B20_HIGH(); delay_us(2); // 时隙结束后释放 } } uint8_t ds18b20_read_bit(void) { uint8_t val = 0; DS18B20_LOW(); delay_us(2); // 拉低至少 1us 启动时隙 DS18B20_HIGH(); // 释放总线 delay_us(5); // 采样点放在释放后约 5us val = DS18B20_READ(); delay_us(50); // 等待时隙走完 return val; }

写 1 的拉低时间我固定用 6μs，而不是极限的 15μs。原因是器件的采样窗口从时隙开始后 15μs 内有效，如果拉低到 15μs 才释放，器件采样时总线电平可能刚切换不久，上升沿还没稳定，误判概率增加。6μs 是实践里留足余量的做法。

读时序的采样点放在释放后 5μs，这个位置比很多人习惯的“时隙中点”要早。原因是总线上的分布电容和上拉电阻会拖慢上升沿，越早采样，读到的越是传感器真正驱动的电平；拖到 20μs 以后，读到的可能是电容充电波形，这就是温度偶尔跳变的常见来源。所有 bit 拼成 byte 的逻辑很简单：

void ds18b20_write_byte(uint8_t byte) { for (uint8_t i = 0; i < 8; i++) { ds18b20_write_bit(byte & 0x01); byte >>= 1; } } uint8_t ds18b20_read_byte(void) { uint8_t byte = 0; for (uint8_t i = 0; i < 8; i++) { byte >>= 1; if (ds18b20_read_bit()) byte |= 0x80; } return byte; }

4.4 启动转换与读取温度数据：完整的一次采样流程

有了上面的基础函数，读温度就是按协议组装指令。这里最关键的顺序是：第一次复位后发 0x44 启动转换，等待转换完成，第二次复位后发 0xBE 读暂存器，两次复位之间不能省略，因为转换和读取是两个独立的通信事务。

uint8_t ds18b20_read_temp(float *temp) { uint8_t buf[9]; if (!ds18b20_reset()) return 1; // 总线上没有设备 ds18b20_write_byte(0xCC); // 跳过 ROM 匹配（单设备） ds18b20_write_byte(0x44); // 启动温度转换 delay_ms(750); // 12 位分辨率需要约 750ms if (!ds18b20_reset()) return 1; ds18b20_write_byte(0xCC); ds18b20_write_byte(0xBE); // 读取暂存器 for (uint8_t i = 0; i < 9; i++) // 读出 9 字节 { buf[i] = ds18b20_read_byte(); } if (ds18b20_crc8(buf, 8) != buf[8]) // 前 8 字节做 CRC，第 9 字节是校验值 { return 2; // CRC 校验失败，数据不可信 } int16_t raw = (int16_t)((buf[1] << 8) | buf[0]); // 带符号扩展 *temp = raw * 0.0625f; // 12 位分辨率 LSB = 0.0625℃ return 0; }

CRC 校验函数用逐位计算即可，多项式是 0x8C，对应 DS18B20 规格书里的 CRC-8 多项式，和 Modbus 用的不是同一个，不要混用：

uint8_t ds18b20_crc8(const uint8_t *data, uint8_t len) { uint8_t crc = 0; for (uint8_t i = 0; i < len; i++) { crc ^= data[i]; for (uint8_t bit = 0; bit < 8; bit++) { if (crc & 0x01) crc = (crc >> 1) ^ 0x8C; else crc >>= 1; } } return crc; }

温度换算这一步有个容易被忽略的细节：buf[1] 是高字节，如果温度是负数，高字节的高位是符号扩展的 1，直接把两个字节拼成 int16_t 再乘系数，负温度就对了；如果声明成 uint16_t 再乘，负温度会变成很大的正数。delay_ms(750) 是按 12 位分辨率给的，如果配置寄存器改成了 9 位分辨率，转换时间只要 93.75ms，但实际工程为了精度，我固定用 12 位，延时给到 800ms 以上，不给器件卡边界的机会。

5. 避坑清单：DS18B20 调试中的 5 个经典翻车现场与排查手段

这一章写成一份排查手册，都是我实际调过或看别人调过的问题，每一条按“现象 → 原因 → 解决”的顺序写。遇到问题时，先对照现象找原因，再按解决步骤操作，比从头看代码有效率得多。

5.1 读到的第一帧温度永远是 85.0℃

现象：上电后程序运行，串口打印的第一个温度值固定是 85.0℃，之后恢复正常。

原因：DS18B20 上电复位后暂存器里的温度寄存器默认值是 0x0550，乘以 0.0625 正好是 85.0℃。如果主机发完 0x44 后没有等够转换时间就去读，或者 0x44 命令根本没被执行，读到的就是默认值。另一个常见情况是第二次复位遗漏了——很多人在写完 0xCC 和 0x44 后直接发 0xBE，中间没有复位，器件不会响应读取命令。

解决：严格按“复位 → 0xCC → 0x44 → 延时 750ms → 复位 → 0xCC → 0xBE → 读 9 字节”的顺序执行，任何一步都不能省。延时建议给 800ms，宁可慢一点，不赌器件转换刚好在边界完成。

5.2 读回来的数据全是 0xFF，偶尔冒出一个正常值

现象：串口打印的数据几乎全是 0xFF，解析出来的温度离谱，偶尔能跳出一个正常的温度值。

原因：总线根本没有被传感器拉低过，主机读到的全是上拉电阻拉高的高电平。最常见的原因是 GPIO 配成了推挽输出，读的时候没切换成输入模式，主机自己把总线保持在高电平；其次是上拉电阻阻值太大或虚焊，传感器拉低时电平压不下去。

解决：GPIO 改成开漏输出模式；上拉电阻换成一枚 4.7kΩ 的贴片电阻；用万用表量 DQ 静态电压，正常情况应该是 3.3V，执行复位时能看到电压被拉低到接近 0V。没有示波器时，这个电压变化是最直接的判断手段。

5.3 温度在真值附近跳动，一跳就是好几度

现象：温度数据大部分时间是准确的，但每隔几分钟会跳一次，幅度几度，随后恢复正常。

原因：读时序的采样点太靠后。总线走线长、分布电容大时，上升沿被电容拖慢，如果采样点放在时隙后半段，读到的可能不是传感器的驱动电平，而是电容充电过程中的中间电平，采到 0 还是 1 取决于采样瞬间的运气。

解决：把读采样点提前到释放后 4–6μs；线缆超过 50cm 时把上拉从 4.7k 换成 2.2k；读时序期间用临界区关中断保护，防止系统调度在这个 15μs 窗口里插入其他操作。关中断的时间很短，对系统实时性影响可以忽略。

5.4 用手碰一下 DQ 线，数据就跳成错误 CRC

现象：用手触摸 DQ 线或线缆挪动位置时，温度数据瞬间变成错误 CRC，要等下一次采样才恢复。

原因：人体和线缆引入的干扰让总线电平发生震荡，存在脉冲或读写时序被污染，器件进入未定义状态。单总线没有时钟线，抗干扰能力本来就弱，裸接的杜邦线就是一根天线。

解决：DQ 靠近 MCU 一侧串一个 100–220Ω 的电阻，限制干扰电流；线缆换成屏蔽线，屏蔽层单端接地；如果环境实在恶劣，DQ 对地并联一个不超过 100pF 的电容，再大的电容会把时序边沿磨平，得不偿失。软件上做一层保护：连续 3 次 CRC 错误就主动执行一次总线复位恢复，而不是卡死等下一次采样。

5.5 一根总线上挂多只传感器，读数互相串号

现象：总线上挂了 3 只 DS18B20，轮询读数时偶尔两只传感器的数据一样，有一只始终读不到。

原因：代码用的是单设备版本的 0xCC 跳过 ROM 指令，多只传感器同时响应，总线数据冲突，读回来的 64 位 ROM 和温度数据都是乱的。

解决：多设备场景必须用 0x55 匹配 ROM 指令，每次读取前先发目标传感器的 64 位 ROM，让它单独应答。ROM 列表在上电时通过 0xF0 搜索指令枚举出来，或者每只传感器单独上电时读一次 ROM 再保存。如果只想简单可靠，最省事的方案是每路一个 GPIO，物理隔离，软件零负担。

6. 进阶玩法：多路采集、软件滤波与低功耗验证

把单设备跑通之后，下一步通常是从“能读温度”走向“能上产品”。这里分享三个最常见的升级方向，每一个都不复杂，但都能显著提升方案的实用价值。

多路采集有三种拓扑可选。第一种是每路一个 GPIO，引脚多、互不干扰、代码最简单，适合 8 路以内的场景，F407 引脚富余，这也是我最常用的形式。第二种是单总线挂多只传感器，用 0xF0 搜索或上电逐个读 ROM，保存 64 位 ROM 列表，读取时用 0x55 匹配，省引脚但代码复杂度上一个台阶。第三种是硬件总线桥，通过 I2C 转 1-Wire 的桥接芯片扩展，适合对实时性要求不高的场景。我的习惯是：10 路以内直接多 GPIO，10 路以上才考虑单总线搜索。

软件滤波方面，DS18B20 的 12 位分辨率是 0.0625℃，但实际读数在最后一位上跳动是正常的。产品上我一般做 5 次滑动平均，采样间隔 1 秒，既能滤掉随机跳动，又不会让响应慢到不可用；如果现场有脉冲干扰，改成 3 次中值滤波更有效。滤波的代价是响应滞后，测温场景没人关心 1 秒内的变化，放心加。

低功耗方向上，DS18B20 本身在空闲时耗电极低，真正的功耗大头是 F407 和等待转换时的空转。常见做法是把采样周期拉长到 5–10 秒一次，每次先唤醒 MCU，启动转换后进入休眠，750ms 后用定时器唤醒再读结果。F407 的停止模式配合这个流程，整机平均功耗能降一个数量级。

验证方法不能省。0℃ 用冰水混合物，把传感器探头插进去，读数应该在 0.0℃ ±0.5℃ 以内；100℃ 用沸水，但海拔不同沸点有偏差，高海拔地区要用温度计修正；日常巡检用体温对比，稳定后读数应在 36–37℃ 区间。最后做 24 小时连续记录，观察有没有周期性跳变和漂移，这是判断时序余量是否充足最直接的办法。

我做第一版 DS18B20 工程时，被 85℃ 的问题困了两天，最后发现只是转换后的复位被某次代码改动误删了。从那以后，我把完整的调用顺序和延时参数写成了模板注释，每次移植新平台都先对照一遍，再没出过同类问题。这套方案是我在低成本测温里最常用的一套，希望对你有帮助。

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