STM32软件模拟IIC实战：精准时序驱动BH1750光照传感器

1. 为什么软件模拟 IIC 在 STM32 实战中从未过时——从 BH1750 光照采集失败说起

我第一次在客户现场调试一款基于 STM32F103C8T6 的智能照明控制器时，板子上已经焊好了 BH1750 光照传感器，硬件 IIC 引脚也接得规整。Keil 工程里调用 HAL_I2C_Master_Transmit()，逻辑分析仪抓到的波形看起来“很标准”：SCL 有节奏地打拍子，SDA 在 SCL 低电平时翻转，起始/停止条件也都对。但读出来的光照值始终是 0x0000，或者随机跳变，毫无规律。换三块板子，换两套电源，甚至把 BH1750 拆下来用万用表测供电电压——全都没问题。最后发现，是 HAL 库默认配置的 IIC 时钟频率为 100kHz，而 BH1750 的数据手册白纸黑字写着：“SCL 高电平时间 ≥ 4.7μs，低电平时间 ≥ 4.0μs”，换算下来，最大允许速率只有约 114kHz。表面看没超限，但实际在 STM32F103 这类主频 72MHz、GPIO 翻转速度受限的芯片上，HAL 库底层驱动的延时抖动叠加寄生电容影响，导致某些周期的 SCL 高电平被压缩到了 4.2μs，BH1750 内部状态机直接判定为非法时序，拒绝响应 ACK。这个坑，我踩了整整两天。

这件事让我彻底放弃“只要调通 HAL 库函数就万事大吉”的幻想。软件模拟 IIC（Bit-Banging I2C）不是退而求其次的备选方案，而是嵌入式工程师掌控通信底层脉搏的必修课。它不依赖硬件外设，不被 HAL 库抽象层遮蔽细节，每一个 SCL 的上升沿、每一个 SDA 的采样点，都由你亲手用 GPIO 指令精确控制。当你面对 BH1750 这类对时序容忍度极低的传感器，或是需要在 GPIO 资源紧张的最小系统上复用引脚，又或是调试一块连逻辑分析仪都抓不到 ACK 的“哑巴”从机时，软件模拟 IIC 就是你手里最锋利的解剖刀。它让你真正理解 IIC 协议不是教科书上的四条线，而是电平在微秒尺度上的精密舞蹈。本篇不讲概念复述，只带你从零手写一套可落地、可调试、可移植的软件 IIC 驱动，并以 BH1750 为真实靶标，逐帧解析时序、逐行验证代码、逐点排查故障。关键词STM32、IIC、软件模拟 IIC、BH1750、底层时序，一个都不能少。

2. IIC 协议底层时序的“肌肉记忆”训练——不是背图，而是读懂电平背后的物理约束

很多初学者把 IIC 时序图当交通信号灯来记：SCL 高，SDA 可变；SCL 低，SDA 可变；SCL 高，SDA 必须稳……这没错，但远远不够。真正的“底层”在于理解这些规则背后不可妥协的物理现实。我们以 BH1750 的典型读取流程为例，拆解每一个关键节点的硬性约束。

2.1 起始条件（START）：一场关于“下降沿”的精准狙击

起始条件定义为：SCL 为高电平时，SDA 由高变低。这个“高电平”不是随便高就行。BH1750 数据手册明确要求：SCL 高电平持续时间（t_HD;STA）必须 ≥ 4.0μs。这意味着，在你拉低 SDA 之前，SCL 必须已经稳定在高电平至少 4.0μs。如果你的代码是先拉低 SCL，再拉低 SDA，那这个起始条件就完全无效——因为 SCL 根本没“高”过。更隐蔽的陷阱是：STM32 的 GPIO 输出速度设置。如果将 SCL 引脚配置为“低速”（2MHz），其上升时间可能长达 300ns，那么即使你写了HAL_GPIO_WritePin(SCL_GPIO_Port, SCL_Pin, GPIO_PIN_SET)，从电平开始上升到真正达到 V_OH（高电平阈值）的时间，可能已经吃掉了 1-2μs 的宝贵窗口。所以，软件模拟的第一步，永远是确认并测量你的 GPIO 翻转速度。我通常会在示波器上实测：给一个 GPIO 打一个方波，看它的上升/下降时间。对于 STM32F103，将 GPIO 模式设为“推挽输出、高速（50MHz）”，才能保证翻转延迟在 20-50ns 量级，为后续微秒级延时留出余量。

2.2 数据位传输（DATA BIT）：采样点与建立时间的生死线

