企业官网建设流程全解析

简介：这套基于STM32单片机与安卓客户端联动的软硬件综合资源，面向毕业设计、课程设计和嵌入式项目开发，解决心率脉搏监测与运动计步的完整实现问题。硬件端使用MAX30102心率传感器采集心率和脉搏，SW-1801P震动传感器统计步数，再通过HC-05蓝牙模块传输到Android App进行可视化展示，覆盖传感器驱动、蓝牙通信、数据处理与移动端展示等关键环节，适合需要完成软硬件联调项目的读者参考。压缩包约84.43MB，共535个文件，包含C语言源码、Keil5工程配置、PDF参考论文与项目文档、APK安装包和图片等，目录结构清晰，便于按模块查阅和二次开发。已有82人学习，源码经过严格测试，配套调试文档可用于验证硬件逻辑、梳理通信流程及排错，适合作为课程设计、毕业设计或实际项目起步的完整参考。

1. 心率脉搏监测与计步系统：源码、论文、调试文档怎么配合出一套完整 STM32 项目

毕设答辩现场最怕老师问一句：“你测出来的心率准不准？拿指夹式血氧仪对一下。”很多人的项目当场翻车，不是因为代码跑不起来，而是因为传感器读数连自己都说服不了。这套基于 C语言 + STM32单片机 的心率脉搏监测健康运动计步系统，就是冲着“能答辩、能复现、能讲清原理”去的：MAX30102 做光电容积脉搏波（PPG）采集，MPU6050 做三轴加速度计步，OLED 实时显示心率与步数，配套的源码、参考论文、项目文档、调试文档正好覆盖从硬件接线到论文写作的全过程。适合两类人：一类是做毕业设计或课程设计的学生，需要一套能完整落地、经得起追问的项目；另一类是刚入门 STM32 的开发者，想看看一个带传感器算法、带显示、带串口调试的工程到底怎么分层组织。下面按我实际拆这套资源的顺序，把硬件选型、算法实现、工程配置和排错过程一条条讲清楚。

2. 硬件架构与传感器选型：MAX30102 与 MPU6050 各管一条数据链

2.1 为什么是 PPG 方案加六轴传感器，而不是心率带或心电模块

心率检测有几种常见路线：心电（ECG）方案需要模拟前端芯片加电极贴片，信号质量好但硬件贵、调试门槛高，贴在胸口测量也不适合做可穿戴演示；心率带方案依赖胸带和专用接收器，和 STM32 的整合成本高。这套资源选的是 MAX30102 这类光电式传感器，用红光和红外光照射皮肤，通过检测血管搏动引起的透射光或反射光变化来还原脉搏波。它的优势很直接：模块便宜、体积小、焊接简单，I2C 接口直接挂在单片机上，算法在 MCU 里自己写，答辩时可以清楚解释每一个信号处理步骤，而不是把传感器当黑匣子用。

计步部分用 MPU6050 六轴传感器。它内置三轴加速度计和三轴陀螺仪，但计步只需要加速度数据，陀螺仪在静止时会有零漂，动态下又容易积分漂移，用于步数检测反而不如加速度计稳定。我一般会把陀螺仪关掉或忽略其输出，只读加速度寄存器，量程设成 ±2g，这个档位下分辨率达到 16384 LSB/g，走路和跑步的加速度变化范围完全覆盖得住。加速度计输出的是带重力分量的三轴数值，静止时合加速度约等于 1g，走路时会在 1g 附近上下波动，后面算法部分就是围绕这个特征展开的。

这套双传感器方案还有一个好处：两条数据链互不干扰。心率走 I2C 读 MAX30102 的 FIFO，计步走 I2C 读 MPU6050 的加速度寄存器，最后在应用层汇合。如果传感器换成了其他型号，比如用 ADXL345 做计步、用 BH1750 做环境光补偿，驱动层接口不变，只换底层读写函数，这正好体现了 C 语言工程分层的价值。

2.2 引脚分配与电路连接：I2C 总线上三个设备怎么共存

