1. 为什么是BH1750这块传感器的脾气和本事做STM32嵌入式项目的人迟早会遇到“测光照”这个需求——可能是智能家居里的窗帘自动开合可能是大棚补光灯的自动控制也有可能是产品做亮暗自适应屏幕。方案无非三种光敏电阻、光敏二极管、数字光照传感器。我早期贪便宜用过光敏电阻被温漂和校准问题折磨得够呛同一光照下冬天和夏天的ADC读数能差出一大截换个批次又得重新标定。后来换到BH1750才算真正省心。BH1750是罗姆ROHM出品的环境光强度数字传感器I2C接口16位ADC输出量程1到65535 lx测量结果直接以数字量输出不需要自己做ADC换算和线性校准。它的核心价值在于“人眼感知近似”——光谱响应经过专门设计和视觉灵敏度的曲线匹配度比光敏电阻高得多所以做出来的产品行为更符合人的直觉。这颗芯片的功耗也低待机时微安级别非常适合电池供电的项目。另外它不需要外部校准出厂前已经调好这在量产阶段能省一大笔生产测试工时。你不需要额外搭运放电路也不需要做光照传感器的手动校准几颗电阻电容就能让它稳定工作这是它能在创客圈和工业项目里都用得开的核心原因。选STM32F103C8T6来带它是性价比最优解。这颗芯片目前市场价相当便宜某宝上十几块钱能买一片Cortex-M3内核72MHz主频有硬件I2C外设64KB Flash、20KB SRAM做光照采集这种轻量级任务绰绰有余。更关键的是F1系列的资料极其丰富不管是寄存器开发还是标准库、HAL库踩坑解法一搜一大把非常适合新手练手和快速出原型。顺便说一句“国产替代”这个词最近在STM32圈子里特别热。如果你做的是量产产品现在国产的GD32、APM32、CH32系列都有可以Pin-to-Pin兼容F103C8T6的型号代码改动量很小我后面讲到的HAL库代码换个芯片的Device选型重新编译基本能跑。不过新手学习的话STM32F103C8T6原版资料多、社区活跃作为第一块入门板仍然是最稳的选择。这篇文章的完整路线是这样先理清引脚接线再搭建CubeMX工程然后讲透BH1750的I2C寄存器操作最后搞定串口打印和常见坑排错。按照这个顺序走哪怕你之前没碰过I2C也能一个晚上跑通全部流程。2. 接线之前先想清楚的几件事引脚分配、上拉电阻、供电电压2.1 最小系统板的典型接线方案STM32F103C8T6最小系统板就是那种蓝色、黑色或者绿色的核心板最常用的I2C引脚有两组PB6/PB7对应I2C1PB10/PB11对应I2C2。跟BH1750连接的教科书式接法是这样的BH1750引脚连接目标说明VCC3.3V供电范围2.4V~3.6V务必不要接5VGNDGND共地SCLPB6I2C1_SCL时钟线SDAPB7I2C1_SDA数据线ADDRGND地址选择接GND时地址为0x23这里有个非常关键的细节BH1750的供电上限是3.6V接5V大概率会烧掉芯片。很多新手图省事直接接到开发板的5V引脚上芯片发烫、读数异常、甚至冒烟都是这么来的。一定要接3.3V。ADDR引脚决定I2C器件地址。接GND时7位地址是0x23接VCC时是0x5C。这是新手的第一个“隐坑”如果照抄网上代码没反应先检查ADDR接法对不对。一颗I2C总线上可以挂两个BH1750一个ADDR接高一个接低地址不冲突这是它的一个很方便的特性。2.2 上拉电阻不是“可选项”是“必选项”这是我要强调的重点。I2C总线是开漏结构SCL和SDA两条线必须在外部接上拉电阻到VCC才能正常工作。STM32F103C8T6最小系统板上虽然已经把I2C1引脚的上拉电阻焊好了一般是两个4.7K或10K但如果你自己飞线、用杜邦线连传感器模块线的长度和接触电阻会引入干扰这时板载的上拉可能不够稳定。更稳妥的操作在BH1750模块的SCL和SDA上分别并联一个4.7K电阻到3.3V。很多成品模块上已经带了这两个电阻接之前看一眼模块背面有没有丝印标注如果写了“R1 R2 4K7”之类的字样就不用再加。如果没有强烈建议焊上否则在杜邦线较长的情况下很容易出现“偶尔能读到、经常超时”的诡异问题。我实测过的一个场景用20cm杜邦线连接不加上拉读数据大概有30%的概率返回超时表现为程序卡死在等待应答的while循环里。加上拉电阻之后连续读1000次一次失败都没有。所以这步别偷懒。2.3 硬件I2C还是软件模拟I2C先给结论F103C8T6的硬件I2C外设在圈子里名声不太好很多人反映有“坑”事件标志位复杂、出错后容易卡死、要处理总线错误恢复。但其实这些坑大多是因为没有正确配置和处理好错误处理逻辑。作为新手我给你的建议是先从软件模拟I2C上手把时序原理跑通再尝试CubeMX生成的硬件I2C工程两套代码都能跑你对I2C的理解会深刻得多。本文后面会重点讲寄存器层面的操作然后用HAL库的硬件I2C来实现因为这是最主流的做法代码量也最少。硬件I2C的好处是CPU不用管时序细节读数据时等待中断或查询标志位即可适合系统里还有其他实时任务要处理的场景。缺点是出问题不好调试。软件模拟的好处是每个引脚都能当I2C用调起来直观不容易出现硬件外设死锁的问题缺点是占用CPU时间片。两条路我都走过第一阶段建议都试一遍后面做产品时根据实际需求选型。3. 从CubeMX到Keil搭建一个最小可用的工程环境3.1 CubeMX工程配置的完整参数用STM32CubeMX生成工程是目前最高效的方式。打开CubeMX芯片型号选择STM32F103C8Tx然后按下面参数配置SYS - Debug选Serial Wire这个必须开否则烧录一次后第二次就下载不了程序因为SWD引脚被占用了。RCC - HSE选Crystal/Ceramic Resonator用板载8M晶振做时钟源。Clock Configuration把HCLK设为72MHz让系统跑满速。CubeMX会自动计算分频系数一般默认就行。I2C1Mode选I2CBasic Parameters里速度模式选Standard Mode100KHz就行BH1750的最高I2C速率就是400KHz100KHz足够稳定和杜邦线搭配不容易出错。如果想跑到400KHzFast Mode建议先把板子上拉电阻确认好再试。USART1Mode选Asynchronous波特率1152008位数据、无校验、1位停止位这是最常用的调试串口配置。工程设置里Toolchain/IDE选MDK-ARM V5。这里解释一下为什么串口用USART1的PA9/PA10PA9是TX、PA10是RX和ST-Link或者其他USB转串口模块连接时很顺手而且和I2C引脚不冲突。如果你用的是国产开发板板载串口芯片可能已经接到了特定的USB转串口引脚那就以板子的原理图为准。3.2 固件库版本和编码细节CubeMX生成代码时会让你选择固件包版本。F1系列的HAL库我用过好几个版本1.8.0和1.8.1都比较稳定没有遇到过影响这个项目的bug。如果你电脑上有多个版本建议固定用同一个避免换个版本后API行为有细微差异。生成代码后在Keil里要确认两个地方C/C选项卡的Define里需要加上USE_HAL_DRIVER, STM32F103xB。CubeMX一般会自动加好但要养成检查的习惯我之前遇到过用户自己手动创建工程时漏了这个宏导致编译报一堆HAL库函数未定义的错误。Target选项卡的ARM Compiler选Version 5还是Version 6。V6编译器对代码规范性要求更高老工程直接拿过来编译容易报错新手建议先用AC5跑通后再考虑升级。工程生成后在main.c里就可以写业务代码了I2C和串口的初始化函数CubeMX已经帮你生成好了这比自己花半小时查寄存器配置靠谱太多。但千万不要以为CubeMX生成的初始化之后就不用管了还要检查一件事情确认HAL_I2C_MspInit里GPIO的配置默认是开漏输出Alternate Function Open-Drain。如果是推挽输出I2C时序会异常这一点CubeMX默认是对的但如果你手欠改过请注意改回来。3.3 printf重定向让串口输出浮点光照值串口要打印浮点数的光照强度需要重定向printf到串口。在usart.c末尾加一段代码#ifdef __GNUC__ #define PUTCHAR_PROTOTYPE int __io_putchar(int ch) #else #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f) #endif PUTCHAR_PROTOTYPE { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }在Keil AC5编译器下会走fputc分支问题不大。但如果编译报错“未定义 __stdout”需要在main.c里定义一个struct __FILE类型或者直接改用HAL_UART_Transmit自己封装一个发送函数不重定向printf也能做串口调试。我个人的习惯是如果只是调试直接用HAL_UART_Transmit发送字符串虽然麻烦点但省心。如果要格式化输出加浮点位再启用printf重定向。还得在Keil的Options里勾选Use MicroLIB否则浮点printf会占用大量Flash和RAMF103C8T6只有20KB RAM扛不住完整版C库的浮点格式化。4. 说透BH1750的寄存器与指令集单次测量模式的完整流程4.1 六个核心指令和测量模式BH1750没有传统意义上的寄存器地址它只接收1字节指令靠指令字本身完成操作。这点和大多数I2C传感器不一样刚开始接触会觉得怪但理解后会发现非常简洁。常用指令如下指令值二进制功能0000_00000x00关机进入待机0000_00010x01开机等待测量指令0000_01110x07重置清除测量结果0001_00000x10连续H分辨率模式1lx精度测量时间120ms0010_00000x20单次H分辨率模式测量后自动关机0001_00110x13连续L分辨率模式4lx精度测量时间16msH分辨率模式下分辨率是1 lxL分辨率模式下是4 lx。追求精度选H模式追求速度选L模式。还有H分辨率模式20x11和0x21分辨率是0.5 lx但最大量程会减半一般来说用不到。单次测量模式有个很贴心的设计测量完成后芯片自动进入关机状态省电。这一点在电池供电产品里非常实用。对应的还引出一个需要注意的问题单次测量模式必须在每次测量前重新发送一次开机指令否则芯片处于关机状态读数会一直失败或者读到旧数据。我见过不少人在循环里只发一次测量指令后面数据一直不变的情况排查半天发现自己压根没处理开机和测量的顺序问题。4.2 为什么推荐用单次H分辨率模式项目里我一般推荐单次H分辨率模式最主要原因是“功耗数据新鲜度”的平衡。连续模式适合需要实时监控、光照快速变化的场景比如户外气象站。但连续模式下芯片永远处于测量状态功耗相对高。而单次模式是“按需测量”想测了发指令等120ms读回来芯片进入关机。对于大多数IoT节点、智能设备来说每隔一段时间采一次光单次模式是更合理的选型。还有一个隐藏好处单次模式天然避免了“读到瞬态数据”的问题。连续模式如果恰好在光源切换瞬间读数可能采到突变值。单次模式每个周期重新开始测量数据更平均配合后级的软件滤波输出曲线会很平滑。4.3 上电后的标准操作序列BH1750在第一次使用时的标准流程是这样的上电后先发0x01开机指令让芯片退出上电默认状态。发0x07重置指令清掉可能残留的测量数据。延时几毫秒让芯片内部稳定。每次测量前发0x20单次H指令。等待测量完成至少120ms。稳妥起见我留200ms。读取2字节数据拼接成16位无符号数。用结果除以1.2得到单位为lx的光照强度。为什么除以1.2因为BH1750的H分辨率模式的转换因子是1.2单位lx/count这是数据手册明确给的数值。也就意味着寄存器原始值330对应约275lx。L分辨率模式转换因子是4.2H分辨率模式2的转换因子是0.6不同模式对应不同因子不能混用。5. 数据读取与换算16位原始数据是怎么变成光照值的5.1 完整可跑的HAL库代码下面这段代码是用HAL库硬件I2C驱动BH1750单次H模式的核心逻辑我做了详细注释。这段代码我实测在F103C8T6上连续运行一周没有异常#include main.h #include i2c.h #include usart.h #include stdio.h #define BH1750_ADDR (0x23 1) // ADDR接GND, 7位地址0x23, 左移1位变成8位地址 #define BH1750_POWER_ON 0x01 #define BH1750_RESET 0x07 #define BH1750_ONE_H 0x20 // 单次H分辨率模式 // 读取一次光照强度返回单位lx float BH1750_ReadLux(void) { uint8_t buf[2] {0}; uint16_t raw 0; uint8_t cmd 0; // 1. 开机 cmd BH1750_POWER_ON; HAL_I2C_Master_Transmit(hi2c1, BH1750_ADDR, cmd, 1, 100); // 2. 发单次H模式测量指令 cmd BH1750_ONE_H; HAL_I2C_Master_Transmit(hi2c1, BH1750_ADDR, cmd, 1, 100); // 3. 等待测量完成H模式典型120ms HAL_Delay(180); // 4. 读取2字节测量结果 HAL_I2C_Master_Receive(hi2c1, BH1750_ADDR, buf, 2, 100); // 5. 拼接原始数据高字节左移8位再或上低字节 raw (buf[0] 8) | buf[1]; // 6. 除以转换因子1.2得到光照值 return (float)raw / 1.2f; } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); MX_USART1_UART_Init(); float lux 0; printf(BH1750 Test Start\r\n); while (1) { lux BH1750_ReadLux(); printf(Light: %.1f lx\r\n, lux); HAL_Delay(1000); } }特别注意第1行地址的写法BH1750的7位地址是0x23但在HAL库的HAL_I2C_Master_Transmit里传入的地址参数是8位格式需要在7位地址基础上左移1位也就是0x23 1得到0x46。漏掉这一步是新手最常见的错误。一旦地址错I2C通信会一直NACK无应答。反过来如果你想用寄存器操作或者自己写软件模拟I2C发送地址时要先发0x468位写地址读数据时发0x478位读地址这个知识是通用的。5.2 测量等待时间的坑读太快会得到什么H分辨率模式的测量时间典型值是120ms最大值约180ms。这个参数在数据手册的“Measurement Time”表格里很多人忽略它。如果发送测量指令后立即去读数据会发生两种情况第一种读出全0。此时芯片还没完成测量数据寄存器里还是上电初始值。如果之前的测量值不为0读到的就是上次的旧值。这会导致数据显示“卡住”看起来像是传感器坏了其实是读得太早。第二种读到“半截数据”。I2C在读取过程中如果测量刚好完成可能读出混合数据高位是新数据、低位是旧数据数值看起来会有些跳变但不至于离谱。稳妥做法是延时200ms再读。有朋友会用HAL_I2C_Mem_Read直接读数据寄存器但BH1750没有寄存器地址的概念所以不能用Mem_Read要用Master_Receive直接收数据。这也是很多新手卡住的一个点明明照着别的传感器例程写Mem_Read结果一直报错。5.3 计算光照值的另一种思路查表法除以1.2得到的就是标准lx值这个公式适用于绝大多数场景。但在做极端高光照对比度环境时可以把原始值直接输出放大动态范围后再做算法处理。传感器数据的稳定性还可以通过软件滤波增强比如最简单的滑动平均维护一个长度为5的数组每次采样后求平均可以减少光源抖动带来的数值跳动。这个思路对新手理解“传感器数据后处理”很有帮助。6. 实测排错SDA死锁、全0xFF、数值跳动这三个经典故障6.1 故障一程序卡死在HAL_I2C_Master_Transmit里表现形式程序跑起来后卡在HAL_I2C_Master_Transmit这一行不往下走或者返回超时错误。排查优先级依次是查接线。SDA和SCL有没有接反杜邦线接触不良是头号嫌疑。用手轻轻拨动导线看现象会不会变化用万用表测一下通断最直接。查地址。ADDR引脚接的是GND还是VCC对应地址是0x23还是0x5C程序里用的哪个如果ADDR接VCC但程序里用了0x23芯片永远不会应答表现为发地址时收到NACK。查上电状态。芯片有没有先发开机指令单次模式下如果上电后直接发测量指令部分批次芯片可能不响应。先发0x01再发0x20。加上拉电阻。如果前面三样都没问题但还是超时90%的概率是上拉问题。先测SCL和SDA对地电压正常情况下空闲时都应该是3.3V。如果SDA被拉低到0V说明总线上有设备把它拉死了这就是典型的I2C死锁。I2C死锁怎么解锁把SCL的GPIO配置成普通推挽输出手动翻转9个时钟周期让卡在半途的从设备把状态机复位。也能直接断电重启但这治标不治本。如果频繁出现死锁优先怀疑是通信过程中被中断打断导致的时序错位需要在发送和接收时屏蔽中断或者做好HAL库的错误恢复回调。6.2 故障二读出来全是0xFF表现形式能读到数据但内容全是0xFF换算后光照值是5461.3lx——或者数值极大明显不合理。这个故障比卡死要隐蔽。PH1750输出0xFF通常意味着SDA线被拉低后没法正常释放从设备在传输位时输出了低电平但主机采样到高电平或者电阻上拉能力不足。更常见的原因MCU的I2C引脚没有被正确配置为开漏模式内部被拉成了推挽输出导致SDA在发送1时主动输出高电平和从设备拉低冲突读回来的数据全是乱的。解决方法是回到CubeMX里确认I2C1的GPIO配置SCL和SDA都必须是Output开漏模式Alternate Function Open-Drain内部上拉可以开也可以不开因为外部已经有上拉电阻了。改了配置之后重新生成代码再烧录。还有一种可能性模块本身的I2C地址冲突。如果总线上挂了两个BH1750且ADDR接法相同两个芯片会同时在SCL线上响应数据线上互相打架读出来就是乱码。用单个模块排查问题时先确保总线上只挂一个设备。6.3 故障三数值跳动大或者数据突然变零再恢复现象是光照值在稳定光源下波动超过10%或者每隔一段时间突然读出一个0然后又恢复正常。波动大的根因通常是环境本身LED照明有频闪市电频率的100Hz/120Hz波动打在传感器上人眼看不出来但传感器能采到。此时单次采样的瞬时值确实不准需要用滑动平均或者卡尔曼滤波平滑。我项目里简单粗暴地取5次平均效果就很好了。数据偶尔变零的原因有两个一是读取时序抢跑测量还没完成就去读了。二是I2C通信错误被HAL库返回超时但程序里没有处理返回值接收缓冲区可能是空的导致raw为0。所以代码里建议加一层判断if (HAL_I2C_Master_Receive(hi2c1, BH1750_ADDR, buf, 2, 100) ! HAL_OK) { return -1.0f; // 读取失败返回负值外部逻辑识别并做重试 }-1.0f作为错误标志在调用层遇到负数就跳过本次刷新继续用上一次的有效值。这种“无效数据不刷新”的策略在很多传感器场景里都适用比一读到0就当成真实光照值传给业务逻辑要可靠得多。7. 从开发板到产品这套驱动还能怎么延伸跑通BH1750之后这套I2C驱动经验可以直接迁移到很多其他传感器上SHT30温湿度、MPU6050陀螺仪、AT24C02存储器、OLED屏幕SSD1306它们的I2C操作本质完全一致——无非是按照芯片手册里的寄存器地址和指令字来读写。你花一晚上学会BH1750其实是用一个最小但完整的案例摸清了整个I2C设备驱动的思维模型。如果后面要做的项目对功耗有要求可以把MCU和BH1750都接入低功耗模式每10秒唤醒一次发测量指令等180ms读数据打印/上报再睡回去。这样一节CR2032纽扣电池可以撑几个月。想提升测量精度可以在传感器前面加一层扩散片比如半透明的亚克力让入射光更均匀。虽然BH1750本身已经做了余弦修正但在某些大角度入射场景下扩散片能明显改善测量一致性。最后提一下“江科大”风格的寄存器版本代码。很多人在B站学过江协科技江科大的STM32课程那套代码风格是标准库寄存器直接操作。BH1750的软件模拟I2C驱动网上流传版本很多核心逻辑无非就是把SCL/SDA置高置低、时钟翻转、数据采样这些基础操作按I2C协议拼出来。我建议你在跑通HAL库版本之后找个晚上对照时序图自己写一遍软件模拟I2C写到能成功读出亮度的程度你对I2C时序的理解会上一个台阶。硬件I2C帮你避开了时序细节但想真正具备调试能力还是得能在示波器或逻辑分析仪上看出时序对不对。先把这篇文章里的HAL库版本跑通遇到问题回头对照第6节的排查清单。这条路我走过值得走。 
长河君 · 2026/9/24 12:18:39 · 阅读 1.2k STM32驱动BH1750光照传感器：I2C接线、HAL库代码与排错实战
1. 为什么是BH1750这块传感器的脾气和本事做STM32嵌入式项目的人迟早会遇到“测光照”这个需求——可能是智能家居里的窗帘自动开合可能是大棚补光灯的自动控制也有可能是产品做亮暗自适应屏幕。方案无非三种光敏电阻、光敏二极管、数字光照传感器。我早期贪便宜用过光敏电阻被温漂和校准问题折磨得够呛同一光照下冬天和夏天的ADC读数能差出一大截换个批次又得重新标定。后来换到BH1750才算真正省心。BH1750是罗姆ROHM出品的环境光强度数字传感器I2C接口16位ADC输出量程1到65535 lx测量结果直接以数字量输出不需要自己做ADC换算和线性校准。它的核心价值在于“人眼感知近似”——光谱响应经过专门设计和视觉灵敏度的曲线匹配度比光敏电阻高得多所以做出来的产品行为更符合人的直觉。这颗芯片的功耗也低待机时微安级别非常适合电池供电的项目。另外它不需要外部校准出厂前已经调好这在量产阶段能省一大笔生产测试工时。你不需要额外搭运放电路也不需要做光照传感器的手动校准几颗电阻电容就能让它稳定工作这是它能在创客圈和工业项目里都用得开的核心原因。选STM32F103C8T6来带它是性价比最优解。这颗芯片目前市场价相当便宜某宝上十几块钱能买一片Cortex-M3内核72MHz主频有硬件I2C外设64KB Flash、20KB SRAM做光照采集这种轻量级任务绰绰有余。更关键的是F1系列的资料极其丰富不管是寄存器开发还是标准库、HAL库踩坑解法一搜一大把非常适合新手练手和快速出原型。顺便说一句“国产替代”这个词最近在STM32圈子里特别热。如果你做的是量产产品现在国产的GD32、APM32、CH32系列都有可以Pin-to-Pin兼容F103C8T6的型号代码改动量很小我后面讲到的HAL库代码换个芯片的Device选型重新编译基本能跑。不过新手学习的话STM32F103C8T6原版资料多、社区活跃作为第一块入门板仍然是最稳的选择。这篇文章的完整路线是这样先理清引脚接线再搭建CubeMX工程然后讲透BH1750的I2C寄存器操作最后搞定串口打印和常见坑排错。按照这个顺序走哪怕你之前没碰过I2C也能一个晚上跑通全部流程。2. 接线之前先想清楚的几件事引脚分配、上拉电阻、供电电压2.1 最小系统板的典型接线方案STM32F103C8T6最小系统板就是那种蓝色、黑色或者绿色的核心板最常用的I2C引脚有两组PB6/PB7对应I2C1PB10/PB11对应I2C2。跟BH1750连接的教科书式接法是这样的BH1750引脚连接目标说明VCC3.3V供电范围2.4V~3.6V务必不要接5VGNDGND共地SCLPB6I2C1_SCL时钟线SDAPB7I2C1_SDA数据线ADDRGND地址选择接GND时地址为0x23这里有个非常关键的细节BH1750的供电上限是3.6V接5V大概率会烧掉芯片。很多新手图省事直接接到开发板的5V引脚上芯片发烫、读数异常、甚至冒烟都是这么来的。一定要接3.3V。ADDR引脚决定I2C器件地址。接GND时7位地址是0x23接VCC时是0x5C。这是新手的第一个“隐坑”如果照抄网上代码没反应先检查ADDR接法对不对。一颗I2C总线上可以挂两个BH1750一个ADDR接高一个接低地址不冲突这是它的一个很方便的特性。2.2 上拉电阻不是“可选项”是“必选项”这是我要强调的重点。I2C总线是开漏结构SCL和SDA两条线必须在外部接上拉电阻到VCC才能正常工作。STM32F103C8T6最小系统板上虽然已经把I2C1引脚的上拉电阻焊好了一般是两个4.7K或10K但如果你自己飞线、用杜邦线连传感器模块线的长度和接触电阻会引入干扰这时板载的上拉可能不够稳定。更稳妥的操作在BH1750模块的SCL和SDA上分别并联一个4.7K电阻到3.3V。很多成品模块上已经带了这两个电阻接之前看一眼模块背面有没有丝印标注如果写了“R1 R2 4K7”之类的字样就不用再加。如果没有强烈建议焊上否则在杜邦线较长的情况下很容易出现“偶尔能读到、经常超时”的诡异问题。我实测过的一个场景用20cm杜邦线连接不加上拉读数据大概有30%的概率返回超时表现为程序卡死在等待应答的while循环里。加上拉电阻之后连续读1000次一次失败都没有。所以这步别偷懒。2.3 硬件I2C还是软件模拟I2C先给结论F103C8T6的硬件I2C外设在圈子里名声不太好很多人反映有“坑”事件标志位复杂、出错后容易卡死、要处理总线错误恢复。但其实这些坑大多是因为没有正确配置和处理好错误处理逻辑。作为新手我给你的建议是先从软件模拟I2C上手把时序原理跑通再尝试CubeMX生成的硬件I2C工程两套代码都能跑你对I2C的理解会深刻得多。本文后面会重点讲寄存器层面的操作然后用HAL库的硬件I2C来实现因为这是最主流的做法代码量也最少。硬件I2C的好处是CPU不用管时序细节读数据时等待中断或查询标志位即可适合系统里还有其他实时任务要处理的场景。缺点是出问题不好调试。软件模拟的好处是每个引脚都能当I2C用调起来直观不容易出现硬件外设死锁的问题缺点是占用CPU时间片。两条路我都走过第一阶段建议都试一遍后面做产品时根据实际需求选型。3. 从CubeMX到Keil搭建一个最小可用的工程环境3.1 CubeMX工程配置的完整参数用STM32CubeMX生成工程是目前最高效的方式。打开CubeMX芯片型号选择STM32F103C8Tx然后按下面参数配置SYS - Debug选Serial Wire这个必须开否则烧录一次后第二次就下载不了程序因为SWD引脚被占用了。RCC - HSE选Crystal/Ceramic Resonator用板载8M晶振做时钟源。Clock Configuration把HCLK设为72MHz让系统跑满速。CubeMX会自动计算分频系数一般默认就行。I2C1Mode选I2CBasic Parameters里速度模式选Standard Mode100KHz就行BH1750的最高I2C速率就是400KHz100KHz足够稳定和杜邦线搭配不容易出错。如果想跑到400KHzFast Mode建议先把板子上拉电阻确认好再试。USART1Mode选Asynchronous波特率1152008位数据、无校验、1位停止位这是最常用的调试串口配置。工程设置里Toolchain/IDE选MDK-ARM V5。这里解释一下为什么串口用USART1的PA9/PA10PA9是TX、PA10是RX和ST-Link或者其他USB转串口模块连接时很顺手而且和I2C引脚不冲突。如果你用的是国产开发板板载串口芯片可能已经接到了特定的USB转串口引脚那就以板子的原理图为准。3.2 固件库版本和编码细节CubeMX生成代码时会让你选择固件包版本。F1系列的HAL库我用过好几个版本1.8.0和1.8.1都比较稳定没有遇到过影响这个项目的bug。如果你电脑上有多个版本建议固定用同一个避免换个版本后API行为有细微差异。生成代码后在Keil里要确认两个地方C/C选项卡的Define里需要加上USE_HAL_DRIVER, STM32F103xB。CubeMX一般会自动加好但要养成检查的习惯我之前遇到过用户自己手动创建工程时漏了这个宏导致编译报一堆HAL库函数未定义的错误。Target选项卡的ARM Compiler选Version 5还是Version 6。V6编译器对代码规范性要求更高老工程直接拿过来编译容易报错新手建议先用AC5跑通后再考虑升级。工程生成后在main.c里就可以写业务代码了I2C和串口的初始化函数CubeMX已经帮你生成好了这比自己花半小时查寄存器配置靠谱太多。但千万不要以为CubeMX生成的初始化之后就不用管了还要检查一件事情确认HAL_I2C_MspInit里GPIO的配置默认是开漏输出Alternate Function Open-Drain。如果是推挽输出I2C时序会异常这一点CubeMX默认是对的但如果你手欠改过请注意改回来。3.3 printf重定向让串口输出浮点光照值串口要打印浮点数的光照强度需要重定向printf到串口。在usart.c末尾加一段代码#ifdef __GNUC__ #define PUTCHAR_PROTOTYPE int __io_putchar(int ch) #else #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f) #endif PUTCHAR_PROTOTYPE { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }在Keil AC5编译器下会走fputc分支问题不大。但如果编译报错“未定义 __stdout”需要在main.c里定义一个struct __FILE类型或者直接改用HAL_UART_Transmit自己封装一个发送函数不重定向printf也能做串口调试。我个人的习惯是如果只是调试直接用HAL_UART_Transmit发送字符串虽然麻烦点但省心。如果要格式化输出加浮点位再启用printf重定向。还得在Keil的Options里勾选Use MicroLIB否则浮点printf会占用大量Flash和RAMF103C8T6只有20KB RAM扛不住完整版C库的浮点格式化。4. 说透BH1750的寄存器与指令集单次测量模式的完整流程4.1 六个核心指令和测量模式BH1750没有传统意义上的寄存器地址它只接收1字节指令靠指令字本身完成操作。这点和大多数I2C传感器不一样刚开始接触会觉得怪但理解后会发现非常简洁。常用指令如下指令值二进制功能0000_00000x00关机进入待机0000_00010x01开机等待测量指令0000_01110x07重置清除测量结果0001_00000x10连续H分辨率模式1lx精度测量时间120ms0010_00000x20单次H分辨率模式测量后自动关机0001_00110x13连续L分辨率模式4lx精度测量时间16msH分辨率模式下分辨率是1 lxL分辨率模式下是4 lx。追求精度选H模式追求速度选L模式。还有H分辨率模式20x11和0x21分辨率是0.5 lx但最大量程会减半一般来说用不到。单次测量模式有个很贴心的设计测量完成后芯片自动进入关机状态省电。这一点在电池供电产品里非常实用。对应的还引出一个需要注意的问题单次测量模式必须在每次测量前重新发送一次开机指令否则芯片处于关机状态读数会一直失败或者读到旧数据。我见过不少人在循环里只发一次测量指令后面数据一直不变的情况排查半天发现自己压根没处理开机和测量的顺序问题。4.2 为什么推荐用单次H分辨率模式项目里我一般推荐单次H分辨率模式最主要原因是“功耗数据新鲜度”的平衡。连续模式适合需要实时监控、光照快速变化的场景比如户外气象站。但连续模式下芯片永远处于测量状态功耗相对高。而单次模式是“按需测量”想测了发指令等120ms读回来芯片进入关机。对于大多数IoT节点、智能设备来说每隔一段时间采一次光单次模式是更合理的选型。还有一个隐藏好处单次模式天然避免了“读到瞬态数据”的问题。连续模式如果恰好在光源切换瞬间读数可能采到突变值。单次模式每个周期重新开始测量数据更平均配合后级的软件滤波输出曲线会很平滑。4.3 上电后的标准操作序列BH1750在第一次使用时的标准流程是这样的上电后先发0x01开机指令让芯片退出上电默认状态。发0x07重置指令清掉可能残留的测量数据。延时几毫秒让芯片内部稳定。每次测量前发0x20单次H指令。等待测量完成至少120ms。稳妥起见我留200ms。读取2字节数据拼接成16位无符号数。用结果除以1.2得到单位为lx的光照强度。为什么除以1.2因为BH1750的H分辨率模式的转换因子是1.2单位lx/count这是数据手册明确给的数值。也就意味着寄存器原始值330对应约275lx。L分辨率模式转换因子是4.2H分辨率模式2的转换因子是0.6不同模式对应不同因子不能混用。5. 数据读取与换算16位原始数据是怎么变成光照值的5.1 完整可跑的HAL库代码下面这段代码是用HAL库硬件I2C驱动BH1750单次H模式的核心逻辑我做了详细注释。这段代码我实测在F103C8T6上连续运行一周没有异常#include main.h #include i2c.h #include usart.h #include stdio.h #define BH1750_ADDR (0x23 1) // ADDR接GND, 7位地址0x23, 左移1位变成8位地址 #define BH1750_POWER_ON 0x01 #define BH1750_RESET 0x07 #define BH1750_ONE_H 0x20 // 单次H分辨率模式 // 读取一次光照强度返回单位lx float BH1750_ReadLux(void) { uint8_t buf[2] {0}; uint16_t raw 0; uint8_t cmd 0; // 1. 开机 cmd BH1750_POWER_ON; HAL_I2C_Master_Transmit(hi2c1, BH1750_ADDR, cmd, 1, 100); // 2. 发单次H模式测量指令 cmd BH1750_ONE_H; HAL_I2C_Master_Transmit(hi2c1, BH1750_ADDR, cmd, 1, 100); // 3. 等待测量完成H模式典型120ms HAL_Delay(180); // 4. 读取2字节测量结果 HAL_I2C_Master_Receive(hi2c1, BH1750_ADDR, buf, 2, 100); // 5. 拼接原始数据高字节左移8位再或上低字节 raw (buf[0] 8) | buf[1]; // 6. 除以转换因子1.2得到光照值 return (float)raw / 1.2f; } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); MX_USART1_UART_Init(); float lux 0; printf(BH1750 Test Start\r\n); while (1) { lux BH1750_ReadLux(); printf(Light: %.1f lx\r\n, lux); HAL_Delay(1000); } }特别注意第1行地址的写法BH1750的7位地址是0x23但在HAL库的HAL_I2C_Master_Transmit里传入的地址参数是8位格式需要在7位地址基础上左移1位也就是0x23 1得到0x46。漏掉这一步是新手最常见的错误。一旦地址错I2C通信会一直NACK无应答。反过来如果你想用寄存器操作或者自己写软件模拟I2C发送地址时要先发0x468位写地址读数据时发0x478位读地址这个知识是通用的。5.2 测量等待时间的坑读太快会得到什么H分辨率模式的测量时间典型值是120ms最大值约180ms。这个参数在数据手册的“Measurement Time”表格里很多人忽略它。如果发送测量指令后立即去读数据会发生两种情况第一种读出全0。此时芯片还没完成测量数据寄存器里还是上电初始值。如果之前的测量值不为0读到的就是上次的旧值。这会导致数据显示“卡住”看起来像是传感器坏了其实是读得太早。第二种读到“半截数据”。I2C在读取过程中如果测量刚好完成可能读出混合数据高位是新数据、低位是旧数据数值看起来会有些跳变但不至于离谱。稳妥做法是延时200ms再读。有朋友会用HAL_I2C_Mem_Read直接读数据寄存器但BH1750没有寄存器地址的概念所以不能用Mem_Read要用Master_Receive直接收数据。这也是很多新手卡住的一个点明明照着别的传感器例程写Mem_Read结果一直报错。5.3 计算光照值的另一种思路查表法除以1.2得到的就是标准lx值这个公式适用于绝大多数场景。但在做极端高光照对比度环境时可以把原始值直接输出放大动态范围后再做算法处理。传感器数据的稳定性还可以通过软件滤波增强比如最简单的滑动平均维护一个长度为5的数组每次采样后求平均可以减少光源抖动带来的数值跳动。这个思路对新手理解“传感器数据后处理”很有帮助。6. 实测排错SDA死锁、全0xFF、数值跳动这三个经典故障6.1 故障一程序卡死在HAL_I2C_Master_Transmit里表现形式程序跑起来后卡在HAL_I2C_Master_Transmit这一行不往下走或者返回超时错误。排查优先级依次是查接线。SDA和SCL有没有接反杜邦线接触不良是头号嫌疑。用手轻轻拨动导线看现象会不会变化用万用表测一下通断最直接。查地址。ADDR引脚接的是GND还是VCC对应地址是0x23还是0x5C程序里用的哪个如果ADDR接VCC但程序里用了0x23芯片永远不会应答表现为发地址时收到NACK。查上电状态。芯片有没有先发开机指令单次模式下如果上电后直接发测量指令部分批次芯片可能不响应。先发0x01再发0x20。加上拉电阻。如果前面三样都没问题但还是超时90%的概率是上拉问题。先测SCL和SDA对地电压正常情况下空闲时都应该是3.3V。如果SDA被拉低到0V说明总线上有设备把它拉死了这就是典型的I2C死锁。I2C死锁怎么解锁把SCL的GPIO配置成普通推挽输出手动翻转9个时钟周期让卡在半途的从设备把状态机复位。也能直接断电重启但这治标不治本。如果频繁出现死锁优先怀疑是通信过程中被中断打断导致的时序错位需要在发送和接收时屏蔽中断或者做好HAL库的错误恢复回调。6.2 故障二读出来全是0xFF表现形式能读到数据但内容全是0xFF换算后光照值是5461.3lx——或者数值极大明显不合理。这个故障比卡死要隐蔽。PH1750输出0xFF通常意味着SDA线被拉低后没法正常释放从设备在传输位时输出了低电平但主机采样到高电平或者电阻上拉能力不足。更常见的原因MCU的I2C引脚没有被正确配置为开漏模式内部被拉成了推挽输出导致SDA在发送1时主动输出高电平和从设备拉低冲突读回来的数据全是乱的。解决方法是回到CubeMX里确认I2C1的GPIO配置SCL和SDA都必须是Output开漏模式Alternate Function Open-Drain内部上拉可以开也可以不开因为外部已经有上拉电阻了。改了配置之后重新生成代码再烧录。还有一种可能性模块本身的I2C地址冲突。如果总线上挂了两个BH1750且ADDR接法相同两个芯片会同时在SCL线上响应数据线上互相打架读出来就是乱码。用单个模块排查问题时先确保总线上只挂一个设备。6.3 故障三数值跳动大或者数据突然变零再恢复现象是光照值在稳定光源下波动超过10%或者每隔一段时间突然读出一个0然后又恢复正常。波动大的根因通常是环境本身LED照明有频闪市电频率的100Hz/120Hz波动打在传感器上人眼看不出来但传感器能采到。此时单次采样的瞬时值确实不准需要用滑动平均或者卡尔曼滤波平滑。我项目里简单粗暴地取5次平均效果就很好了。数据偶尔变零的原因有两个一是读取时序抢跑测量还没完成就去读了。二是I2C通信错误被HAL库返回超时但程序里没有处理返回值接收缓冲区可能是空的导致raw为0。所以代码里建议加一层判断if (HAL_I2C_Master_Receive(hi2c1, BH1750_ADDR, buf, 2, 100) ! HAL_OK) { return -1.0f; // 读取失败返回负值外部逻辑识别并做重试 }-1.0f作为错误标志在调用层遇到负数就跳过本次刷新继续用上一次的有效值。这种“无效数据不刷新”的策略在很多传感器场景里都适用比一读到0就当成真实光照值传给业务逻辑要可靠得多。7. 从开发板到产品这套驱动还能怎么延伸跑通BH1750之后这套I2C驱动经验可以直接迁移到很多其他传感器上SHT30温湿度、MPU6050陀螺仪、AT24C02存储器、OLED屏幕SSD1306它们的I2C操作本质完全一致——无非是按照芯片手册里的寄存器地址和指令字来读写。你花一晚上学会BH1750其实是用一个最小但完整的案例摸清了整个I2C设备驱动的思维模型。如果后面要做的项目对功耗有要求可以把MCU和BH1750都接入低功耗模式每10秒唤醒一次发测量指令等180ms读数据打印/上报再睡回去。这样一节CR2032纽扣电池可以撑几个月。想提升测量精度可以在传感器前面加一层扩散片比如半透明的亚克力让入射光更均匀。虽然BH1750本身已经做了余弦修正但在某些大角度入射场景下扩散片能明显改善测量一致性。最后提一下“江科大”风格的寄存器版本代码。很多人在B站学过江协科技江科大的STM32课程那套代码风格是标准库寄存器直接操作。BH1750的软件模拟I2C驱动网上流传版本很多核心逻辑无非就是把SCL/SDA置高置低、时钟翻转、数据采样这些基础操作按I2C协议拼出来。我建议你在跑通HAL库版本之后找个晚上对照时序图自己写一遍软件模拟I2C写到能成功读出亮度的程度你对I2C时序的理解会上一个台阶。硬件I2C帮你避开了时序细节但想真正具备调试能力还是得能在示波器或逻辑分析仪上看出时序对不对。先把这篇文章里的HAL库版本跑通遇到问题回头对照第6节的排查清单。这条路我走过值得走。