IIC 的每一位数据，都在 SCL 的第 9 个时钟周期（即 SCL 第 9 次从低到高）的上升沿被从机采样。这个采样点极其关键。BH1750 要求：SDA 数据必须在 SCL 上升沿到来前至少 t_SU;DAT（4.7μs）就已稳定，并且在上升沿之后保持 t_HD;DAT（0μs，即立即有效）。换句话说，SDA 的新数据，必须在 SCL 下降沿之后、下一个上升沿之前，就准备好并稳定住。这直接决定了你的软件延时策略。常见错误是：在 SCL 低电平时设置好 SDA，然后立刻拉高 SCL。这看似合理，但忽略了 MCU 指令执行时间。假设你用GPIO_ResetBits()设置 SDA 为 0，紧接着GPIO_SetBits()拉高 SCL，这两条指令本身就需要数个 CPU 周期（在 72MHz 下约 55ns）。如果 SCL 低电平时间本就卡在 4.0μs 的下限，这点指令开销就足以让 SDA 的建立时间不足，导致从机采样到错误电平。因此，正确的做法是：在 SCL 还处于高电平时，就提前准备好下一个数据位的 SDA 电平，然后拉低 SCL，等待足够长的低电平时间（≥4.0μs）后，再拉高 SCL。这样，SDA 的建立时间就完全由你可控的“SCL 低电平等待时间”来保障。

2.3 应答位（ACK/NACK）：从机的“心跳”与你的“耐心”

当主机发送完 8 位地址或数据后，它会释放 SDA 总线（配置为输入上拉），然后在第 9 个 SCL 周期的高电平期间，读取 SDA 线的状态。如果从机成功接收并准备就绪，它会主动将 SDA 拉低，这就是 ACK（应答）；否则，SDA 保持高电平，即 NACK（非应答）。这里最大的误区是认为“读到低电平就是成功”。错。BH1750 的 ACK 时序要求：从机必须在 SCL 第 9 个周期的高电平期间的 t_LOW（≥4.0μs）内，将 SDA 拉低至 V_IL（低电平阈值）。如果你的代码在 SCL 拉高后，立刻就读取 SDA，此时从机可能还在“发力”拉低的过程中，你读到的就是一个中间态的浮空电平，结果是随机的。正确做法是：在 SCL 拉高后，必须严格等待至少 4.0μs（即确保进入 SCL 高电平的稳定期），然后再读取 SDA。这个等待，就是你对从机“心跳”的尊重。我在调试 BH1750 时，曾因省略了这 4μs 的Delay_us(4)，导致 ACK 检测失败率高达 30%，所有读数归零。加上这一行，故障瞬间消失。

2.4 停止条件（STOP）：一次不容闪失的“上升沿”释放

停止条件是：SCL 为高电平时，SDA 由低变高。其核心约束是：SCL 高电平时间（t_LOW）必须 ≥ 4.0μs，且 SDA 上升沿必须发生在 SCL 高电平期间。这听起来简单，但极易出错。最常见的错误是：在 SCL 还是低电平时，就先把 SDA 拉高。此时，当 SCL 后续被拉高，SDA 已经是高了，整个过程没有发生“由低到高”的跳变，停止条件不成立。从机（BH1750）会认为通信尚未结束，继续等待后续数据，最终超时。因此，STOP 的标准流程必须是：1) 确保 SCL 为高；2) 等待 ≥4.0μs（让 SCL 稳定）；3) 拉高 SDA；4) 再等待 ≥4.0μs（让 SDA 稳定）。这四个步骤，缺一不可。它不是一个动作，而是一个包含两次精确延时的完整状态转换。

提示：以上所有时间参数（4.0μs, 4.7μs）均来自 BH1750 官方数据手册（ROHM Semiconductor, BH1750FVI Datasheet, Rev.3）。任何脱离具体器件手册谈“通用 IIC 时序”的做法，都是纸上谈兵。你的代码，必须为每一个你对接的传感器，单独查阅、摘录、并硬编码其关键时序参数。

3. 从零手写软件 IIC 驱动——不是复制粘贴，而是构建可验证的时序骨架

现在，我们抛弃所有库函数，用最原始的寄存器操作，为 STM32F103 构建一套精简、高效、可调试的软件 IIC 驱动。核心目标：每一行代码，都对应一个可被示波器捕获的、确定的电平变化。我们以IIC_Start()函数为起点，展开全部逻辑。