MAX30102、MPU6050、OLED 屏幕都支持 I2C，很多人第一反应是“三个设备挂一条总线会不会冲突”。不会，I2C 本来就是为了多设备共用总线设计的，只要每个设备的 7 位地址不重复就行。这套资源用的地址是：MAX30102 默认地址 0x57，MPU6050 的 AD0 引脚接地时地址 0x68，OLED 常见地址 0x3C 或 0x3D，三个地址互不重叠。接线时把所有 SDA 接到一起、SCL 接到一起，再统一上拉到 3.3V。

这里有一个容易被忽略的细节：I2C 总线必须接上拉电阻。STM32 的 I2C 引脚是开漏输出，不接上拉，SDA 和 SCL 拉不高，通信时序直接乱掉。大多数淘宝模块板载了上拉电阻，但如果你用的是自制板或某些最小系统板，外部要补两个 4.7kΩ 到 3.3V。总线上的设备越多，上拉电阻可以适当换小，比如 2.2kΩ，否则信号上升沿变缓，高速模式下面容易出错。这套资源里 I2C 速率配的是 400kHz 快速模式，实测三条设备共用一条总线没有问题，但布线时尽量让三条支路短一些，避免总线电容过大。

供电方面，三个模块都支持 3.3V，直接从 STM32 最小系统板的 3.3V 引脚引出即可。需要留意的是 MAX30102 的 LED 驱动电流比较大，峰值可达几十毫安，如果最小系统板上的 LDO 余量不足，LED 点亮瞬间会把 3.3V 拉低，表现为心率数据周期性跳变。常见做法是在 MAX30102 模块的电源引脚旁边加一个 10μF 钽电容和一个 0.1μF 陶瓷电容，分别吸收低频和高频纹波。

2.3 电源与去耦：传感器读数的第一道稳定关口

很多人在传感器数据和预期不符时，第一反应是改算法、调阈值，实际上有一半的问题出在电源上。MAX30102 内部有 LED 驱动电路，当 LED 以脉冲方式点亮时，瞬间电流会在电源线上产生毛刺，这些毛刺通过地线耦合进模拟前端，最终反映在 ADC 采样值里，表现为脉搏波形上多了很多高频毛刺。所以画 PCB 或面包板接线时，遵循三条原则：所有模块共地，避免形成地环路；每个 IC 的电源引脚就近放 0.1μF 去耦电容；长线供电时在入口处加大电容，比如 100μF 电解电容，稳住低频波动。

MPU6050 对电源的要求相对宽松，但如果加速度数据出现周期性漂移，先量一下 3.3V 纹波，再用示波器看 VDD 波形，比反复调算法阈值高效得多。我自己的习惯是先把电源和接线排查干净，再开始调算法。这套资源里只要按最小系统板 + 传感器模块的方式插接，供电问题一般不会太严重，真正影响大的是后面算法章要讲的信号处理和参数标定。

3. 算法与代码分层：PPG 波峰检测与三轴合加速度计步落地成 C

3.1 C 语言工程的目录与分层：驱动、算法、应用各归其位

打开这套资源的源码包，先看文件组织，就能看出工程素养。驱动层、算法层、应用层是分开的，没有把所有代码堆在 main.c 里。我建议复现时也保持这个结构，后面调试和答辩都好讲。

驱动层只做一件事：把传感器寄存器读写封装成函数，向上层屏蔽硬件细节。算法层接收驱动层返回的原始数据，经过滤波和判断后输出结果。应用层负责调度，比如定时器每 10ms 读一次 MAX30102，每 20ms 读一次 MPU6050，结果刷新到 OLED。这样的分层有一个实际好处：如果想把 MAX30102 换成 MAX30100，只需要改驱动层，算法层完全不动；想换 OLED 型号，也只需要改 oled.c 的初始化函数和显存写入函数。

很多初学者喜欢把传感器读取、数据处理、显示逻辑全写在一个 while 循环里，看起来代码很短，但一旦数据异常，根本分不清是读出来的值就不对，还是算法把它算错了。分层之后，你可以先在 uart_debug 里把原始 ADC 值打印出来，确认驱动没有问题，再去看算法逻辑，排查范围直接缩小一半。

