企业官网建设流程全解析

这两年做嵌入式项目，经常被“线太多”折腾得头疼。传感器要供电、要地、要信号，三根线起步，多点采集时线束更是绕成蜘蛛网。后来在冷链温湿度记录仪的项目里改用1-Wire协议，一条总线挂十几个DS18B20温度探头，只拉一对双绞线就全解决了。这个协议在工业现场、智能家居、农业大棚里出现频率非常高，尤其适合“传感器分散、距离几十米、不想布线太复杂”的场景。这篇就围绕“Putting 1-Wire Protocol into Action”展开，从原理到底层时序，再到STM32上的完整驱动和排坑经验，一次讲透。

1-Wire协议由Dallas Semiconductor（现为Maxim Integrated）推出，单根数据线既传数据又能给从机供电，通信距离在标准模式下可达几十上百米，主机只需要一个GPIO口就能挂接大量从机。对刚接触的人来说，最陌生的是它的“严格时序”：读写每一位都要精确控制延时，和I2C、SPI那种靠时钟线同步的思路完全不同。这篇内容适合正在做单片机采集、温度监控、设备识别或传感器网络的朋友，尤其是想啃底层协议、不满足于直接抄库函数的开发者。

1. 认识1-Wire：一根线怎么既传数据又供电

1.1 单总线的通信模型

1-Wire总线本质上是一个主从式半双工通信系统，所有从机挂在同一条数据线上，主机（MCU的某个GPIO）发起所有通信。总线上没有独立的时钟线，从机靠主机发出的时序边沿来同步节奏；没有独立的电源线，部分器件能从数据线上“偷电”工作，这就是它最特殊的点——寄生供电。

整个网络的硬件结构非常简单：主机GPIO接一只上拉电阻到VCC（通常3.3V或5V），然后数据线延伸到各个从机的DQ引脚，每个从机再有一条独立的GND回路。通信过程由主机控制，从机永远不会主动说话，主机问一句、从机答一句。因为从机只能通过“拉低总线”来表达自己的状态，所以总线必须依赖上拉电阻保证空闲时有确定的高电平。

1.2 为什么某些场景非它不可

做技术选型时，很多人问我：有I2C、SPI、UART，为什么还要用1-Wire？我的回答是：它牺牲速度，换来了极端的接口简化。

I2C虽然也是两根线，但地址只有7位，一条总线上同类传感器地址相同就容易冲突；SPI速度虽快，可每加一个从机就要多一根片选线；RS485距离远，但需要收发器和双线差分。1-Wire最吸引人的地方是每个器件出厂时烧录了唯一的64位ROM序列号，一条总线上可以挂几十个同型号芯片，不需要额外地址引脚，也不存在地址撞车问题。再加上单线供电，成本非常低，特别适合温度采集这种低速、多点、远距离的场景。

1.3 典型器件和应用场景

说到1-Wire器件，必须提DS18B20，几乎成了这个协议的代名词。这颗数字温度传感器精度在-10°C到+85°C范围内可以做到±0.5°C，分辨率可配置成9到12位，直出数字结果，不需要校准。除了测温，常用的1-Wire器件还有：

• DS2431：1Kb EEPROM，常用于设备身份识别、校准参数存储。
• DS2405：单路可寻址开关，做远端IO控制很实用。
• DS28E05：廉价安全认证芯片，用于防伪。
• DS2408：8通道IO扩展器，一条总线扩展出多个IO。

应用场景上，最典型的是多测点温度监控，比如养殖大棚、冷库、数据中心机柜，一条两芯线串起几十个探头；其次是设备身份管理，在电池包、传感器模块里放一个DS2431，插上主机就能读出厂序列号和生产日期；还有一些老式智能电表、门禁读卡器内部也在用1-Wire做通信。

2. 硬件电路设计：上拉电阻、寄生供电与布线细节

2.1 上拉电阻的取值，不是随便放一个就行

我在开发板上看不少参考设计直接放一个4.7kΩ电阻了事，短距离确实能用，但距离一长或设备一多就出各种怪问题。1-Wire的上拉电阻值直接影响总线上升沿时间和驱动能力，需要根据线缆电容、从机数量和供电电压综合估算。

基本公式是上升沿时间约等于RC常数，R是上拉电阻，C是总线电容。总线电容由线缆分布电容和每个从机输入电容组成，常见双绞线分布电容约50pF/m，DS18B20输入电容约25pF。如果要求上升沿不超过1μs，用100m线缆挂10个传感器，C大概等于10050 + 1025 = 5250pF，那么R应不高于1μs / 5250pF ≈ 190Ω。