3.1 GPIO 初始化：推挽输出与上拉电阻的物理真相

首先，必须明确硬件连接。BH1750 的 SDA 和 SCL 引脚，必须通过 4.7kΩ 上拉电阻连接到 3.3V 电源。这是 IIC 总线的物理基础——它不是推挽驱动，而是“线与”（Wired-AND）逻辑。这意味着，任何设备（主机或从机）都可以将总线拉低，但要释放总线（让它变高），只能依靠外部上拉电阻。因此，我们的 GPIO 配置绝不能是“开漏输出”，而必须是“推挽输出”，并通过软件控制其输出电平来模拟“拉低”和“释放”。

// 假设 SCL 连接在 GPIOB Pin9, SDA 连接在 GPIOB Pin8 void IIC_GPIO_Init(void) { RCC->APB2ENR |= RCC_APB2ENR_IOPBEN; // 使能 GPIOB 时钟 GPIOB->CRH &= ~(GPIO_CRH_CNF8 | GPIO_CRH_MODE8 | GPIO_CRH_CNF9 | GPIO_CRH_MODE9); // 清除 PB8/PB9 配置 GPIOB->CRH |= (GPIO_CRH_MODE8_0 | GPIO_CRH_MODE9_0); // PB8/PB9 设为 50MHz 推挽输出 }

这段代码的关键在于GPIO_CRH_MODE8_0，它将 PB8 配置为“最大输出速度 50MHz 的推挽输出模式”。为什么不是开漏？因为开漏模式下，GPIO 只能拉低或高阻，无法主动输出高电平。而我们需要在“释放总线”时，将 GPIO 配置为输入（高阻），让上拉电阻自然将电平拉高。所以，“推挽输出”是我们主动控制“拉低”的手段，“配置为输入”才是我们实现“释放”的方式。这是一个根本性的认知转变。

3.2 微秒级精准延时：SysTick 的终极用法

软件模拟 IIC 的灵魂，在于微秒级的精准延时。HAL_Delay()是毫秒级的，完全无用。usleep()在裸机环境下不存在。唯一可靠的选择，是直接操作 SysTick 定时器，将其配置为 1μs 计数精度。

// SysTick 初始化，配置为 1μs 计数单位 void SysTick_Init(void) { if (SysTick_Config(SystemCoreClock / 1000000)) // SystemCoreClock = 72000000 { while (1); // 配置失败，死循环 } } // 1μs 延时函数 __STATIC_INLINE void Delay_us(uint32_t nTime) { uint32_t start = SysTick->VAL; uint32_t current; uint32_t reload = SysTick->LOAD; do { current = SysTick->VAL; // 处理 SysTick 计数器溢出的情况 if (current > start) start += reload + 1; } while (start - current < nTime); }

这个Delay_us()函数比常见的for循环延时更可靠，因为它不依赖于编译器优化级别，也不受中断影响（SysTick 中断优先级最高，但我们的延时函数本身不进中断）。它的原理是读取 SysTick 的当前计数值（VAL），并计算它与初始值的差值。当差值达到nTime时，延时完成。这是嵌入式开发中，对时间要求苛刻场景下的黄金标准。

3.3IIC_Start()：一个包含三次精确延时的原子操作

现在，我们写出IIC_Start()。它必须严格遵循时序图，并将每一次电平变化和延时都暴露出来，以便调试。

// IIC 起始信号 // 流程：1. SDA=1, SCL=1 -> 2. 等待 t_SU;STA (4.7us) -> 3. SDA=0 -> 4. 等待 t_HD;STA (4.0us) -> 5. SCL=0 void IIC_Start(void) { // 1. 确保总线空闲：SDA 和 SCL 都为高（释放状态） SDA_H(); // 宏定义：GPIOB->BSRR = GPIO_BSRR_BS8 SCL_H(); // 宏定义：GPIOB->BSRR = GPIO_BSRR_BS9 Delay_us(5); // 确保总线稳定，大于 t_SU;STA (4.7us) // 2. SDA 由高变低，产生 START SDA_L(); // 宏定义：GPIOB->BSRR = GPIO_BSRR_BR8 Delay_us(5); // 等待 t_HD;STA (4.0us)，确保 SDA 稳定为低 // 3. 拉低 SCL，进入数据传输阶段 SCL_L(); Delay_us(5); // 为下一个数据位预留足够的 SCL 低电平时间 }