3.2 心率脉搏算法：去直流、滑动均值、波峰检测与 BPM 换算

MAX30102 输出的原始数据是一个 18 位左右的 ADC 值，它包含两部分：一部分是组织对光的固定吸收，数值较大且变化缓慢，叫直流分量；另一部分是血管搏动引起的微小变化，幅度只有直流分量的百分之一左右，叫交流分量。我们要提取的脉搏波就在交流分量里，第一步就是把直流分量去掉。

常见做法是滑动均值滤波：维护一个最近 N 个采样点的窗口，每来一个新点就计算窗口平均值，把这个均值当作当前时刻的直流基线，原始值减基线就得到交流分量。窗口大小的选取有讲究，我在这套资源里看到并验证过的配置是采样率 100Hz、窗口取 50 个点，也就是 500ms 的窗口。这样窗口能覆盖呼吸引起的低频基线漂移，又不会把周期约 0.8 秒的脉搏波抹掉。

#define PPG_SAMPLE_RATE 100 /* 采样率 100 Hz，10ms 一个点 */ #define PPG_WINDOW_SIZE 50 /* 滑动窗口 500 ms，滤除低频基线漂移 */ #define PEAK_THRESHOLD 80 /* 交流分量阈值，需结合实际波形标定 */ #define PEAK_MIN_GAP_MS 300 /* 最小峰间隔，防止一个波峰重复计数 */ static uint16_t ppg_window[PPG_WINDOW_SIZE]; static uint8_t ppg_index = 0; static uint32_t ppg_window_sum = 0; static uint32_t last_peak_ms = 0; static uint16_t peak_count = 0; /* 每 10ms 由定时器回调一次，传入最新原始 ADC 值 */ void ppg_process_sample(uint16_t raw_value) { /* 更新滑动窗口和累计和 */ ppg_window_sum -= ppg_window[ppg_index]; ppg_window[ppg_index] = raw_value; ppg_window_sum += raw_value; ppg_index = (ppg_index + 1) % PPG_WINDOW_SIZE; uint16_t baseline = ppg_window_sum / PPG_WINDOW_SIZE; /* 直流基线 */ int16_t ac_signal = raw_value - baseline; /* 交流分量 */ uint32_t now_ms = HAL_GetTick(); /* 波峰检测：幅度超过阈值，且与上一个峰间隔足够远 */ if (ac_signal > PEAK_THRESHOLD && (now_ms - last_peak_ms) >= PEAK_MIN_GAP_MS) { last_peak_ms = now_ms; peak_count++; } } /* 每 10 秒调用一次，返回当前心率值 */ uint16_t ppg_get_bpm(void) { uint16_t bpm = peak_count * 6; /* 10 秒内 N 个峰，折算成每分钟心率 */ peak_count = 0; return bpm; }

逻辑说明：主循环或定时器中断每 10ms 调一次ppg_process_sample，把 MAX30102 的原始 ADC 值推进滑动窗口。ppg_window_sum维护窗口内所有采样点的和，减掉被覆盖的最老值、加上新值，再除以窗口长度得到基线，这样每采样一次只需做一次减法和一次加法，不会因为重复遍历窗口而消耗 CPU。PEAK_THRESHOLD的值不能随便定，要根据实际波形的交流分量幅度来标定，一般取安静状态下脉搏峰幅度的 60% 左右，太小会把噪声当波峰，太大又漏检。PEAK_MIN_GAP_MS设为 300ms 对应最高 200 次/分钟的心率，正常人运动时也很少超过这个频率，能有效防止一个峰被重复计数。

BPM 换算用的是“10 秒统计窗乘 6”的方法，这个方式简单直接，不会出现瞬时心率剧烈跳变的问现象。缺点是有 10 秒延迟，如果希望显示更跟手，可以改成记录相邻峰的时间间隔，用60 / ((t2 - t1) / 1000.0)实时计算，但单个间隔受噪声和运动干扰较大，我一般会取最近 5 个间隔的平均值再换算。这套资源里两种方法都有注释，按需求切换就行。