但电阻也不是越小越好。1-Wire从机靠“把总线拉低”来写0，芯片内部的下拉MOS管有电流限制，上拉太强会把总线电压抬得过高，导致从机拉不动；同时强上拉也会加大功耗。实践中，3.3V系统短距离（<5m）用4.7kΩ没问题，10m以上建议1kΩ到2.2kΩ，5V系统可以适当增大到2.2kΩ到4.7kΩ。我还见过一个技巧：通信前主机强上拉一下总线，帮助总线电容快速充电，这个后面讲时序时会再提到。

2.2 寄生供电模式详解

1-Wire的寄生供电是它区别于所有常规总线的地方。DS18B20只有3个引脚：GND、DQ、VDD。正常接法下，VDD接3V到5.5V，DQ接数据线；寄生供电模式下，VDD引脚直接接地，芯片完全通过DQ引脚在总线空闲高电平时给内部电容充电，在低电平期间依赖电容存电运行。

寄生供电的优点是省掉一路电源线，两线制即可远端测温。但代价是芯片能获取的能量有限，尤其是在做温度转换时（转换电流约1mA，持续几百毫秒），如果总线充电时间不足，转换可能失败。DS18B20数据手册里明确写了，使用寄生供电时，温度转换命令发出后主机必须主动把总线拉高，并提供强上拉，否则转换结果可能不对或者干脆不转换。具体做法是把GPIO切换成开漏输出且外部上拉到5V，或者用PMOS管做可控强上拉，转换期间拉高约750ms。

2.3 线缆、接插件与防护

1-Wire在低速下看似好说话，实际上对长线传输很敏感。最大的敌人是线缆电容和反射。距离超过20m时，建议用屏蔽双绞线，屏蔽层单端接地。同时要注意，数据线和电源线（如果外部供电）最好不要缠在一起，容易形成串扰。

另外，户外或工业场景一定要加保护。总线接口建议串一个100Ω到220Ω的电阻，防止ESD和浪涌冲击；再加上TVS管（比如SMBJ3.3）和一个小电容到地，能有效减缓静电和雷击感应电压。插拔连接器用RJ11/RJ12或者防水航空插头都可以，关键是保证接触可靠，接触不良引起的抖动会让时序彻底乱掉。

3. 软件核心：时序、ROM搜索和CRC校验

硬件只是舞台，1-Wire的表演全在时序上。这一部分我把最底层的位时序逐条讲清楚，再给出一个可以直接移植的C语言驱动框架。

3.1 复位脉冲与存在应答

1-Wire通信的每一次事务（transaction）都从复位开始。主机先把总线拉低至少480μs，然后释放总线，上拉电阻把总线拉高。15μs到60μs之后，总线上所有从机会同时把总线拉低60μs到240μs，表示“我存在”。主机在这个窗口内读取总线状态，读到低电平说明总线上有设备。

这个时序非常关键，因为主机是靠“检测总线被拉低”来判断从机存在的，而每个从机是开漏输出，所以多个从机同时拉低也不会冲突。复位脉冲的宽度不能太短，太短从机来不及响应；也不能过长（超过960μs），否则会触发从机的复位。

下面是一段STM32 HAL库下的复位函数：

#define ONE_WIRE_GPIO_PORT GPIOB #define ONE_WIRE_PIN GPIO_PIN_0 // 宏：拉低和释放总线 #define OW_LOW() HAL_GPIO_WritePin(ONE_WIRE_GPIO_PORT, ONE_WIRE_PIN, GPIO_PIN_RESET) #define OW_HIGH() HAL_GPIO_WritePin(ONE_WIRE_GPIO_PORT, ONE_WIRE_PIN, GPIO_PIN_SET) #define OW_READ() HAL_GPIO_ReadPin(ONE_WIRE_GPIO_PORT, ONE_WIRE_PIN) // 将GPIO配置为开漏输出，才能实现双向IO void ow_init(void) { GPIO_InitTypeDef gpio = {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); gpio.Pin = ONE_WIRE_PIN; gpio.Mode = GPIO_MODE_OUTPUT_OD; // 开漏输出 gpio.Pull = GPIO_PULLUP; gpio.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(ONE_WIRE_GPIO_PORT, &gpio); OW_HIGH(); } uint8_t ow_reset(void) { uint8_t presence = 0; OW_LOW(); delay_us(500); // 拉低至少480us OW_HIGH(); // 释放总线 delay_us(60); // 等待从机应答窗口 presence = OW_READ(); // 读存在脉冲，低电平为0表示有设备 delay_us(500); // 等待整个复位周期结束 return presence == 0; }