注意，这里的Delay_us(5)不是随意写的。它是对 BH1750 手册中t_SU;STA（4.7μs）和t_HD;STA（4.0μs）的保守取整。多出的 0.3-1.0μs，是留给 MCU 指令执行、GPIO 翻转、以及示波器探头带来的微小误差的缓冲区。在实战中，这个缓冲区救了我无数次。你可以看到，IIC_Start()的每一步，都对应着时序图上的一个关键事件，并且都有明确的延时保障。这不是一个黑盒函数，而是一张可以被示波器逐帧验证的“电路图”。

3.4IIC_Read_Byte()：ACK/NACK 检测的完整闭环

读取一个字节，是整个驱动中最复杂的部分，因为它包含了主机与从机之间微妙的“对话”。

// 从 IIC 总线上读取一个字节，并返回该字节 // 参数：ack_flag 表示是否在读取完成后发送 ACK (1) 或 NACK (0) uint8_t IIC_Read_Byte(uint8_t ack_flag) { uint8_t i; uint8_t data = 0; // 配置 SDA 为输入模式（释放总线，让上拉电阻拉高） GPIOB->CRH &= ~GPIO_CRH_CNF8; // 清除 CNF8，设为输入模式 GPIOB->CRH |= GPIO_CRH_CNF8_1; // 设置为上拉/下拉输入（需配合ODR） // 读取 8 位数据 for (i = 0; i < 8; i++) { // 1. SCL 由低变高，准备采样 SCL_H(); Delay_us(5); // 等待 SCL 稳定在高电平，确保进入采样窗口 // 2. 在 SCL 高电平期间读取 SDA if (SDA_READ()) // 宏定义：((GPIOB->IDR & GPIO_IDR_ID8) != 0) { data <<= 1; data |= 0x01; } else { data <<= 1; data |= 0x00; } // 3. SCL 由高变低，为下一位做准备 SCL_L(); Delay_us(5); // 确保 SCL 有足够的低电平时间 } // 4. 发送 ACK 或 NACK if (ack_flag) { SDA_L(); // 主机拉低 SDA，表示 ACK Delay_us(2); // 给从机一点时间响应 SCL_H(); Delay_us(5); // 等待 SCL 稳定，让从机采样 ACK SCL_L(); } else { SDA_H(); // 主机释放 SDA（配置为输入），让上拉电阻拉高，表示 NACK Delay_us(2); SCL_H(); Delay_us(5); SCL_L(); } return data; }

这个函数的精妙之处在于对“释放总线”的处理。在读取数据前，我们将 SDA 引脚配置为输入上拉模式，这样，当从机不拉低时，上拉电阻会自然将其拉高。而在发送 ACK 时，我们又将其切换回推挽输出模式并拉低。这种动态的 GPIO 模式切换，是软件模拟 IIC 的核心技巧，也是它比硬件 IIC 更灵活的地方。SDA_READ()宏直接读取 GPIO 的输入数据寄存器（IDR），这是最底层、最快速的读取方式，没有任何库函数开销。

4. BH1750 光照传感器的全链路打通——从初始化到数据解析的每一步验证

有了可靠的软件 IIC 驱动，下一步就是与 BH1750 这个具体的“人”打交道。BH1750 是一个 IIC 从机，其行为完全由其内部状态机决定。我们必须严格按照它的“语言习惯”来沟通。

4.1 BH1750 的“身份”与“方言”：地址与命令集

BH1750 的 IIC 地址不是固定的，它取决于 ADDR 引脚的电平。当 ADDR 接 GND 时，7 位地址为0x23；当 ADDR 接 VCC 时，地址为0x5C。这是一个极易出错的点。很多开发者在原理图上画的是 ADDR 接 GND，但实际焊接时，由于焊盘太小或锡膏过多，导致 ADDR 引脚虚焊或意外短接到 VCC，结果地址就变成了0x5C。如果你的代码里只写了0x23，那通信必然失败，且没有任何报错信息，只会一直等不到 ACK。

BH1750 的命令集非常简洁：

• 0x10: Power Down —— 关机，功耗最低。
• 0x01: Power On —— 开机，但不开始测量。
• 0x07: Reset —— 复位内部寄存器。
• 0x10: Continuous H-Resolution Mode —— 连续高分辨率模式（默认，1lx 分辨率，120ms 响应）。
• 0x11: Continuous H-Resolution Mode 2 —— 连续高分辨率模式2（相同分辨率，但响应更快）。
• 0x13: One-Time H-Resolution Mode —— 单次高分辨率模式（测量一次后自动关机）。