3.3 计步算法：合加速度、高通滤波、动态阈值与去抖窗口

计步的物理基础是人走路时身体质心会上下起伏，加速度计的三轴数据合成为一个矢量后，在重力加速度 1g 附近上下波动。直接对三轴分别判断再加起来算步数是不对的，因为手机或设备佩戴角度不同，同一脚落地时各轴的分量完全不同。正确做法是先算合加速度，再做滤波和阈值判断。

MPU6050 在 ±2g 量程下，每个轴的原始值是 16 位有符号整数，除以 16384 就得到以 g 为单位的实际加速度值。合加速度的公式是三个轴平方和开根号，静止时它等于 1g，走路时波形会在 1g 上下起伏，如图中那种规律性的毛刺波形。如果直接用原始合加速度做阈值，重力分量 1g 会把波动完全淹没，所以必须先滤掉重力分量。我用一阶高通滤波器实现这个效果。

typedef struct { int16_t ax; int16_t ay; int16_t az; } accel_data_t; #define ACCEL_SCALE 16384.0f /* ±2g 量程下的比例因子 */ #define HIGH_PASS_ALPHA 0.85f /* 高通滤波系数，越大截止频率越低 */ #define STEP_THRESHOLD 0.45f /* 加速度波动阈值，单位 g */ #define STEP_MIN_GAP_MS 250 /* 最小步间隔，对应最快步频 240 步/分钟 */ static float prev_norm = 1.0f; /* 上一次合加速度 */ static float prev_filtered = 0.0f; static uint32_t last_step_ms = 0; static uint16_t step_count = 0; uint16_t pedometer_update(accel_data_t *acc) { float norm = sqrtf(acc->ax * acc->ax + acc->ay * acc->ay + acc->az * acc->az) / ACCEL_SCALE; /* 一阶高通滤波：y[n] = a * (y[n-1] + x[n] - x[n-1]) */ float filtered = HIGH_PASS_ALPHA * (prev_filtered + norm - prev_norm); prev_norm = norm; prev_filtered = filtered; uint32_t now_ms = HAL_GetTick(); /* 向上越过阈值判定为一步，加最小间隔去抖 */ if (filtered > STEP_THRESHOLD && (now_ms - last_step_ms) > STEP_MIN_GAP_MS) { last_step_ms = now_ms; step_count++; } return step_count; }

逻辑说明：先用三轴加速度算出合加速度norm，静止站立时它稳定在 1.0g 附近。高通滤波器的输入是合加速度，输出是去掉了重力直流分量的波动信号，HIGH_PASS_ALPHA越大，能滤掉的低频成分越多，但也不能太大，否则把走路时约 1~3Hz 的主频也滤掉了，波形幅度明显衰减。这个值需要结合采样频率调整，在 50Hz 采样率下取 0.85 左右是常见做法。滤波后的信号会在走路时出现正负交替的波动，每次从负值向上越过正阈值时记一步。

STEP_MIN_GAP_MS取 250ms 对应最大步频 240 步/分钟，普通人快跑也就 180 步/分钟，这个限制可以防止同一个跨步被重复计数。阈值 0.45g 是我在这类项目里常用的起始值，但实际标定时不能照抄：把设备固定在手腕上匀速走动 30 步，观察滤波后波形的峰值幅度，取峰值的 50% 到 60% 作为阈值比较稳。走路和跑步的峰值差异很大，如果能做动态阈值，也就是每 3 秒更新一次最大峰值并取其中间值，效果会更好，但代码复杂度会上升，毕业设计用固定阈值加标定就能讲清楚。

3.4 两路数据怎么联动成“健康运动”信息

心率数据和步数单独显示只是两个数字，把这套系统定位成“健康运动”而不是单纯的心率计或计步器，关键在于联动逻辑。一个常见做法是将计步模块输出的步数和步频作为运动强度参考：静止时心率低于 80bpm，走路时升高到 100~120bpm，慢跑时到 130~150bpm。如果步频很高但心率上不去，或者心率异常高而步数几乎没变化，说明传感器或算法可能出了问题。

