前阵子做健康监测小项目我在网购模块里挑了一片 MAX30100 血氧心跳传感器以为接上 I2C、读几个寄存器就能把数据跑起来结果从 OpenHarmony 侧驱动注册到 PPG 信号稳定输出前后折腾了不少时间。这个过程中踩过的坑、验证过的方法整理出来就是这篇文章。内容覆盖 MAX30100 的测量原理、HDF 驱动框架下的驱动实现、FIFO 数据读取与缓冲设计、血氧和心率算法的边界以及最终调试验证时遇到的一堆实际问题。适合有 C 语言基础、想直接在 OpenHarmony 小设备上跑通这颗传感器驱动开发流程的朋友。1. 先搞清楚MAX30100在测什么血氧和心率背后的光学原理很多教程把 MAX30100 说得太简单了好像就是读寄存器、拿数据、算结果三步。但如果你不了解它到底在测量什么物理量后面遇到数据乱跳、数值不准的时候根本不知道从哪查起。所以第一步先把这颗传感器的物理逻辑讲清楚。1.1 红光与红外光的吸收差异SpO2测出来的依据血氧饱和度的核心是氧合血红蛋白HbO2和还原血红蛋白Hb对光的吸收特性不同。简单说氧合血红蛋白对 660nm 左右的红光吸收更弱、对 940nm 左右的红外光吸收更强还原血红蛋白正好相反。MAX30100 内部集成了红光 LED 和红外 LED再加上一个光电接收管。它让红光和红外交替发光接收管测量经过组织反射回来的光强根据两种波长的吸收比就能推断血液中氧合血红蛋白的比例。理解这一点对驱动开发很重要。因为你读出来的不是血氧百分比而是两个原始 ADC 值红光通道和红外通道的反射光强。血氧值必须用这两个通道的相对关系算出来只看任意一个通道是得不出结果的。这也就解释了为什么调试时一定要同时观察两条波形而不是只看一条。1.2 动脉搏动产生AC分量心率信号藏在0.5%~5%的变化里心率测量的原理是光电容积脉搏波PPG。心脏每次搏动动脉血管里的血容量会周期性变化这会导致皮肤组织对光的吸收量发生微小波动。于是反射光强出现一个很小的周期性起伏这个起伏的频率就是心率。这里有个关键概念光强信号里包含着巨大的直流分量DC它来自皮肤、骨骼、静脉血等固定组织对光的稳定吸收数值可能是几千而心跳引起的交流分量AC可能只占 DC 的 0.5% 到 5%也就是几十到几百 LSB。MAX30100 的 ADC 可以直接输出这个叠加了 DC 和 AC 的原始值驱动层要做的就是把这个信号完整、连续、不失真地采集回来后续用滤波把 DC 去掉把 AC 分离出来。注意AC 分量极其微弱这就是为什么硬件上很小的电源纹波都可能直接淹没信号。我一开始把传感器模块直接挂在开发板的 3.3V 上波形里全是周期性的毛刺后来专门用一个 LDO 单独给传感器供电并且在靠近芯片的 VIN 引脚并了 10μF 加 0.1μF 的去耦电容信号才干净下来。1.3 硬件连接与上电时序别让电源纹波毁掉PPGMAX30100 是标准 I2C 接口7 位地址是 0x57对应 8 位写地址 0xAE、读地址 0xAF。除了 VIN、GND、SDA、SCL还有一个 INT 引脚可以在 FIFO 达到某个阈值时产生中断。我的板子上最初没有接 INT完全靠轮询方式读取100Hz 采样率下完全够用。上电时序值得单独说芯片上电后寄存器不是立刻稳定的我从实际调试中发现刚上电立刻读设备 ID 很容易失败。建议流程是先让电源稳定几毫秒再读一次 PART_ID 验证 I2C 通讯确认通讯正常以后再写配置寄存器。如果一上来就连续写一串配置偶尔会出现前面的配置丢失、后面的配置生效的诡异情况排查起来很费时间。还有一个容易忽略的点LED 脉冲瞬间电流不小如果 VIN 走线和其它大电流外设共用一条电源线PPG 信号里会混入明显的工频或开关噪声。条件允许的话把它当作一个模拟前端器件来对待电源单独走、地线单点接。2. 在OpenHarmony这边驱动代码挂在哪里HDF的落地路径传感器物理上通了接下来是 OpenHarmony 侧的问题。OpenHarmony 的驱动框架叫 HDFHarmonyOS Driver Framework它有一套统一的驱动模型从设备描述、驱动加载到对外服务接口都有规范。刚开始接触会有点懵其实拆开看就三层驱动入口、设备描述HCS 配置、平台接口I2C 等。2.1 HDF驱动生命周期Bind、Init、Release到底干了什么HDF 驱动的生命周期很清晰。系统启动时HDF 框架会解析配置文件找到匹配的设备节点和驱动模块然后依次调用三个函数Bind、Init、Release。Bind 负责设备路径与驱动服务的绑定通常用来给上层应用提供一个可访问的接口路径Init 做真正的硬件初始化比如解析配置参数、打开 I2C 控制器、配置传感器寄存器、创建采集线程Release 则是卸载时释放资源、关闭设备。对应到 MAX30100 驱动上大部分核心工作都放在 Init 里Bind 如果暂时不做服务接口直接返回成功即可。驱动入口结构体需要指定模块名HDF 框架凭 moduleName 找到这个驱动模块。注册入口的宏在旧版本里是HDF_INIT新版本有的分支改成了HDF_DRIVER_INIT。如果你编译报这个宏找不到去系统已有的驱动源码里搜一下照着写就行。这类版本差异不用背遇到时现场对照最省事。2.2 HCS设备描述让驱动参数脱离C代码HDF 用的是 HCS 配置文件它是类树状结构的描述语言。设备在哪里、匹配哪个驱动属性、使用哪条 I2C 总线、从机地址是多少这些参数都写在 HCS 里驱动代码里不再硬编码。我项目里的 device_info.hcs 大致长这样root { sample_host { device_max30100 { deviceName max30100_device; deviceMatchAttr max30100_config; #include max30100_config.hcs } } }对应的 max30100_config.hcs 里放驱动自定义属性root { max30100_config { i2cBusNum 1; i2cAddr 0x57; sampleRate 100; redLedCurrent 0x21; irLedCurrent 0x24; } }这样做的价值在于换了一块板子、I2C 控制器变了只要改 HCS 文件C 代码一行不动。我后面前后换了两个硬件平台这个设计帮我省了很多事。注意deviceMatchAttr的值要和驱动代码里读取配置时使用的匹配属性一致否则驱动能找到模块但拿不到自定义参数。2.3 驱动源码目录与BUILD.gn的组织方式驱动源码我放在板级目录下的 drivers 子目录里结构很简单device/board/xxx/drivers/max30100/ ├── max30100.c ├── max30100.h ├── max30100_config.hcs └── BUILD.gnBUILD.gn 用 HDF 提供的驱动模板编译简化版长这样import(//build/ohos.gni) hdf_driver(max30100_driver) { sources [ max30100.c, ] include_dirs [ //drivers/framework/include, //drivers/framework/include/platform, ] deps [ //drivers/framework/stream/platform/i2c:libi2c, //drivers/framework/core/adapter:libhdf_adapter, ] }不同 OpenHarmony 版本的模板名称、依赖路径差别不小我每次换版本都会对照系统里现成的驱动 BUILD.gn 改。不用死记关键是理解依赖关系驱动代码需要包含 HDF 核心头文件和 I2C 平台接口头文件。3. 驱动开发实操从寄存器配置到FIFO数据流前面准备做足了这一章进入代码。我会按实际开发顺序来讲先写 I2C 读写封装再做初始化配置最后设计连续采集的数据通路。写驱动和写业务代码不一样每一步都要能独立验证别指望一口气写完再统一调试那样出了问题根本定位不到。3.1 驱动入口与I2C读写封装先定义设备结构体和两个 I2C 传输函数。HDF 的 I2C 接口在旧版本里是I2cOpen、I2cTransfer、I2cClose如果你的系统版本用的是新的I2cCnRead、I2cCnWrite替换对应调用即可封装思路是一样的#include hdf_device_desc.h #include hdf_log.h #include device_resource_if.h #include i2c_if.h #define MAX30100_I2C_ADDR 0x57 #define MAX30100_REG_PART_ID 0x0D typedef struct { DevHandle i2cHandle; uint8_t i2cAddr; uint32_t busNum; uint32_t sampleRate; uint8_t redLedCurrent; uint8_t irLedCurrent; } Max30100Device; static Max30100Device g_max30100; static int32_t Max30100WriteReg(uint8_t reg, uint8_t val) { struct I2cMsg msg; uint8_t buf[2]; buf[0] reg; buf[1] val; msg.addr g_max30100.i2cAddr; msg.flags 0; msg.len 2; msg.buf buf; return I2cTransfer(g_max30100.i2cHandle, msg, 1); } static int32_t Max30100ReadRegs(uint8_t reg, uint8_t *buf, uint16_t len) { struct I2cMsg msgs[2]; uint8_t regAddr reg; msgs[0].addr g_max30100.i2cAddr; msgs[0].flags 0; msgs[0].len 1; msgs[0].buf regAddr; msgs[1].addr g_max30100.i2cAddr; msgs[1].flags I2C_FLAG_READ; msgs[1].len len; msgs[1].buf buf; return I2cTransfer(g_max30100.i2cHandle, msgs, 2); }写寄存器用先发寄存器地址、再发数据的一次写事务读用先写寄存器地址、再发读事务的两段式传输。我在调试中发现千万不要把多个寄存器写操作一次性拼到一个事务里MAX30100 对 I2C 时序挺敏感分开写、读回验证稳定性明显更好。然后是驱动入口static int32_t Max30100Bind(struct HdfDeviceObject *device) { (void)device; return HDF_SUCCESS; } static int32_t Max30100Init(struct HdfDeviceObject *device) { // 解析HCS属性、打开I2C、验证芯片、初始化寄存器、启动采集线程 } static void Max30100Release(struct HdfDeviceObject *device) { if (g_max30100.i2cHandle ! NULL) { I2cClose(g_max30100.i2cHandle); g_max30100.i2cHandle NULL; } } struct HdfDriverEntry g_max30100DriverEntry { .moduleVersion 1, .moduleName max30100_driver, .Bind Max30100Bind, .Init Max30100Init, .Release Max30100Release, }; HDF_INIT(g_max30100DriverEntry);Init 里第一件事是解析 HCS 属性。不同版本接口名有差异我用的版本是GetUint32ElemValuestruct DeviceResourceIface *iface DeviceResourceIfaceGet(); if (iface NULL) { return HDF_FAILURE; } if (iface-GetUint32ElemValue(device-property, i2cBusNum, g_max30100.busNum, 0) ! HDF_SUCCESS) { HDF_LOGE(read i2cBusNum failed); return HDF_FAILURE; } if (iface-GetUint32ElemValue(device-property, i2cAddr, g_max30100.i2cAddr, 0) ! HDF_SUCCESS) { HDF_LOGE(read i2cAddr failed); return HDF_FAILURE; }拿到总线号和地址之后打开 I2C 控制器g_max30100.i2cHandle I2cOpen((uint16_t)g_max30100.busNum); if (g_max30100.i2cHandle NULL) { HDF_LOGE(I2cOpen failed); return HDF_FAILURE; }先读一次 PART_ID确认芯片真的在总线上再做后续初始化。这个先验证再配置的习惯帮我避免了很多无效调试。3.2 初始化寄存器设置分步验证比一次写齐更重要初始化寄存器最忌讳网上抄一份配置一写了之。每个项目的电源环境、LED 电流、采样率需求都不一样我一开始把几组配置一起写结果信号不是饱和就是太弱最后只能逐个寄存器回退着查。关键的寄存器有这几个寄存器地址我的配置策略FIFO_CONFIG0x06开启滚动模式允许新数据覆盖旧数据防止溢出停采样本平均设到 4可以平滑信号毛刺MODE_CONFIG0x07配成 SpO2 模式让红光和红外 LED 交替工作SPO2_CONFIG0x08采样率配到 100Hz这个频率对心率信号充足ADC 量程和脉宽按手上手册的位定义来选LED1_PA0x09红光 LED 电流初始给一个中间值后面按波形调LED2_PA0x0A红外 LED 电流同样先给中间值配置代码大致这样static int32_t Max30100Config(void) { int32_t ret; ret Max30100WriteReg(0x06, 0x50); // 滚动使能 样本平均4 if (ret ! HDF_SUCCESS) return ret; ret Max30100WriteReg(0x07, 0x03); // SpO2模式 if (ret ! HDF_SUCCESS) return ret; // 采样率等参数按数据手册的位定义设置这里不写死 ret Max30100WriteReg(0x08, sampleRateConfig); if (ret ! HDF_SUCCESS) return ret; ret Max30100WriteReg(0x09, g_max30100.redLedCurrent); if (ret ! HDF_SUCCESS) return ret; ret Max30100WriteReg(0x0A, g_max30100.irLedCurrent); if (ret ! HDF_SUCCESS) return ret; return HDF_SUCCESS; }配置完成后我习惯立刻回读一遍确认寄存器真的写进去了。有些时候 I2C 传输返回成功但设备端因为时序问题没有真正接收回读是最直接的验证手段。LED 电流的选择值得单独说电流太小AC 分量被噪声淹没电流太大接收管饱和ADC 读数顶到满量程血氧比值完全失真。我调这个花了很长时间最终原则是让两个通道的静态 DC 值落在 ADC 量程的中间偏下位置比如 16 位 ADC 的话让 DC 落在 2000 到 3000 左右然后在这个基础上微调 AC 幅度。3.3 FIFO读取与环形缓冲采集线程怎么设计MAX30100 内部有个 FIFO传感器采集的数据先存在 FIFO 里驱动再去读。在 SpO2 模式下每个样本包含红光和红外两个 16 位 ADC 值即 4 字节。读取时先看写指针和读指针算出当前可读几个样本再连续读取。#define MAX30100_REG_FIFO_WR_PTR 0x02 #define MAX30100_REG_FIFO_RD_PTR 0x04 #define MAX30100_REG_FIFO_DATA 0x05 static int32_t Max30100ReadPpg(uint16_t *redArray, uint16_t *irArray, uint8_t *count) { uint8_t wr; uint8_t rd; uint8_t raw[32]; uint8_t available; int32_t ret; int32_t i; ret Max30100ReadRegs(MAX30100_REG_FIFO_WR_PTR, wr, 1); if (ret ! HDF_SUCCESS) return ret; ret Max30100ReadRegs(MAX30100_REG_FIFO_RD_PTR, rd, 1); if (ret ! HDF_SUCCESS) return ret; available (uint8_t)(((wr 32 - rd) 0x1F) / 4); if (available 0) { *count 0; return HDF_SUCCESS; } if (available 8) { available 8; // 单次最多拿8个样本避免长时间占用I2C } ret Max30100ReadRegs(MAX30100_REG_FIFO_DATA, raw, (uint16_t)(available * 4)); if (ret ! HDF_SUCCESS) return ret; for (i 0; i available; i) { uint8_t *p raw[i * 4]; redArray[i] (uint16_t)((p[0] 8) | p[1]); irArray[i] (uint16_t)((p[2] 8) | p[3]); } *count available; return HDF_SUCCESS; }这里有个小细节计算可用样本数时((wr 32 - rd) 0x1F)是把写指针和读指针放在同一个环形空间里求差避免指针回绕时相减出负数或出大数。MAX30100 的 FIFO 深度是 32 个样本单位SpO2 模式下每个样本点占 4 个单元所以再除以 4 得到可读样本数。采集线程我用了最直白的轮询方式每隔 10ms 调一次Max30100ReadPpg把数据写进一个环形缓冲区。环形缓冲大小我设置成 128 组样本大约是 1 秒多钟的数据量足够应用层做算法运算。生产者和消费者的逻辑很简单typedef struct { uint16_t red[128]; uint16_t ir[128]; uint16_t head; uint16_t tail; } PpgRingBuffer;采集线程向 head 写应用层从 tail 读。如果应用层来不及消费就覆盖最旧的数据保证拿到的永远是最新的一段波。数据规模不大用数组实现比链表简单可靠得多也不会因为内存分配产生碎片问题。3.4 把数据送给应用层轮询、中断与服务接口的选择数据最后怎么交给应用层我前前后后试过三种方式。最简单的是轮询驱动里的采集线程负责读 FIFO应用层按需调用查询接口从环形缓冲里取数据。这种方式代码少100Hz 采样率下足够稳我就先用它跑通了整条链路。第二种是用 INT 引脚。MAX30100 的 INT 在 FIFO 数据达到一定量时拉低接到开发板的 GPIO 中断上驱动收到中断以后再去读。好处是功耗低、不需要固定周期唤醒适合做低功耗穿戴设备的场景。代价是要多申请一个 GPIO 中断而且中断服务函数里不能做太重的事通常是置一个标志唤醒采集线程去干活。第三种是做成 HDF 服务由上层应用绑定服务路径后调用。这是最规范的做法但牵扯到 HDF 服务接口定义、权限配置、应用侧跨进程调用工程量会大不少。我的经验是先把数据链路调通再考虑要不要上服务框架。4. 原始PPG到手之后算法与驱动的分工边界驱动把连续的 PPG 原始数据送到环形缓冲之后接下来才是真正意义的数据处理。这一章重点讲算法和驱动的分工因为我在这个环节走过弯路一开始想在驱动里把血氧和心率全算完结果耦合太重、调参也麻烦后面全部推倒重来。4.1 原始PPG波形长什么样先学会画图在写任何算法之前先把数据画出来看。最笨也最有效的方法是串口按 CSV 格式打印采样序号、红光 ADC、红外 ADCPC 端用 Python 脚本读取并画波形。正常的 PPG 波形长这样每个通道都是一个接近直流的基线基线值在几千左右上面叠加小幅度的、周期性的起伏每个起伏对应一次心跳。红光通道和红外通道的起伏应该基本同步但幅度可能不同。如果你看到两个通道的起伏不同步、形状差异很大说明某个通道饱和了或者 LED 电流配比不对。这一步没有捷径。我见过很聪明的同学直接跳过画图开始写血氧算法最后调了两天也不知道是算法问题还是信号问题。信号都没看明白算法就是盲人摸象。4.2 心率计算峰值检测与带通滤波心率算法我放在应用层做驱动层只保证数据连续、带时间戳。算法思路分三步滤波、峰检测、间隔换算。先对红外通道做带通滤波。心率范围一般在 30 到 200 次每分钟换算成频率大约是 0.5Hz 到 3.3Hz用一个两步的 IIR 滤波器把直流和低频漂移滤掉同时把 5Hz 以上的高频噪声去掉。滤波之后基线被拉平剩下的是清晰的脉搏波。然后是峰值检测。我最常用的是一阶差分加滑动窗口// 伪代码寻找局部最大值并限制最小波峰间隔 if (current prev current next current threshold (now - lastBeatTime) minInterval) { heartRate 60000 / (now - lastBeatTime); lastBeatTime now; }这个思路简单但在信号质量不错的场景下很有效。minInterval用来防止把同一波形的两个小毛刺误判成两次心跳我一般设 300ms对应最大 200bpm。注意心率输出不要每拍都更新正确做法是取过去 4 到 8 拍的间隔做滑动平均否则读数会跳动得很厉害。4.3 SpO2计算R值公式和查表思路血氧计算比心率稍微绕一点但原理不复杂。对红光和红外两个通道分别提取交流分量 AC 和直流分量 DC计算比值 RR (AC_RED / DC_RED) / (AC_IR / DC_IR)然后通过经验公式或查表把 R 映射到 SpO2。标准模型下R 值在 0.4 附近对应接近 100% 的血氧R 为 1.0 左右大约对应 94%R 为 2.0 时大约降到 75% 附近。这个区间可以做个粗略对照R值参考SpO20.4约100%0.6约97%1.0约94%1.5约85%2.0约75%注意这张表只能作为演示示意不能直接用于医疗用途。不同肤色、不同 LED 波长偏差、不同佩戴松紧都会改变映射曲线做到产品级必须用自己的硬件和采集环境做多用户标定。实际计算中AC 不能直接取原始数据的振幅一般是用带通滤波后的信号按一个滑动窗口算均方根或平均峰峰值。窗口太长响应慢窗口太短数值抖动大我最终选了 4 秒窗口每 1 秒输出一次平衡了更新速度和稳定性。4.4 为什么我不建议在驱动层做算法我知道有人会觉得既然驱动里已经有数据了顺手就把心率算了多方便。我确实这么干过然后果断放弃了。原因是算法开发是高频迭代的滤波器的截止频率、窗口长度、阈值参数几乎每天都要调。如果这些逻辑塞在驱动里每次调参都要重新编译整个驱动镜像、烧录、重启设备效率极低。驱动层的正确姿势是稳定采数、打时间戳、管理缓冲、提供干净的接口。算法放应用层可以单独编译、单独调试甚至可以在 PC 上用同样的算法处理串口传出来的数据。这个架构上的分界比优化任何一个具体算法细节都更重要。5. 想拿到稳定的数据我踩过并解决过的坑最后这一章我把整个开发周期里遇到的最典型的几个问题列出来。这些问题在网上都能搜到零散答案但很少有文章把排查思路讲清楚我尽量还原当时的判断过程。5.1 设备ID读出来全FF先查时序再查I2C第一次上电读 PART_ID 返回 0xFF也就是总线上根本没应答。我当时第一反应是模块坏了换了一片还是同样现象才开始系统排查。排查顺序是这样的先查 I2C 地址确认发的是 0xAE 写地址再查 HCS 配置里的总线号会不会配到了一条没有设备的空总线上然后用逻辑分析仪看 SCL/SDA 波形发现 SDA 根本没有被拉低说明从设备没有拉总线最后检查模块板上的上拉电阻发现模块自带上拉但因为接了一根比较长的杜邦线加上开发板内部也有上拉组合起来电平反而异常。换用短线和独立 4.7k 上拉后ID 正常读回。还有一个容易忽略的原因刚上电立刻读 ID芯片还没准备好。我后来在 Init 里先OsalMSleep(10)再读成功率明显提升。读到 ID 值之后要和你手上的芯片批次资料核对不同批次的 ID 可能会不一样不同型号的兼容芯片也可能返回不同数值。5.2 FIFO溢出或长期为空采样率与读出节奏的平衡调试中我遇到过两个极端一个现象是 FIFO 溢出标志一直置起另一个现象是读出来的样本永远是 0。这两个问题其实是同一类问题采样率和读取节奏失配。溢出很好理解采样率 800Hz但上层读取线程每隔 50ms 才读一次FIFO 早就满了。如果没有开滚动模式芯片会停止采样数据就断了即使在滚动模式数据也会大量覆盖丢失。解决方法是把采样率降到 100Hz读取线程保证至少每 20ms 读一次。我之前用消息队列间接读延迟涨到几十毫秒后数据就开始出现空洞后来直接用一个高优先级的采集线程轮询问题消失。长期为空的原因则更隐蔽。起初我怀疑是寄存器配置问题反复检查都没发现错误。后来发现采集线程创建成功但一直阻塞在等待一个应用层才会发送的信号量上导致 FIFO 里的数据永远没人读。这是一个纯粹的调度设计错误和传感器本身无关。这也提醒我驱动里的采集线程和上层消费逻辑尽量解耦采集线程只依赖自己的定时器不要依赖外部信号。5.3 SpO2数值乱跳信号质量评估比算法更关键血氧值乱跳是几乎所有健康监测设备都会遇到的问题。刚开始我的 R 值算出来一会儿 0.3、一会儿 2.5血氧从 100% 直接掉到 75%但人的状态完全正常。仔细观察原始波形后才明白是手指按压力度变化和微小晃动导致的运动伪迹。解决这个问题算法上最高效的不是优化公式而是加信号质量评估。我加了三个判断条件一是 R 值必须落在 0.3 到 2.5 的合理区间内超出就不输出二是红光和红外通道的波峰间隔要基本一致差异超过 20% 就视为信号不可靠三是 AC 分量占比不能太低AC 太小说明信号太弱通常是因为手指没有贴紧或 LED 电流不足。经过这三道闸以后稳定坐姿下血氧读数能连续几分钟保持误差在一个很小的范围内。运动状态下想做到完全稳定那就要上加速度传感器辅助做运动伪迹消除已经超出这颗芯片本身的能力范围了。5.4 调试方法串口日志加Python绘图具体调试手段上我推荐一套投入小、见效快的组合驱动把数据以文本帧格式从串口发出来PC 端用 Python 的 pyserial 接收再用 matplotlib 实时绘图。串口输出格式我做成这样frame_no, red, ir 123, 2400, 2800 124, 2420, 2820驱动里注意不要在 I2C 读数据的过程中直接打印日志串口打印很慢会把采样节奏拖垮。正确做法是先把本次读到的数据存到环形缓冲到主循环外面再按批量输出。Python 侧我每次只画最近 10 秒的波形这样既能看细节又不会糊成一团。画图的时候重点关注三个指标DC 基线是否稳定、AC 幅度是否在合理范围、两个通道的波峰是否同步。这三个指标正常再去看心率血氧计算结果否则先回头查硬件和配置。还有一个小技巧用串口输出的样本序号检查丢帧。如果序号不连续说明驱动读取侧有丢数据这时候不管算法多好最终结果都会受影响。先把序号补成全连续再接算法这条调试顺序我后来一直遵守。如果问我在这个项目里最大的体会其实不是学会了怎么配 HDF、怎么写 I2C 封装而是意识到驱动开发真正的难点是数据质量而不是代码框架。MAX30100 是一颗很便宜的传感器但想拿到稳定的 PPG 数据从电源、布局、LED 电流到读取节奏每一个环节都在影响最终结果。我建议你动手时先别急着写算法把波形打印出来盯一两个晚上信号看着顺眼了心率血氧自然就出来了。后面有空我再写一篇应用层怎么通过 HDF 服务读取驱动数据以及把实时波形传到手机端调试的做法。