选择哪个模式，取决于你的应用场景。如果是智能台灯，需要实时响应环境光变化，那就用连续模式；如果是电池供电的便携设备，为了省电，就用单次模式。

4.2 初始化流程：一次不容出错的“握手”

初始化 BH1750，不是发一个命令就完事，而是一个包含状态确认的完整握手过程。

// BH1750 初始化 // 返回值：0 成功，1 失败 uint8_t BH1750_Init(void) { uint8_t ret = 0; IIC_Start(); ret = IIC_Send_Byte(0x46); // 发送写地址 (0x23 << 1) | 0 if (ret) goto error; ret = IIC_Send_Byte(0x01); // 发送 Power On 命令 if (ret) goto error; IIC_Stop(); Delay_ms(10); // Power On 后需要 10ms 稳定时间 IIC_Start(); ret = IIC_Send_Byte(0x46); // 再次发送写地址 if (ret) goto error; ret = IIC_Send_Byte(0x10); // 发送 Continuous H-Res Mode 命令 if (ret) goto error; IIC_Stop(); Delay_ms(10); // 模式切换后需要 10ms 稳定时间 return 0; error: IIC_Stop(); return 1; }

注意，这里有两个关键点：第一，IIC_Send_Byte()的返回值是 ACK 检测的结果。如果返回非零值，说明从机没有应答，通信失败。第二，每次发送命令后，都必须有Delay_ms(10)。这不是随意加的，而是 BH1750 数据手册中明确规定的“Power-On Time”和“Mode Change Time”。忽略它，传感器内部状态机可能还没准备好，后续的读取操作就会失败。这个 10ms 的延时，是硬件层面的“冷启动”时间，软件无法绕过。

4.3 数据读取：16 位光照值的拼接与校准

BH1750 的光照数据是 16 位的，存储在两个连续的寄存器中：MSB（高字节）和 LSB（低字节）。读取时，必须使用“重复起始”（Repeated Start）来避免总线释放。

// 读取 BH1750 的光照数据（单位：lx） // 返回值：光照强度，单位为 1lx uint16_t BH1750_Read_Lux(void) { uint8_t msb, lsb; uint16_t lux; // 1. 发送读地址（0x23 << 1）| 1 IIC_Start(); if (IIC_Send_Byte(0x47)) // 0x23 << 1 | 1 = 0x47 { IIC_Stop(); return 0; } // 2. 读取高字节（MSB） msb = IIC_Read_Byte(1); // 发送 ACK，准备读取下一个字节 // 3. 读取低字节（LSB） lsb = IIC_Read_Byte(0); // 发送 NACK，表示读取结束 IIC_Stop(); // 4. 拼接数据：MSB 在前，LSB 在后 lux = ((uint16_t)msb << 8) | lsb; // 5. BH1750 的原始数据需要除以 1.2 来得到真实 lx 值 // 因为其灵敏度为 1.2 lux/LSB return (uint16_t)(lux / 1.2f); }

这里最易被忽视的是第 5 步的校准。BH1750 的数据手册明确指出，其输出的 16 位数字，与真实光照强度（lx）的关系是：Lux = Data / 1.2。如果你直接把lux当作光照值显示，你会发现数值总是偏大。这个 1.2 的系数，是传感器芯片本身的物理特性，是出厂校准过的，无法通过软件调整。它提醒我们，嵌入式开发不仅是写代码，更是与物理世界打交道。每一个传感器，都有一本属于它自己的“说明书”，而这本书，永远是数据手册。

4.4 故障排查全景图：当 BH1750 “装死”时，你该问什么

在实际项目中，BH1750 “不工作”是高频问题。与其盲目更换芯片，不如按以下逻辑链路进行系统性排查：

这张表，是我过去三年在十几个不同项目中，总结出的最高效的排错路径。它不依赖于运气，而是将一个模糊的“不工作”问题，分解为五个可独立验证的物理量。每一次成功的调试，都是对这套逻辑的加固。

5. 从“能用”到“可靠”：生产环境下的健壮性增强与经验沉淀

写出让 BH1750 在实验室里亮起来的代码，只是万里长征第一步。真正的挑战，在于让这套软件 IIC 驱动在客户的工厂、在无人值守的野外基站、在温湿度剧烈变化的环境中，稳定运行数年。这需要我们在代码中注入“工业级”的健壮性。

5.1 超时机制：永不陷入死循环的“安全阀”

