简介：面向STM32开发者的BMP180气压与温度传感器驱动资源，解决在嵌入式项目中快速接入BMP180并稳定读取环境数据的问题。包内提供软件IIC与硬件IIC两套驱动方案：软件IIC通过GPIO模拟时序，灵活适配任意引脚；硬件IIC利用STM32内置外设，通信效率更高、CPU占用更少。驱动代码已由作者实测验证，覆盖传感器校准、压力和温度读取等关键流程，并附带头文件、实现文件、主程序、工程配置文件、编译产物及PDF说明，共222个文件，压缩包8.05MB。文件类型包括.c/.h源码、.o/.axf编译中间文件、.hex烧录文件、.uvprojx工程文件等，便于直接参考或集成到自己的工程。已有908人学习下载，适合需要I2C驱动范例、从事气象观测、导航或物联网终端开发的STM32初中级用户，可作为软硬件联调与代码移植的有用参考。
1. 为什么BMP180驱动值得自己写：一次翻车之后
刚接触STM32气象站项目时，我第一反应是从网上找一份现成的BMP180驱动代码。结果连换三个版本，要么读出的温度值在25℃和-40℃之间乱跳，要么气压值比当地气象站差了十几个hPa。最后我放弃了“拿来主义”，翻出数据手册，从I2C时序开始一行一行重写，半天时间就把问题定位清楚：不是传感器坏了，而是驱动里校准参数的符号位没处理，加上EOC等待逻辑写反了。BMP180作为经典的气压温度传感器，模块便宜的只要几块钱，寄存器少、协议简单，很适合自己把驱动完整写一遍。这份资源适合正在做气压计、高度计、无人机定高或者气象数据采集的开发者，尤其是想在STM32上吃透I2C通信和传感器校准流程的人。
2. 先啃寄存器：BMP180的I2C通信与五个关键寄存器操作
2.1 从芯片地址到寄存器映射：BMP180的I2C协议骨架
BMP180挂在I2C总线上时，7位设备地址固定为0x77，写操作时地址字节是0xEE，读操作时是0xEF。很多第一次写驱动的开发者会在这上面踩坑：ST的库函数里I2C发送地址时，需要的是7位地址左移一位后的完整字节。直接拿0x77去发，总线上看到的地址就是0xEE，恰好能对应上写操作，但读操作就会对不上。
整个芯片对外暴露的寄存器不多，真正天天打交道的就下面这一组。
| 寄存器地址 | 名称 | 作用 | 关键位说明 |
|---|---|---|---|
| 0xF4 | 控制寄存器 | 发起测量 | bit7-bit5写测量模式（温度/气压），bit0是EOC状态 |
| 0xF6 | 数据寄存器MSB | 测量结果高字节 | 与LSB、XLSB拼成19位原始数据 |
| 0xF7 | 数据寄存器LSB | 测量结果中间字节 | 与MSB组成高16位 |
| 0xF8 | 数据寄存器XLSB | 测量结果低字节 | 只有高3位有效，对应低精度的3位 |
| 0xAA~0xBF | 校准寄存器区 | 存放出厂校准参数 | 共11个参数，AC1到MD，分布在这22个字节里 |
理解这五个寄存器，驱动就已经完成了一半。0xF4是发起测量和查询状态的入口，0xF6到0xF8装的是测量出来的原始值，而0xAA到0xBF里存的是芯片出厂时烧录的校准系数。BMP180和很多气压传感器不太一样的一点是，它出厂时不直接给校准后的物理量，只给原始ADC值和一组校准参数，真正的温度和气压需要你在代码里手动算出来。这也是这份驱动资源的核心价值所在。
2.2 硬件I2C和软件模拟I2C怎么选：稳定性与代码量的权衡
写BMP180驱动之前，先得定通信方式。STM32的I2C外设常被吐槽“不稳定”，我早年就被默认的I2C超时问题坑过，后来干脆用GPIO模拟I2C，代码虽然多了十几行，但每个时序都是自己控制的，出问题好排查。常见的做法是直接操作寄存器开漏输出，配合上拉电阻，按数据手册的时序翻转SCL和SDA。
那么什么时候选硬件I2C？项目里如果使用RTOS，任务多、中断多，模拟I2C容易被高优先级中断打断时序，导致传感器偶发读错。硬件I2C有硬件移位寄存器兜底，扛干扰能力强。反过来，底层裸机跑循环，GPIO模拟I2C反而更直观，排查问题只要看波形就能定位。
BMP180的I2C时钟频率最大支持3.4MHz，但实际工程我一般压在400kHz以内，甚至很多例程直接跑100kHz。气压传感器对读取频率要求不高，每秒读一次都算高频，所以低速反而更稳。散热和电磁环境复杂的板子，我习惯把I2C速率降到100kHz，牺牲一点点读取速度，换来的是长时间运行不丢数据。这是我在某图像处理Demo上反复测试得到的结论。
3. 驱动代码怎么写：初始化、测量触发与原始数据读取实战
3.1 初始化：连接I2C总线、读取出厂校准参数
拿到一份BMP180驱动代码，我习惯先看它的初始化流程。合格的初始化里，至少包含三步：I2C总线初始化、检测设备是否存在、读取11个校准参数并保存到全局结构体。第一次上电时，芯片内部的校准寄存器是立即可读的，不需要等待任何触发命令。这里我一般会加一个I2C探测函数，读到设备地址0x77的应答才算初始化成功。
下面是一份精简但完整的BMP180初始化代码，是我在模拟项目X上调试时最常用的版本。
typedef struct { int16_t AC1, AC2, AC3, B1, B2, MB, MC, MD; uint16_t AC4, AC5, AC6; int32_t UT, UP; int32_t B5; } BMP180_Handle_t; BMP180_Handle_t bmp180; uint8_t BMP180_Init(void) { uint8_t rx_data[22]; uint8_t i; // 前面先做I2C总线初始化，跟具体芯片无关 // 探测设备：往0x77发地址，等待应答 if (I2C_CheckDevice(0x77) != 0) { return 1; // 设备不存在 } // 连续读取22个字节的校准寄存器，地址从0xAA开始 if (I2C_ReadBuffer(0xAA, rx_data, 22) != 0) { return 2; // 读取失败 } // 按数据手册规定的顺序，把字节拼成有符号/无符号整数 bmp180.AC1 = (int16_t)((rx_data[0] << 8) | rx_data[1]); bmp180.AC2 = (int16_t)((rx_data[2] << 8) | rx_data[3]); bmp180.AC3 = (int16_t)((rx_data[4] << 8) | rx_data[5]); bmp180.AC4 = (uint16_t)((rx_data[6] << 8) | rx_data[7]); bmp180.AC5 = (uint16_t)((rx_data[8] << 8) | rx_data[9]); bmp180.AC6 = (uint16_t)((rx_data[10] << 8) | rx_data[11]); bmp180.B1 = (int16_t)((rx_data[12] << 8) | rx_data[13]); bmp180.B2 = (int16_t)((rx_data[14] << 8) | rx_data[15]); bmp180.MB = (int16_t)((rx_data[16] << 8) | rx_data[17]); bmp180.MC = (int16_t)((rx_data[18] << 8) | rx_data[19]); bmp180.MD = (int16_t)((rx_data[20] << 8) | rx_data[21]); return 0; // 初始化完成 }读校准参数时最容易犯的错，是把AC1、AC2这类参数一律当作无符号数来用。数据手册里明确标了AC1、AC2、AC3、B1、B2、MB、MC、MD是int16_t类型，AC4、AC5、AC6才是uint16_t。如果全部按uint16_t读，温度补偿计算出来的值就会明显偏高，而且温度越高，偏差越大。代码里特意把拼接结果强转成对应的类型，就是为这一步留一道保险。
I2C_ReadBuffer是我封装的一个底层函数，传参是寄存器起始地址、接收缓冲区指针和长度。BMP180支持连续读，所以22个校准参数只用一次连续读操作就能全部取回，不需要逐个寄存器发地址，省时间也省代码。
3.2 触发测量与读取原始数据：控制时序与EOC轮询
初始化完成后，每次测量要分三步走：写入测量命令、等待转换结束、读取三字节原始数据。BMP180的命令写在0xF4寄存器里，温度测量固定写0x2E，气压测量写0x34加上模式位。气压模式OSS有0到3四档，OSS每增加一档，采样时间翻倍，但分辨率也从0.06hPa提升到0.03hPa左右。
这里先看触发温度测量和读回原始值的代码。
uint8_t BMP180_ReadTemp(int32_t *temp_raw) { uint8_t reg = 0xF4; uint8_t cmd = 0x2E; // 温度测量命令 uint8_t data[3]; uint16_t timeout = 1000; // 写入测量命令 I2C_WriteByte(reg, cmd); // 等待EOC位置1，0xF4的bit0表示转换完成 while (timeout--) { I2C_ReadByte(0xF4, ®); if (reg & 0x01) { break; } delay_ms(1); } if (timeout == 0) return 1; // 超时 // 读取0xF6、0xF7、0xF8三个字节的原始数据 I2C_ReadBuffer(0xF6, data, 3); // 拼成19位无符号原始值，右移3位去掉低位的XLSB *temp_raw = (int32_t)((data[0] << 16) | (data[1] << 8) | data[2]) >> 3; return 0; }EOC等待是整个驱动里最需要仔细品味的地方。0xF4寄存器的bit0是转换完成标志位，转换过程中是0，转换完成会自动变成1。代码里轮询时读取的是同一个控制寄存器，而不是数据寄存器，这一点很多简化版驱动会写错。我见过有人用读0xF6来判断是否转换完成，结果读到的是上一次的旧数据，温度值看起来没变化，其实传感器早就休眠了。
EOC置位之后，数据寄存器里的内容才是本次测量的结果。三字节数据中，0xF8的XLSB其实只有高3位有效，所以拼成32位整数后再右移3位，才能得到标准的19位数据。温度原始值UT的精度是0.1℃，气压原始值UP配合OSS模式，最低能表示到0.03hPa。右移操作放在读取时做还是放在补偿计算时做，结果一样，但提前右移能让后续计算函数更直观。
气压测量的触发代码几乎和温度一样，唯一的区别是命令值需要加上OSS模式参数。
uint8_t BMP180_ReadPressure(int32_t *pressure_raw, uint8_t oss) { uint8_t reg = 0xF4; uint8_t data[3]; uint16_t timeout = 3000; if (oss > 3) oss = 3; // 模式越界时按0处理会出错，这里直接钳位 // 气压测量命令 = 0x34 + (oss << 6)，注意是左移6位 I2C_WriteByte(reg, (uint8_t)(0x34 + (oss << 6))); while (timeout--) { I2C_ReadByte(0xF4, ®); if (reg & 0x01) { break; } delay_ms(1); } if (timeout == 0) return 1; I2C_ReadBuffer(0xF6, data, 3); // OSS不为0时，XLSB的低位也是有效数据，变化只在右移位数上 *pressure_raw = (int32_t)((data[0] << 16) | (data[1] << 8) | data[2]) >> (8 - oss); return 0; }OSS模式和右移次数的对应关系，是气压读取最容易翻车的地方。OSS=0时，最终原始值就等于19位数据右移3位；OSS=1时，右移4位；OSS=2时，右移5位；OSS=3时，右移6位。写成公式就是8-oss，正好对应上面代码里的逻辑。有些驱动一上来就固定右移3位，OSS调成1或2时气压值就会整体偏差，换算成高度差能差出十几米。之所以强调这一点，是因为BMP180的大多数应用场景是测高度，高度对气压极其敏感，海平面气压差1hPa，高度就差大约8.4米。
4. 避坑记录：EOC等待、校准参数类型与I2C死锁的4条血泪经验
4.1 现象一：EOC位读不到转换完成，程序卡死在轮询里
这大概是我见过最多的运行故障。现象是程序跑起来后，第一次测量就卡住，断点打在EOC等待循环里出不来，读0xF4的返回值一直是0x00。
排查后发现两个原因叠加。第一次是我的轮询间隔太密，没有加任何延时，I2C读操作本身就消耗时间，但读到的寄存器值还没准备好，EOC位就一直读不到1。第二次是板子上I2C上拉电阻被误焊成了10k的大阻值，总线时间常数变大，高速读的时候经常读回垃圾数据。
解决方法是轮询循环里加延时，我一般用1ms的间隔，超时时间拉到500ms以上。BMP180最快的一次气压转换也要4.5ms，1ms间隔足够保证不错过EOC置位瞬间。总线上下拉电阻改成4.7k之后，问题彻底消失。如果你用的是模块而不是裸芯片，模块上一般已经自带电阻，但也要确认上拉是接到VCC而不是接到了某些开发板的IO上。
4.2 现象二：温度读数跳变、气压偏差超过几个hPa
温度值在25℃附近来回跳，或者气压比气象站报的偏低好几个hPa，这种问题优先怀疑校准参数的符号处理。用某开发板调试时，我发现读回的温度在27℃和-18℃之间交替出现，一开始以为是传感器坏了，换了一个新的还是同样的现象。
最后翻数据手册，对照寄存器定义逐字节检查，发现AC2读回来后最高位是1，按无符号数算就成了一个很大的正数，代入补偿公式后温度被强行拉偏。我一开始想复杂了，以为罕见工况校验问题，起了个外号叫“玄学跳变”，其实原因一点都不玄，就是C语言里unsigned和signed的锅。
解决方式很干脆：校准参数里所有带符号的参数全部声明为int16_t，读取时先拼成uint16_t，再强转成int16_t。代码里我已经是这么写的，但如果你要改别人的代码，一定要把结构体定义从头到尾检查一遍。AC4、AC5、AC6保持uint16_t，这两个类型混用，很容易在计算时被隐式转换坑到。
4.3 现象三：I2C总线被从设备拉死，整个系统卡住
表现是任务跑一段时间后，再读气压返回失败，板子上I2C波形看SDA一直为低，SCL还在正常翻转。这种I2C死锁问题在STM32的硬件I2C上触发概率更高，原因通常是读数据过程中主设备提前释放了总线，或者从设备在传输中掉电，导致SDA被从设备锁死。
我现在的处理办法有两种。第一种是在I2C读函数里加超时保护，超时后强制把I2C外设复位，同时把SCL手动翻转9个周期，让从设备释放总线。第二种是改用GPIO模拟I2C，从根本上减少这种死锁概率。模拟I2C虽然占用CPU，但每次时序都由软件控制，就算出错，也能通过重新初始化GPIO状态来恢复。如果你选了硬件I2C，这个9脉冲恢复函数几乎是必须的。
4.4 现象四：低功耗场景下换用OSS=3后电池很快耗完
气压模式选了最高分辨率OSS=3，结果设备待机电流明显变大。忽视了一个细节：每次气压转换最长要25.5ms，在这个时间段内芯片处于活动状态，电流比休眠时大一个数量级。如果你每秒读一次，每25%的时间都在高电流，功耗当然下不来。
这里的选择是，根据实际场景定OSS。无人机定高对刷新率更敏感，OSS=0就已经够用，4.5ms完成一次转换，1秒能读20次。气象站要测气压趋势，对精度敏感，OSS=2比较合适，功耗和分辨率折中。不要为了读数好看盲目上OSS=3，除非你真的需要0.03hPa级别的分辨率。还有一个小技巧：不测量时把芯片完全断电，或者至少不要再轮询EOC，让I2C总线休眠。
5. 换个MCU也能用的移植技巧：只改I2C底层，保留一套驱动逻辑
BMP180的驱动代码最大的价值在于补偿算法那一层——把19位原始数据换算成温度和气压的公式是固定的，芯片手册里不会变。这部分代码值得单独抽出来，和I2C通信隔离。我现在的习惯是建两个文件：bmp180.c负责测量流程和补偿计算，bmp180_i2c.c负责具体平台上的I2C读写。换MCU时只改bmp180_i2c.c，上层的BMP180_ReadTemp和BMP180_ReadPressure一行都不用动。
移植后的验证方法我一般分三步走。第一步是改完底层后，先读校准参数，把11个值和数据手册上的出厂记录比对，如果全对，说明I2C读写是可靠的。第二步是连续读50次温度，记录最大值和最小值的差，温差保持在0.2℃以内算通过。第三步是拿气压值和当地气象站的实时数据做对比，用公式换算成海平面气压后，误差在±2hPa以内，驱动就算合格了。
分享一个真实教训：有一次我移植到新的MCU上，温度气压读数都正常，但和另一块板子比对总是差3hPa。查到最后，是I2C速率配置错误，跑在400kHz时读回来的校准参数都是正确的，但测量数据偶尔会错位。从那以后我每次移植完都会强制做一遍校准参数比对和连续读数稳定性测试，数据有一点不对，先降速到100kHz再排查，别急着怀疑芯片精度。希望帮到你。
本文还有配套的精品资源，点击获取