注意：运动时 MAX30102 受到加速度干扰，PPG 信号里会叠加大量运动伪影，心率数据会明显失真。这是所有光电心率传感器的通病，不是代码 bug。这套资源里对这个问题做了两层处理：一是运动幅度较大时，在显示界面上标注“运动干扰”，不刷新心率值；二是利用 MPU6050 的加速度数据做简单的运动状态识别，静止或走路时正常刷新心率，剧烈运动时等待信号恢复。这个联动逻辑是论文里可以重点展开的亮点，比单纯把两个模块拼在一起更有说服力。

代码层面就是应用层读步数判断运动状态，再决定要不要更新心率缓存：

if (step_count > last_step_count + 20) { /* 20 步内步数明显增加 */ heart_rate_valid = 0; /* 标记心率数据可能失真 */ disp_refresh_heart_rate(0); /* 显示 -- */ } else { heart_rate_valid = 1; disp_refresh_heart_rate(bpm); }

这样处理后，使用者走路时看到心率短暂显示“--”，停下来 3 秒左右恢复，反而更容易解释和演示。这个联动逻辑也直接影响后面的避坑方案，因为在安静状态下测试心率算法是准的，运动状态下就需要靠这套机制兜底。

4. CubeMX 到 Keil 的完整流程：时钟、I2C、串口与烧录参数一次配齐

4.1 时钟树与引脚复用：72MHz 主频和 400kHz I2C 怎么来的

把源码烧进板子之前，先过一遍 STM32CubeMX 的配置。这套资源的工程基于 STM32F103C8T6，外部晶振 8MHz，经过 PLL 倍频到系统主频 72MHz，这是 F103 的标称最高主频。打开 CubeMX 的 Clock Configuration 页面，能看到整条时钟树：HSE 8MHz 输入，PLL 源选择 HSE，倍频系数 9，得到 72MHz 的 SYSCLK；APB1 总线分频器设为 2，得到 36MHz；APB2 不分频，保持 72MHz。I2C1 挂在 APB1 上，所以它的输入时钟是 36MHz，要得到 400kHz 的 I2C 时钟，需要把 I2C 时钟配置里的快速模式参数设成相应的分频值，CubeMX 会自动计算，不需要手算寄存器。

这里有一个关键配置：调试接口默认是 JTAG 四线，占用了 PA13、PA14、PA15、PB3、PB4 这几个引脚。如果工程里要用到 PA15 或 PB3，必须在 SYS 页面把 Debug 从 JTAG 改成 Serial Wire，只保留 SWDIO（PA13）和 SWCLK（PA14）。改完之后，SWD 下载还能用，JTAG 接口失效。很多人后面下载报错，就是这一步没配对，又或者用了占用 PB3/PB4 的引脚却开着 JTAG，导致引脚冲突，代码烧进去后外设初始化失败。

串口部分用 USART1，引脚默认是 PA9（TX）和 PA10（RX），波特率 115200，8 位数据、无校验、1 位停止位，这是最通用的配置。TIM2 配成 1ms 向上计数溢出中断，HAL_GetTick()依赖 SysTick，而 TIM2 的中断用来驱动传感器采样节奏，两个定时器职责不同：SysTick 提供全局毫秒计数，TIM2 用更精确的周期触发采样回调。

4.2 Keil 工程组织与 printf 重定向

CubeMX 生成的工程导入 Keil 后，第一件事是检查 Device 型号有没有选对。很多人的 Keil 里装了 C51 和 MDK 两套环境，打开工程时如果默认选择了 C51 编译器，编译直接报一堆找不到头文件的错误。工程项目必须用 MDK 打开，并在 Options for Target 里确认 Device 是 STM32F103C8。如果 keil5 兼容 c51 和 stm32 安装的是同一个 IDE，切换方法是 Project → Manage → Project Items 里看编译器版本，MDK 会显示 ARM Compiler，C51 会显示 C51 Compiler，新建工程或打开工程时选择对应环境即可。

