简介：这是一套基于STM32的MAX30100心率血氧传感器驱动程序包，面向嵌入式开发者和健康监测产品入门者，解决在STM32平台上快速完成传感器配置、原始数据采集与心率和血氧计算的问题。压缩包大小6.95MB，共200个文件，除C/C++源码（.c/.h）外，还包含Keil工程配置（.uvprojx）、编译中间文件（.o/.d/.crf）以及可直接烧录的hex文件，适合直接打开工程查看学习或二次开发。工程中不仅包含max30100驱动相关代码，还集成了STM32F10x系列的多种外设驱动，如I2C、定时器、ADC、FLASH等，并带有LCD显示模块，可直观展示测量结果。已有712人学习下载，对于正在调试心率血氧功能、需要参考底层寄存器配置和信号处理思路的开发者而言，这份工程能提供完整的实现范例，包括滤波处理和基于光电容积脉搏波的血氧估算流程，具有较高的参考价值。
1. 为什么MAX30100驱动不能直接抄给MAX30101
如果看到MAX30101和MAX30100用同一个I2C地址、同一套FIFO寄存器，就顺手把MAX30100的驱动工程改个芯片型号编译到MAX30101上，结果往往是红光和红外通道能出数，绿光通道始终读不到有效信号。MAX30101和MAX30100在寄存器布局上是同一个家族，但多出来的绿光LED电流寄存器、温度传感器和模式位会让快速初始化序列完全对不上。下面把驱动拆成“寄存器差异→I2C读写层→初始化时序→FIFO读数→验证”五个块，用C/C++把两个芯片同时跑通。适合正在做手环、血氧夹，或者准备把老项目的MAX30100驱动迁移到MAX30101的嵌入式工程师。
2. 寄存器级对比：MAX30100与MAX30101的真实差异
2.1 从I2C地址到寄存器映射的相似性
MAX30100和MAX30101都挂在I2C总线上，设备地址都是0x57，I2C时钟建议不要超过400kHz。两个芯片的寄存器空间从0x00到0xFF，重叠度非常高，绝大多数驱动例程只需要关心中断状态0x00、中断使能0x01、FIFO写指针0x02、FIFO溢出计数0x03、FIFO读指针0x04、FIFO数据0x05、模式配置0x06、SpO2配置0x07，以及设备ID 0xFE。对只做心率和血氧的固件来说，操作这些寄存器就能跑起来。
但操作方式不一定兼容。以模式配置寄存器0x06为例，MAX30100在心率模式下只需要在低三位写0b000，SpO2模式写0b010；MAX30101同样使用0x06，但针对绿光LED增加了一种“红光+红外+绿光同时采样”的multi-LED模式。如果把MAX30100的初始化状态机原封不动套过来，绿光通道不会被使能，而且FIFO里每个采样占用的字节数也会对不上。真正的坑就在这里。
2.2 两张芯片的关键差异表
我把驱动需要关心的差异列成表，方便选型和写宏时直接对照。
| 项目 | MAX30100 | MAX30101 |
|---|---|---|
| I2C地址 | 0x57 | 0x57 |
| LED数量 | 红光+红外，2路 | 红光+红外+绿光，3路 |
| LED电流寄存器 | 0x0C（红光）、0x0D（红外） | 0x0C、0x0D、0x11（绿光） |
| 温度传感器 | 无 | 有，温度配置0x18，数据0x16/0x17 |
| 设备ID（0xFE典型值） | 0x11 | 0x15 |
| FIFO单采样典型大小 | 6字节（红+红外各18bit） | 6字节或9字节，取决于模式 |
| 适用佩戴方式 | 手指透射式为主 | 手指和手腕反射式均可 |
这张表每个差异点都会反馈到驱动代码上。设备ID决定上电自检时走哪套分支；绿光电流寄存器决定反射式场景下的功耗策略；温度传感器则影响数据手册对LED发射强度随温度漂移的修正。驱动层面的做法是保留一个uint8_t chip_model变量，初始化时读0xFE保存，之后所有配置都通过它判断。
2.3 模式配置和温度寄存器怎么区分
当驱动需要同时兼容两种芯片时，我一般会在头文件里做两组宏，而不是在代码里到处判断芯片ID。
#define MAX30_CFG_HR_MODE 0x00 #define MAX30_CFG_SPO2_MODE 0x03 #define MAX30_CFG_MULTI_MODE 0x07其中MAX30_CFG_MULTI_MODE仅供MAX30101在绿光多LED场景下使用，MAX30100遇到这个值只会停在错误状态。初始化函数里必须根据之前读回的ID来决定最终写入的模式值：
uint8_t mode_reg; if (chip_model == MAX30101) { mode_reg = MAX30_CFG_MULTI_MODE; } else { mode_reg = MAX30_CFG_SPO2_MODE; } max30_write_reg(0x06, mode_reg);温度寄存器建议独立封装成max30_temp_read(float *t)，因为MAX30101的温度值分成整数和小数两个寄存器，读取前还要通过温度配置寄存器0x18触发转换。如果把这些逻辑塞进通用读写函数里，会让普通LED通道读取数据时多出无用代码，也容易在低温环境下引入额外延迟。
3. 用C/C++搭建跨芯片的I2C驱动核心
3.1 驱动分层的常见做法：HAL、核心与应用分离
写MAX30100/01驱动最怕的是把所有I2C操作直接写在业务代码里，芯片型号一变，改得满文件都是。常见做法是把驱动拆成三层：HAL层只提供I2C读写、延时、毫秒计数三个函数；核心层负责寄存器操作、初始化和FIFO读取；应用层只拿原始红光、红外数值去算血氧或心率。这样换MCU时只改HAL层，换MAX30101时也只改核心层的初始化分支。
HAL层接口我习惯定义成这样：
int hal_i2c_write_blocking(uint8_t dev_addr, const uint8_t *buf, uint8_t len); int hal_i2c_read_blocking(uint8_t dev_addr, uint8_t reg, uint8_t *buf, uint8_t len); void hal_delay_ms(uint32_t ms);返回0表示成功，非0表示错误。不要直接引用某家vendor库的HAL类型，避免驱动层被具体芯片厂商绑死，后面也能在PC端模拟器里替换实现。
3.2 最小可用的I2C读写层实现
核心层的寄存器读写直接封装为两个函数。写寄存器时，把寄存器地址和值拼成一个缓冲区，再交给HAL层；读寄存器时，先发送寄存器地址，再连续读回N个字节。下面是C语言的参考实现：
#define MAX30_I2C_ADDR 0x57 int max30_write_reg(uint8_t reg, uint8_t val) { uint8_t pkt[2]; pkt[0] = reg; pkt[1] = val; return hal_i2c_write_blocking(MAX30_I2C_ADDR, pkt, 2); } int max30_read_reg(uint8_t reg, uint8_t *val) { return hal_i2c_read_blocking(MAX30_I2C_ADDR, reg, val, 1); } int max30_read_fifo(uint8_t *buf, uint8_t len) { return hal_i2c_read_blocking(MAX30_I2C_ADDR, 0x05, buf, len); }这里把FIFO数据寄存器0x05单独剥出来，是因为连续读FIFO时寄存器地址不应变化，I2C只需要在启动时发送一次地址。hal_i2c_read_blocking内部会处理重复起始位，确保时序正确。参数len最大可以设为9，对应MAX30101在triple LED模式下的一个采样大小。单独封装的好处是在使用DMA传输时，不会因为寄存器地址每次递增而破坏FIFO的自动滚动读机制。
3.3 初始化序列：先复位、再识别、最后配模式
初始化顺序是驱动能否稳定工作的关键。我见过很多失败的案例，都是因为先配置SpO2参数、后写复位寄存器，导致前面配置被复位清零。推荐的顺序是：
- 写模式配置0x06，置位复位位并等待10ms；
- 再写0x06，清除复位位，保留目标模式；
- 读0xFE设备ID，确认当前芯片型号；
- 依次配置SpO2寄存器、LED电流寄存器、中断使能；
- 最后再次写模式寄存器，让芯片进入正式采样状态。
#define MAX30_REG_MODE 0x06 #define MAX30_REG_SPO2 0x07 #define MAX30_REG_LED_RED 0x0C #define MAX30_REG_LED_IR 0x0D int max30_init(int is_max30101) { uint8_t id = 0; max30_write_reg(MAX30_REG_MODE, 0x40 | 0x03); hal_delay_ms(10); max30_write_reg(MAX30_REG_MODE, 0x03); if (max30_read_reg(0xFE, &id) < 0) { return -1; } if (is_max30101 && id != 0x15) return -2; if (!is_max30101 && id != 0x11) return -2; max30_write_reg(MAX30_REG_SPO2, 0x27); max30_write_reg(MAX30_REG_LED_RED, 0x24); max30_write_reg(MAX30_REG_LED_IR, 0x24); if (is_max30101) { max30_write_reg(0x11, 0x24); max30_write_reg(0x18, 0x01); } max30_write_reg(0x01, 0xC0); return 0; }这里复位写的是0x40 | 0x03，bit6为复位位，低3位先写目标模式，复位结束后再写一次不带复位位的模式值。0x27是SpO2配置的起始值，含义是LED脉冲宽度、ADC满量程和采样率的组合，具体每个字段要对照手册核对。LED电流寄存器0x24对应一个常见的毫安值，后续调试时再根据波形幅度微调。MAX30101比MAX30100多出的0x11和0x18在这里单独处理，避免通用代码读到不存在的寄存器。
4. FIFO数据读取与SpO2计算的参数设置
4.1 从FIFO取数：指针计算与连续读
MAX30100和MAX30101的FIFO都按环形缓冲区组织，容量32个样本。读指针寄存器是0x04，写指针寄存器是0x02，读取前先计算当前样本数(wr + 32 - rd) & 0x1F，这样不会出现负数情况。MAX30100每个样本占6字节，顺序是红光高字节、红光中间字节、红光低字节（只有高2位有效）、红外高字节、红外中间字节、红外低字节。下面的函数会返回本次读到的样本数：
#define MAX30_REG_WRPTR 0x02 #define MAX30_REG_RDPTR 0x04 int max30_fifo_read(uint32_t red[], uint32_t ir[], int max_samples) { uint8_t wr, rd, cnt, buf[6]; int i = 0; max30_read_reg(MAX30_REG_WRPTR, &wr); max30_read_reg(MAX30_REG_RDPTR, &rd); cnt = (wr + 32 - rd) & 0x1F; cnt = (cnt > max_samples) ? max_samples : cnt; while (cnt--) { if (max30_read_fifo(buf, 6) < 0) { return -1; } red[i] = ((buf[0] & 0x03) << 16) | ((uint32_t)buf[1] << 8) | buf[2]; ir[i] = ((buf[3] & 0x03) << 16) | ((uint32_t)buf[4] << 8) | buf[5]; i++; } return i; }代码里对红光和红外数据的第1个字节做了& 0x03，因为18位ADC结果被拆成3字节，最高字节只有低2位有效。这里容易踩的坑是只看中间字节，导致波形在满量程附近出现跳变。如果MAX30101工作在triple LED模式，需要把buf改为9字节，并按顺序读取绿光数据，否则读指针会漂移，之后所有样本都错位。读取完一组数据后，可以通过重新读回0x02和0x04确认指针已经滚动，防止中断服务里出现半包更新。
注意：FIFO溢出时读指针不会自动恢复，必须在应用层读取到溢出计数0x03非零后，将写指针和读指针同时清零。
4.2 SpO2公式和它的误差来源
血氧饱和度不能直接用红光和红外的原始值相除，需要先提取交流成分和直流成分。交流成分是脉搏波动的峰峰值，直流成分是信号的基线值。工程上会先对原始信号做带通滤波，窗口长度一般取2到5秒，然后计算：
float max30_spo2_estimate(float red_ac, float red_dc, float ir_ac, float ir_dc) { float r = (red_ac / red_dc) / (ir_ac / ir_dc); return -45.06f * r + 30.25f * r + 94.87f; }这个公式只是线性拟合简化版，真正的产品需要根据探头位置标定系数。MAX30101的优势在手腕佩戴时绿光通道信号更强，可以把绿光的AC/DC代入公式里的红外位置，减少运动伪迹。驱动本身不需要做太多信号处理，但必须保证原始数据帧连续，否则中间缺一段，AC计算会失真，最终血氧值会跳得很难看。
4.3 采样率、LED电流和ADC量程怎么定
这三个参数直接决定波形质量和功耗。采样率太低，脉搏波形会被欠采样，心率跳变捕捉不到；LED电流太大，ADC容易饱和，红光通道可能出现削顶；ADC量程太小，微弱脉搏信号会被量化噪声盖住。下面是我惯用的起点配置：
| 参数 | 手指透射式(MAX30100) | 手腕反射式(MAX30101) |
|---|---|---|
| SpO2采样率 | 100Hz | 50~100Hz |
| LED电流 | 红光6.4mA/红外6.4mA | 红光6.4mA，绿光可调至10mA以上 |
| ADC满量程 | 2048nA~4096nA | 4096nA~8192nA |
| FIFO中断触发值 | 15个样本 | 15个样本 |
实际调试时，先把LED电流调小，观察红光和红外原始值的直方图，保证大部分采样在ADC量程的30%~70%之间。如果看到大量接近满量程的值，说明电流过大；如果波形幅度小于量程的5%，则要增加LED电流或减少手指与传感器的距离。参数修改后需要重新写0x07与LED寄存器，并等待FIFO完全清空再采样，避免新旧配置混在一起。芯片型号不同，I2C总线的时序裕量也不同，MAX30101因为多一路LED，内部多路复用的切换延迟会体现在波形相位差上，所以不要只看绝对幅度，还要对比红光和红外波形的峰位置。
5. 驱动验证的三板斧：读ID、看波形、补中断
5.1 先读ID让硬件说话
拿到驱动后先跑一个最小测试，只读0xFE设备ID。这一步能同时验证I2C通信、芯片焊接和电源电压。打印值如果和型号不符，优先检查I2C地址是否被映射到了别的地方、SDA/SCL上拉电阻是否在2k到10k之间、VDD是否稳定在1.8V。ID正确后再跑初始化，很多无解的FIFO问题在ID阶段就能暴露。
5.2 在vscode里用C/C++建一个寄存器模拟器
没有硬件时，我会在PC端用vscode配置c/c++环境，把驱动核心代码编译成一个本地可执行文件，用模拟I2C回调替代真实总线。由于驱动层用的是hal_i2c_*函数，只要在测试工程里重新实现这三个函数，就能让驱动代码在PC上跑起来。配合CMake和CUnit，可以快速验证FIFO指针计算和溢出逻辑，不用每次改驱动都烧板子。模拟器里的寄存器状态用数组维护，写寄存器时同步更新内存，读寄存器时返回数组内容，测试脚本就能断言中断标志是否被正确清除。这也算是驱动侧的一个轻量级c/c++构建目标，跟固件工程完全分离。
5.3 中断处理里的FIFO复位策略
实际产品里建议用INT引脚触发FIFO几乎满中断，不要在main循环里轮询FIFO指针。中断处理函数要做的不是马上读FIFO，而是先记录中断状态，等主循环空闲时再读取。如果溢出计数0x03非零，说明应用层处理太慢，此时要把读写指针同时清零，否则环形缓冲区错位后波形会出现一个大的跳变。补中断这一步，做到“溢出即清空”就够了，不需要做复杂的预测补偿，因为MAX30100的FIFO采样率最高只有400Hz，32个样本留出的处理时间在几十毫秒量级，实时性要求并不苛刻。
本文还有配套的精品资源，点击获取