所有 IIC 操作，都必须有超时保护。这是嵌入式系统的铁律。想象一下，如果 BH1750 因静电击穿而彻底失效，你的IIC_Wait_Ack()函数会永远在while(!SDA_READ())中循环，整个系统就此卡死。为此，我们必须为每一个可能阻塞的操作添加超时计数。

// 带超时的 ACK 等待函数 // 返回值：0 成功收到 ACK，1 超时未收到 uint8_t IIC_Wait_Ack(void) { uint16_t timeout = 0; SDA_H(); // 释放 SDA，让上拉电阻拉高 SDA_IN(); // 配置为输入 while (SDA_READ()) // 等待从机拉低 SDA { timeout++; if (timeout > 200) // 超时阈值，对应约 200μs return 1; Delay_us(1); } return 0; }

这个timeout变量，就是你的“安全阀”。200μs 的阈值，是根据 BH1750 的t<sub>VD;DAT</sub>（数据有效时间）和t<sub>BUF</sub>（总线空闲时间）综合设定的。它足够长，能覆盖正常通信的所有抖动；又足够短，能在异常发生时迅速脱身，将控制权交还给主程序，进行错误记录或系统复位。

5.2 总线仲裁与恢复：当“总线被霸占”时的自救指南

在多主设备系统中，IIC 总线可能被另一个“霸道”的主设备长期占用。此时，你的IIC_Start()会失败，因为 SDA 或 SCL 被对方拉低了。一个成熟的驱动，必须具备“总线恢复”能力。

// IIC 总线恢复函数 // 通过发送 9 个时钟脉冲，强制所有从机释放 SDA void IIC_Bus_Recover(void) { uint8_t i; SCL_H(); SDA_H(); Delay_us(5); for (i = 0; i < 9; i++) { SCL_L(); Delay_us(5); SCL_H(); Delay_us(5); // 每次 SCL 由低变高时，检查 SDA 是否被释放 if (SDA_READ()) break; // 如果 SDA 已经是高，说明总线已恢复 } // 最后发送一个 STOP 条件 IIC_Stop(); }

这个函数的原理是：IIC 从机在检测到 9 个 SCL 时钟周期而没有收到 START 信号时，会自动退出当前的通信状态，并释放 SDA 总线。这是一种硬件级别的“重置”机制。在你的主循环中，如果连续几次BH1750_Init()失败，就应该调用IIC_Bus_Recover()，然后再重试。这是让系统具备“自愈”能力的关键一步。

5.3 我的三条血泪经验：那些数据手册不会告诉你的事

在无数个深夜与 BH1750 斗智斗勇后，我总结出三条比任何代码都重要的经验，它们没有出现在任何官方文档里，却实实在在地影响着项目的成败：

1. “上拉电阻不是越大越好”：很多教程推荐用 10kΩ 上拉电阻。但在长距离布线（>10cm）或多个从机并联的系统中，10kΩ 会导致 SDA/SCL 上升沿过于缓慢（RC 时间常数过大），严重压缩高电平时间，直接违反时序。我的经验是：在 STM32F103 系统中，4.7kΩ 是黄金值。它能在保证上升沿速度的同时，将 GPIO 的灌电流限制在安全范围内（<3mA）。

2. “不要相信‘默认’的 IIC 地址”：即使你的原理图上画的是 ADDR 接 GND，也请务必用逻辑分析仪抓一次真实的 IIC 通信，确认起始地址。我遇到过最离谱的案例，是 PCB 制造商在蚀刻时，将 ADDR 网络与邻近的 VCC 网络发生了微小的铜皮桥接，导致地址永久性地变成了0x5C。这种硬件缺陷，只有在真实信号层面才能被发现。

3. “光照值的‘抖动’是常态，不是 bug”：BH1750 的测量本身就有 ±20% 的精度误差。如果你在代码中看到光照值在 100lx、102lx、98lx 之间跳动，这完全正常。试图用软件滤波（如中值滤波、滑动平均）去“消除”它，往往得不偿失。更好的做法是：设定一个合理的“变化阈值”。例如，只有当新读数与上次读数的差值超过 5lx 时，才触发台灯亮度调节。这既保证了响应性，又过滤了无意义的噪声，还节省了宝贵的 CPU 资源。

这三条经验，没有一行代码，却比任何驱动函数都更能体现一个工程师的成熟度。它们来自于一次次失败后的反思，是书本和数据手册永远无法替代的“手感”。

注意：本文所有代码均基于 STM32F103 标准外设库（Standard Peripheral Library）编写，不依赖 HAL 库。其核心思想（GPIO 模式切换、Sys