接下来改四个关键设置：C/C++ 选项卡里勾选 C99 标准，支持在 for 循环内声明变量；Target 选项卡里勾选 Use MicroLIB，让 printf 的浮点输出不需要完整 C 库支持，否则串口打印浮点数时 RAM 占用会暴涨；Optimization 选择 Level 2，平衡代码大小和运行速度；Include Paths 里把源码包的 Src、Inc、Core/Inc 这几个目录都加进去，漏掉任何一个编译都会报找不到 max30102.h 之类的错误。

printf 重定向是串口日志的基础。HAL 库环境下默认的 printf 不会输出到串口，需要自己重写fputc函数：

#include "stdio.h" /* 重定向 printf 到 USART1 */ int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 100); return ch; }

逻辑说明：C 库的printf最终通过fputc逐字节输出，这里把每个字节交给 HAL 库的串口发送函数。100是超时时间，单位毫秒，115200 波特率下发送 1 字节约 86 微秒，100ms 的超时足够宽裕，不会因为串口阻塞拖慢主循环。注意huart1这个句柄必须是 CubeMX 生成的全局变量名，如果工程里改过名字，这里的引用也要同步改。勾选了 MicroLIB 之后，不需要额外配置fgetc，但如果要用scanf接收串口数据，需要补一个fgetc的重定向。

4.3 ST-Link 下载与串口调试：从复位到看到第一行日志

烧录接线是 ST-Link 四根线：SWDIO 接 PA13，SWCLK 接 PA14，GND 共地，3.3V 接 ST-Link 的 3.3V 输出，给最小系统板供电也可以，但如果是独立供电，ST-Link 的 3.3V 不必接，避免两个电源打架。Keil 的 Flash Download 设置里，Programming Algorithm 要能识别到 STM32F10x 系列，Reset and Run 这个选项建议勾上，烧录完成后自动复位运行，省去手动按复位键的步骤。

第一次下载如果报Error: Flash Download failed - Target DLL has been cancelled，先不要怀疑芯片损坏，九成是连接问题。按这个顺序排查：确认 ST-Link 驱动安装成功，设备管理器里能看到 ST-Link 调试接口；确认 SWDIO 和 SWCLK 没有接反；确认目标板供电正常，3.3V 实测有电压；最后在 Keil 的 Settings 里点击 Debug 设置页，看能不能检测到芯片 ID。如果以上都不行，按住目标板复位键不放，点击下载后在弹窗出现瞬间松开复位，这一招对某些锁死状态的芯片很有效，属于嵌入式烧录圈的土办法，但确实能解决一部分奇怪问题。

串口调试建议在 main 函数初始化完成后，先打印一条固定的启动信息：

printf("System Init OK, Booting...\r\n"); printf("RAW:%d\r\n", raw_value); /* 打印传感器原始值 */ printf("BPM:%d STEP:%d\r\n", bpm, step_count);

串口助手的参数要和 CubeMX 配置一致：波特率 115200，数据位 8，停止位 1，无校验，无流控。收到System Init OK说明工程整体跑通；收不到但 OLED 正常显示，检查 CH340 驱动和串口线是不是公头母头接反；收到但乱码，检查波特率是否匹配，或者fputc重定向里发送的是不是无符号字节。日志格式固定为数值形式，后面 Python 脚本直接按字段解析，这也是我把原始数据和计算结果都打出来的原因，调试时可以实时对比原始波形和算法输出，不用反复改代码加打印。

5. 避坑排查：五个让数据乱跳或烧录失败的常见陷阱

5.1 I2C 读回全是 0xFF

现象：用 HAL 的 I2C 读 MAX30102 寄存器，返回数据全是 0xFF，怎么读都不对；示波器看 SCL 有波形，但 SDA 上的应答位异常。

原因：最典型的是 SDA/SCL 没有接上拉电阻，或者模块供电电压不对。开漏输出的 I2C 引脚必须靠外部上拉拉高，没有上拉时总线浮空，读回的数据自然全 1。另一个常见原因是寄存器读地址写错了，MAX30102 的 7 位地址是 0x57，作为 I2C 写地址要左移一位变成 0xAE，读地址是 0xAF，直接用 0x57 去 HAL_I2C_Mem_Read 会找不到设备。