有个细节要留意：GPIO必须配置成开漏模式，不能是推挽。如果是推挽输出，主机写高电平时会把总线强拉到VCC，从机根本拉不动，通信直接失败。开漏模式下，写“1”时相当于释放总线，由外部上拉电阻决定电平，这样从机才能正常拉低。

3.2 读一bit和写一bit的精确时序

1-Wire和I2C最大的不同在于：它用“脉冲宽度”和“间隙位置”来区分0和1。写时序中，主机要写0时，拉低总线60μs到120μs；要写1时，拉低总线1μs到15μs后释放，让总线在剩余时间保持高电平。读时序中，主机拉低总线1μs到15μs后释放，然后必须在15μs内采样总线状态：从机写1则总线保持高，从机写0则会继续拉低总线。

难点在于时间窗口非常短，标准速度下读采样点在15μs处，如果这里延时长了，可能错过从机拉低的窗口，读到错误的1。所以读时序必须紧跟着释放总线，不能插入太多其他代码。在STM32上，我习惯用DWT->CYCCNT精确延时，而不是依赖HAL_Delay——HAL_Delay最小单位是1ms，根本没法用在微秒级节奏里。下面是一个基于DWT的延时函数和读写bit的实现：

void delay_us(uint32_t us) { DWT->CYCCNT = 0; while (DWT->CYCCNT < us * (SystemCoreClock / 1000000)); } uint8_t ow_read_bit(void) { uint8_t bit = 0; OW_LOW(); delay_us(2); // 拉低2us，启动读时隙 OW_HIGH(); // 释放 delay_us(5); // 让总线稳定，同时从机开始输出 bit = OW_READ(); // 采样 delay_us(55); // 等待读时隙结束（总时长约60us） return bit; } void ow_write_bit(uint8_t bit) { if (bit) { OW_LOW(); delay_us(5); // 写1时隙：短拉低 OW_HIGH(); delay_us(60); // 剩余时间保持高 } else { OW_LOW(); delay_us(60); // 写0时隙：持续拉低 OW_HIGH(); delay_us(5); // 恢复高电平 } }

这段代码我实测下来在72MHz主频的STM32F103上，配合总线电容较小的情况，通信非常稳定。实际项目如果换到其他主频，一定要重新校准延时，最好用示波器看波形。

3.3 写字节和读字节

有了bit级别的函数，字节级别就简单了，按LSB先行逐位操作即可。注意1-Wire协议规定低位先发，和大多数SPI器件的高位先发相反，写驱动的时候别搞反。下面是标准实现：

void ow_write_byte(uint8_t data) { for (uint8_t i = 0; i < 8; i++) { ow_write_bit(data & 0x01); data >>= 1; } } uint8_t ow_read_byte(void) { uint8_t data = 0; for (uint8_t i = 0; i < 8; i++) { data >>= 1; if (ow_read_bit()) { data |= 0x80; } } return data; }

很多初学者在调试时发现读出来的数据全是0xFF或者全0，先别怀疑时序，先看是不是LSB顺序写反了：你把第一个bit当成了最高位，那结果肯定错得离谱。

3.4 ROM搜索算法：一条总线上挂多设备的关键

一条1-Wire总线上能挂多个从机，靠的是每个从机唯一的64位ROM码。ROM码结构是：8位家族码 + 48位序列号 + 8位CRC校验。主机通过ROM搜索算法，可以枚举总线上所有设备的ROM码，再通过Match ROM命令精确选择某个设备通信。

很多开发者只知道用Skip ROM（0xCC）跳过寻址，结果一条总线上挂两个同型号芯片时只能读到同一个数据，原因就是Skip ROM后所有设备同时响应，数据线被叠加成混乱的电平。解决的办法就是ROM搜索。搜索算法本质上是一个二叉树遍历，逐位确定ROM码的每一位。核心原理是：主机每次读两个bit，分别表示“总线上设备在这一位的互补输出”，有0、1、2三种情况：

• 00：说明总线上既有在此位为0的设备，也有为1的设备，存在分支。
• 01：所有设备此位为0。
• 10：所有设备此位为1。
• 11：没有设备响应，搜索结束。

读完后，主机再写一个bit，用来选中某一边的分支，这样每次下行一层，走完64层就得到一个完整的ROM码。实现时要用回溯算法遍历所有分支，才能把所有设备都以枚举出来。下面是一个常用的搜索实现：

typedef struct { uint8_t rom_codes[16][8]; // 最多支持16个设备 uint8_t count; } ow_device_list_t; void ow_search_rom(ow_device_list_t *devlist) { uint8_t last_discrepancy = 0; uint8_t search_rom[8] = {0}; devlist->count = 0; while (1) { uint8_t discrepancy[64] = {0}; uint8_t rom_bit[64] = {0}; uint8_t last_zero = 0; if (ow_reset() == 0) break; ow_write_byte(0xF0); // Search ROM命令 // 逐位搜索 for (uint8_t i = 0; i < 64; i++) { uint8_t bit_a = ow_read_bit(); uint8_t bit_b = ow_read_bit(); if (bit_a && bit_b) { // 无设备响应，搜索结束 break; } else if (bit_a == 0 && bit_b == 0) { // 出现分支 if (i < last_discrepancy) { rom_bit[i] = discrepancy[i]; } else if (i == last_discrepancy) { rom_bit[i] = 1; last_zero = i; } else { rom_bit[i] = 0; last_zero = i; } } else { rom_bit[i] = bit_a; } discrepancy[i] = rom_bit[i]; ow_write_bit(rom_bit[i]); } // 组ROM字节 for (uint8_t i = 0; i < 8; i++) { search_rom[i] = 0; for (uint8_t j = 0; j < 8; j++) { if (rom_bit[i * 8 + j]) { search_rom[i] |= (1 << j); } } } // 存入设备列表 if (devlist->count < 16) { memcpy(devlist->rom_codes[devlist->count], search_rom, 8); devlist->count++; } if (last_zero == 0) break; last_discrepancy = last_zero; } }

这段代码逻辑稍微复杂，我建议你在硬件上配合逻辑分析仪看协议时序来理解：每次主机会先发Search ROM（0xF0），然后从设备返回两个bit，一个表示“期望位”（一对一，表示设备ROM位是否为1），一个表示“补码位”（表示是否与期望位一致）。两个都为0说明设备们这一位不统一，需要你决定选0分支还是1分支；有一个为1说明大家这一位相同。逐位走下去，一条路径就是一个设备。

3.5 CRC8校验，防止读到错误数据

1-Wire协议中，每个ROM码的第8字节是前56bit的CRC8，读写DS18B20的暂存器时，第9字节也是CRC8。理论上主机可以自己算一遍CRC，和读到的值对比，来判断通信是否出错。实际上在长线上，干扰可能让某个bit翻转，CRC不匹配时就应该丢弃这次数据，而不是直接使用。

1-Wire的CRC8生成多项式是x^8 + x^5 + x^4 + 1，对应二进制0x31。注意它不反转输入输出，初始值为0。下面给出查表法实现，效率高，适合单片机：

static uint8_t crc8_table[256]; void crc8_init(void) { for (uint16_t i = 0; i < 256; i++) { uint8_t crc = i; for (uint8_t j = 0; j < 8; j++) { if (crc & 0x80) crc = (crc << 1) ^ 0x31; else crc <<= 1; } crc8_table[i] = crc; } } uint8_t ow_crc8(const uint8_t *data, uint8_t len) { uint8_t crc = 0; for (uint8_t i = 0; i < len; i++) { crc = crc8_table[crc ^ data[i]]; } return crc; }

我在项目里会同时对ROM码和温度数据都做CRC校验，防止把错误的温度上传给上位机，尤其在冷链验证这种对数据准确性要求高的场景，哑数据比没数据更麻烦。

4. 实战：STM32驱动多路DS18B20温度采集

这一节把前面的零碎知识串起来，从硬件连接到代码流程，完整实现一个“一条总线挂3个DS18B20、每个探头独立读取温度”的经典工程。

4.1 硬件连接

我用的核心板是STM32F103C8T6（蓝丸板），DS18B20采用外部供电模式，电路连接如下：

外部供电比寄生供电更稳妥，多设备并联时也更容易驱动。上拉电阻我用2.2kΩ而不是4.7kΩ——因为三个设备并联后输出电容增加，2.2kΩ能保证上升沿足够快。接线采用普通的杜邦线，长度控制在20cm以内，先保证实验环境稳定。

4.2 完整驱动流程

读取DS18B20温度的流程分三步：初始化 -> 发送Skip ROM/Match ROM -> 启动温度转换 -> 读取暂存器。多设备时，先通过ROM搜索获得设备列表，然后依次对每个设备执行Match ROM + 读取。

下面是核心代码：

float read_temp_by_rom(uint8_t *rom) { uint8_t scratchpad[9] = {0}; int16_t raw = 0; float temp = 0; if (ow_reset() == 0) return -999; ow_write_byte(0x55); // Match ROM for (uint8_t i = 0; i < 8; i++) { ow_write_byte(rom[i]); } ow_write_byte(0x44); // 启动温度转换 delay_ms(750); // 等待转换完成（12位分辨率约750ms） if (ow_reset() == 0) return -998; ow_write_byte(0x55); // 再次Match ROM for (uint8_t i = 0; i < 8; i++) { ow_write_byte(rom[i]); } ow_write_byte(0xBE); // 读取暂存器 for (uint8_t i = 0; i < 9; i++) { scratchpad[i] = ow_read_byte(); } // CRC校验 if (ow_crc8(scratchpad, 8) != scratchpad[8]) { return -997; // CRC错误 } raw = (scratchpad[1] << 8) | scratchpad[0]; temp = raw * 0.0625f; // 12位分辨率，LSB = 1/16 = 0.0625°C return temp; }

在main里先执行一遍ROM搜索：

ow_device_list_t devices; ow_init(); crc8_init(); ow_search_rom(&devices); printf("Found %d devices\\n", devices.count); for (uint8_t i = 0; i < devices.count; i++) { float t = read_temp_by_rom(devices.rom_codes[i]); printf("Device %d: %.2f°C\\n", i, t); }

如果你只有单设备，更简单的方式是Skip ROM：发0xCC跳过寻址，然后直接发0x44启动转换、0xBE读取。这样代码量更少，但一定确保总线上只有一个1-Wire设备。

4.3 实测数据与结果验证

我实际测试时室温约26°C，三个DS18B20分别贴在桌面、手心、冰水杯壁，读数如下：

用冰水混合物做基准，DS18B20读数在2°C左右波动，考虑到冰水在杯壁测量存在误差，精度表现符合预期。值得注意的是，三个设备在每次上电后ROM搜索的顺序不一定固定，可能是随机顺序，所以在多设备项目里，建议通过上位机或配置程序把ROM码和物理位置绑定，而不是依赖搜索顺序来区分传感器。

4.4 提高效率：并发转换

如果总线上有多台DS18B20，逐台发转换命令再等待750ms效率太低。优化的做法是：先发Skip ROM + 0x44，让总线上所有设备同时开始转换，等待750ms后，再逐个Match ROM读温度。这样总耗时大约是“1次转换时间 + N次读取时间”，而不是“N次转换时间”。

注意这个技巧只适用于外部供电模式。寄生供电模式下，所有设备同时转换会导致总线电流需求过大，单靠弱上拉根本供不上，必须使用强上拉电路。因此工业现场多采用外部供电。

4.5 移植到其他平台

如果用的是树莓派，Linux内核自带w1-gpio和w1-therm驱动模块，硬件上把DS18B20的数据线接到GPIO4（BCM编号），上拉4.7kΩ电阻，再修改/boot/config.txt启用dtoverlay=w1-gpio，重启后就能在/sys/bus/w1/devices/下看到形如28-0000xxxxx的目录，读w1_slave文件就能拿到温度值。这个方法很多智能家居项目都在用，搭建成本极低。

如果用的是Arduino，OneWire库和DallasTemperature库已经封装好了底层时序，你只需要关心业务逻辑。但我想提醒的是——用库没问题，但至少要理解它背后做了什么。我在面试嵌入式岗位时，经常问候选人“1-Wire的读时序和写时序有什么区别”，能答上来的人少之又少，而遇到真正的bug时，不懂时序的人只能瞎调参数，完全没法定位问题。

5. 常见问题排查与避坑实录

5.1 复位失败，总线上“没有设备”

这是最常见的故障。排查步骤我一般按这个顺序来：

• 先确认GPIO是不是开漏模式，很多错误出在这里。
• 用示波器看复位波形，重点看主机拉低时间和释放后的上升沿。如果上升沿太缓，说明上拉电阻太大或线缆电容太大，适当减小上拉电阻。
• 确认DS18B20供电电压在3.0V到5.5V之间，VDD和GND不要接反。
• 检查总线上设备数量，多个设备时首次搜索建议断开其他设备，只保留一个调试。

5.2 读数全为85°C

DS18B20有个特性：上电后暂存器默认值是0x0550，对应+85°C。如果你读到这个值，说明温度转换没有真正完成，或者你直接读到了暂存器的初始值。常见原因有两个：

• 发送0x44后等待时间不够。12位分辨率需要750ms，有的MCU在主频低或者中断频繁时，实际时间被拉长，这时建议延长到900ms以上。
• 总线在转换期间供电不足。寄生供电模式下必须强上拉总线，否则芯片内部电容存电不够，转换不会成功。

5.3 多设备时搜索不到或搜索中途卡死

多设备搜索失败，优先怀疑时序：每个bit的读时序采样点是否准确、延时是否符合数据手册。其次，检查总线上是否有其他设备在干扰，比如DS2431的响应时序比DS18B20略快，混挂时搜索算法也能处理，但前提是主机时序正确。

还有一点容易忽略：多设备共用一条长线时，如果某段的接线端子氧化或接触不良，会产生寄生电容和抖动，可能导致搜索到的ROM码在CRC校验时出错。我在项目里遇到过隔几天就少一个设备的情况，最后发现是接线端子松动，重新压接后问题消失。

5.4 CRC错误频繁

如果读到的数据CRC经常错误，先增加重试次数，重试还不能解决就检查波形质量。我用逻辑分析仪抓过不少波形，发现常见的CRC错误场景是：总线空闲时被外部干扰拉低了几微秒，这种“毛刺”会让从机的内部状态机会错乱，后面所有数据都瞎掉。对策是在DQ引脚上加一个100pF到1nF的小电容滤高频干扰，但注意电容不能太大，否则上升沿会变缓，导致时序违反规范。

5.5 加了线缆长度后通信不稳定

距离超过30m时，线缆电容急剧增加，标准上拉电阻跟不上充电速度。我的经验做法是：

• 上拉电阻降到1kΩ，甚至470Ω（注意从机驱动能力）。
• 主机通信前先“强上拉”50μs到100μs，把总线电容充满电，再开始复位时序。
• 将通信速率从标准模式降到overdrive模式是没用的，因为overdrive时序更严格，反而更容易失败。长距离时更应该用标准模式配合强上拉。

5.6 备用避坑清单

• 千万不要在1-Wire总线上直接并联去耦合电容到地，这会让上升沿变得极慢。
• DS18B20的电源引脚如果和逻辑电源不是同一个电源轨，要保证两者是共地的。
• 用ST-Link给STM32供电时，个别ST-Link仿真的IO电平是3.3V，DS18B20能工作，但上拉电阻接5V时要注意电平转换，避免引脚超过MCU耐压。
• 用锂电池供电的项目，电池电压会从4.2V逐渐下降，如果DS18B20直接由电池供电，低电压时上拉能力变弱，最好用稳压电源供电。

6. 个人经验和扩展思路

把1-Wire协议完整跑通后，我发现它最迷人的地方不是“能省一根线”，而是它用极简的硬件实现了一个相当完整的网络协议栈：有物理层时序、有链路层寻址、有传输层校验。这些设计思想放到今天看仍然很有价值。实际项目里，我通常会把1-Wire、I2C、SPI按场景分工：有大量数据要高速传输的用SPI，需要多主通信的用I2C，而像“温度传感器散布在50米范围”这种场景，1-Wire是绕不开的选择。

如果你想把项目做得更完整，可以尝试几个方向：一是把温度数据接入MQTT，用ESP8266或ESP32读1-Wire总线上报云端，做成一个多房间温控系统；二是加入自动发现机制，把新插入的DS18B20自动识别并注册到配置表里，方便热插拔维护；三是用DS2408做远端IO控制，在总线上混合挂传感器和继电器，省掉一路控制线。

最后分享一个我踩过的坑：有一次项目要极限压缩成本，把上拉电阻省了，依赖MCU内部的上拉，结果短距离能通，线稍微一长就疯狂丢数据。1-Wire这个协议看着简单，但每一个电阻、每一段延时都在约束之内，真的是“差之毫厘，失之千里”。先规规矩矩按手册来，再谈优化，这是走完这条路最大的体会。