解决：先用万用表测 SDA 和 SCL 对地电压，正常应该在 3.3V 附近；如果接近 0V，补两个 4.7kΩ 上拉电阻。然后写一个 I2C 扫描函数，遍历 0x01 到 0x7F 的所有地址，打印出有 ACK 应答的设备地址，确认 0x57、0x68、0x3C 三个设备都在总线上。这个扫描函数是所有 I2C 调试的第一板斧，比任何猜疑都高效。

5.2 OLED 白屏或花屏

现象：程序跑起来，OLED 背光亮但屏幕全白，或者显示乱码，内容完全对不上。

原因：OLED 的 I2C 地址跟硬件版本有关。大部分 0.96 寸 OLED 默认地址是 0x3C，但部分模组在背面有地址选择电阻，地址会变成 0x3D。如果驱动代码里写死 0x3C，初始化命令全部发给了错误设备，屏幕自然没有正常响应。另外，OLED 复位脚要在初始化前拉高，有些模块把 RST 引出来了，代码里没控制它，上电时序不对就会花屏。

解决：先用 I2C 扫描确认真实地址，再改工程里的 OLED_ADDR 宏。检查模块原理图，如果 RST 引脚可用，初始化代码开头加两行：拉低 RST，延时 10ms，再拉高。初始化之后让 OLED 先显示一个固定的版本号字符串，比如“System v1.0”，如果这个能正常显示，说明显示链路通的，后面再排查为什么其他页面花屏。

5.3 心率数值忽高忽低

现象：手指放在传感器上，心率从 60 跳到 140 再跳回 75，完全没有规律；安静坐着数值也在漂。

原因：MAX30102 的原始信号质量太差。常见诱因有三个：手指没有稳定贴合，接触压力不断变化导致直流基线剧烈跳动；环境光直射传感器，尤其是荧光灯和太阳光，会在 PPG 信号上叠加 50Hz 或 100Hz 工频干扰；波峰检测阈值设得太低，噪声幅度超过阈值后被当成脉搏峰计数。

解决：先看原始 ADC 波形再下结论。用串口把原始值打印出来，正常脉搏波应该是规律的、幅度稳定的起伏波，周期约 0.8 秒；如果波形上有大量尖刺，优先遮光处理，用黑色胶带把传感器周围挡住，再让手指稳定贴合。阈值调整方面，先记录安静状态下 10 秒内的波形最大幅度，把PEAK_THRESHOLD设为该幅度的 60%，同时确认PEAK_MIN_GAP_MS不小于 300ms。我遇到过最典型的案例是环境光干扰被当成脉搏波，功率计都救了回来，遮光后波形立刻干净了。不要一上来就改滤波算法增加复杂度，先把信号源头弄干净。

5.4 计步误触发：抖手也计数，走路反而不计数

现象：手腕快速抖动几下，步数蹭蹭往上跳；正常走路时却漏计很多步。

原因：阈值设得太低会把细小抖动算成一步，太高会把真实行走的加速度波动滤掉。另一个隐蔽问题是 MPU6050 的加速度数据没有归一化到重力单位 g 就直接参与阈值判断，原始 LSB 和阈值 0.45 完全不在一个量级上，会导致步数要么不减要么狂加。

解决：先在静止状态下打印合加速度值，确认它稳定在 16384 LSB 附近，也就是归一化后的 1.0g。然后原地走 30 步，在串口里看滤波信号的峰值范围。我记得有一次标定时峰值到 0.8g，阈值设 0.3g，结果每走一步被多记两次；把阈值改到峰值的 60% 即 0.5g 后，30 步正好 30 个峰。如果手部抖动幅度和走路幅度接近，可以在算法里加一条限制：两步之间的时间间隔在 300ms 到 1500ms 之间才计数，超出范围丢弃，这样能把快速抖动过滤掉大部分。

5.5 ST-Link 下载失败

现象：点击下载按钮，Keil 提示Cannot access Target或Flash Download failed - Target DLL has been cancelled，代码完全没有烧进去。

原因：最常见的是接线松动、目标板没有独立供电、或者芯片处于低功耗模式下调试接口被禁用。如果程序里进入了Stop或Standby模式，SWD 引脚功能可能被关闭，下载器连不上芯片，表现为擦除失败。

解决：先断掉一切可能的干扰源，只保留 ST-Link 的 SWDIO、SWCLK、GND 三根线，目标板用 USB 独立供电。在 Keil 的 Debug 设置里降低 SWD 时钟频率，从默认的 4MHz 降到 1MHz，可以缓解杜邦线过长带来的信号完整性问题。如果还是连不上，按住复位键不放，点击下载，在弹窗出现的瞬间松开复位，让芯片在复位状态下进入下载流程。这个方法屡试不爽，原理是复位期间内核停止执行，SWD 接口能与调试器建立连接。我后来习惯把电源管理相关代码注释掉再烧录，从根上避免低功耗模式锁死调试接口。

6. 用串口波形验证算法：Python 把原始 PPG 和步数画出来

调心率算法最忌讳不看波形直接调参数。BPM 是一个结果值，它只告诉你算出了多少，不告诉你算的过程有多离谱。把原始 PPG 信号和计步滤波信号用 Python 实时画出来，阈值标定和问题排查会直观很多，这也是我强烈建议复现这套资源后补做的一步。

串口输出格式已经约定好了：RAW:xxxx表示 MAX30102 原始 ADC 值，BPM:xx STEP:xx表示当前结果。Python 用 pyserial 读串口，按行解析，用 matplotlib 绘制滚动波形。

import serial import matplotlib.pyplot as plt ser = serial.Serial('COM5', 115200, timeout=1) ppg_vals = [] raw_window = 500 # 窗口 500 个点，即 5 秒波形 plt.ion() fig, ax = plt.subplots() while True: line = ser.readline().decode('utf-8', errors='ignore').strip() if line.startswith('RAW:'): val = int(line.split(':')[1]) ppg_vals.append(val) if len(ppg_vals) > raw_window: ppg_vals.pop(0) ax.clear() ax.plot(ppg_vals) ax.set_title('PPG Raw Signal') ax.set_ylabel('ADC Value') ax.set_xlabel('Sample @100Hz') plt.pause(0.05)

逻辑说明：串口波特率 115200，与 STM32 的配置保持一致。RAW:前缀让解析器只提取原始数据，不会和其他日志行混淆。窗口 500 个点对应 5 秒波形，既能看清脉搏波的周期性，又不会让绘图延迟太大。plt.pause(0.05)控制界面刷新率，配合 100Hz 的数据上报，画面滚动不卡顿。在 Linux 或 macOS 上，串口号要改成/dev/ttyUSB0或/dev/cu.usbserial-xxx。如果嫌实时绘图占 CPU，也可以把数据追加写入 CSV，跑完再统一分析。

波形画出来后，第一眼看峰值幅度是否稳定。脉搏波的峰值应该是规律的，幅度在几十到几百个 LSB 之间波动；如果波形是一条直线带毛刺，先查传感器贴合和遮光；如果波形幅度忽大忽小，查手指压力；如果波形像正弦波一样圆滑，说明窗口滤掉了太多高频成分，适当减少窗口长度。标定阈值时，直接在图上量峰值的平均值，然后按 60% 折算到代码里，比盲调靠谱一个量级。

计步信号也可以用同样方式验证，把滤波后的filtered值通过串口打出来后绘图，看每一步是否对应一个明显的正峰。如果波形里能数出 30 个峰而屏幕上显示 28 步，说明阈值或去抖参数还有问题；如果波形峰数都对不上，那就是传感器或滤波代码的问题。做这个项目时我有一个血泪经验：用手摇传感器测试计步算法，结果手抖的频率比走路快一倍，算法把所有抖动都当成步数，用软件滤波滤了半天都滤不干净，最后是把传感器绑在脚踝上验证才暴露了真正的问题。从那以后我每次改计步或心率参数，都强制先抓一组原始波形再动手，不盲调任何一个阈值。希望帮到你。

本文还有配套的精品资源，点击获取