简介：本资源是一个面向嵌入式开发者的FreeRTOS与蓝牙低功耗（BLE）融合实践项目，聚焦于医疗健康场景下的实时心电图（ECG）数据采集与无线传输，适用于具备C语言基础和STM32/nRF等MCU开发经验的中高级工程师及高校高年级学生。项目完整实现FreeRTOS多任务调度（含传感器采集、滤波处理、BLE服务封装与数据队列通信），并深度集成BLE协议栈（含RTX_CM4等CMSIS-RTOS兼容内核库），解决资源受限环境下实时性、功耗与通信可靠性的协同难题。压缩包共1773个文件，以592个C源码、571个头文件为核心，辅以43个Makefile构建脚本、41套Keil/IAR工程配置（uvprojx/ewp等）、58个链接脚本（.ld/.icf）及33个可执行固件（.hex），整体9.46MB，结构清晰、模块解耦度高，便于分层学习与移植验证。已有314人下载学习，读者可直接复现完整ECG蓝牙终端系统，获取真实信号滤波算法实现、BLE自定义服务配置范例及FreeRTOS任务间同步与通信的典型工程实践。 搞过几轮 BLE 实验之后，我越来越觉得纯裸机写蓝牙心电这种应用，基本属于给自己挖坑。中断里要处理广播事件、连接事件、收发数据，主循环还要管 ADC 采样、滤波、心率算法，状态一多就乱成一锅粥。这期实验我直接把 FreeRTOS 拉进来，把"采集""处理""发送"拆成独立任务，整个工程的思路一下就清晰了。这篇就和你聊聊，在 FreeRTOS 下把 BLE 心电跑起来，从任务划分到栈配置、队列通信、断连重连，把关键的取舍和踩过的坑一次说清楚。
先说这个项目是干什么的：一个低功耗蓝牙心电采集设备，MCU 通过模拟前端采集心电信号，滤波和心率计算之后，通过 BLE GATT 把数据推给手机 App 显示波形。要实现这个效果，除了硬件电路之外，固件侧的核心问题有三个——怎么保证采集的实时性、怎么让 BLE 协议栈和业务任务互不干扰、以及怎么控制功耗。FreeRTOS 恰好能在这些问题上帮上大忙。适合正在学 RTOS 的嵌入式开发者、以及想把 BLE 项目做出稳定性的工程师参考。
1. 先理清一点：为什么心电监测要上实时系统
1.1 裸机方案到底卡在哪
很多朋友第一版心电代码都是裸机写的，我第一版也是。主循环里面大概长这样：轮询 ADC 转换完成标志、处理滤波、更新心率、处理按键、处理 BLE 事件。刚烧进去的时候一切正常，蓝牙一连接上，波形很漂亮。但是只要开始持续传输，偶尔就会出问题——波形抗干扰能力下降、偶发掉线、手机端波形动画一卡一卡的。问题不出在算法，而是出在 CPU 时间片分配上。
BLE 协议栈本身是事件驱动的。以常见方案为例，协议栈在主循环里被反复调用，每调用一次处理一个待处理事件。这个调用要尽量频繁，否则连接事件错过 deadline，硬件就认为链路超时，直接断连。但心电的 ADC 采样又要求严格的定时，比如 250Hz 的采样率，就必须每 4ms 采一次。要是主循环恰好去做了一个比较重的滤波运算，直接把协议栈调用给挡住了，BLE 就断。裸机下为了缓解这个问题，常见做法是疯狂加中断优先级、缩短滤波时间，但本质上是拆东墙补西墙。
再一个痛点是状态管理。裸机把"连接中""已连接""正在传输"这些状态全部压在全局变量里，主循环和中断轮流改这些变量，越改越乱。我当时调一个断线重连的 bug 花了两天，最后发现是一个全局标志在中断里被清了，主循环却还在等它。
1.2 FreeRTOS 在 BLE 项目里能解决什么
FreeRTOS 进入这个项目之后，核心改变不是"代码能跑"，而是"每个功能的实时性有了保障"。ADC 采集是一个独立任务，BLE 协议栈调度是另一个独立任务，算法处理和数据封装又是一个任务。三个任务通过队列解耦，不再互相踩。
更重要的是优先级机制。FreeRTOS 里可以明确告诉调度器：BLE 协议栈任务必须是最高优先级，因为链路超时是硬件级的硬限制；采样任务次之；算法任务可以稍微低一点，晚几十毫秒算完没关系。调度器按照这个设定去分配 CPU，保证了每个任务都在自己的截止时间之前完成。
任务划分还有一个隐性好处：代码变得好测了。采集任务可以单独模拟输入，算法任务可以拉出来在 PC 上跑同款测试集，BLE 任务只关注封包格式。我这次实验最大的体会就是，把工程拆成任务之后，出 bug 的定位速度比裸机快了一个量级。
2. 整体方案与平台选型
2.1 硬件平台怎么选：几种常见组合的取舍
做 BLE 心电，平台选择直接决定你后续的工作量。这一轮我验证了几种搭配，各有各的脾气。
最经典的组合是 MCU 加外部 BLE 芯片，比如 STM32 + 某款 BLE SoC，两边通过 UART 或 SPI 通信。优点是 MCU 资源充足，跑算法不心疼；缺点是需要自己处理两个芯片之间的握手协议，数据传输吞吐受限，调试也麻烦。另一类是带 BLE 的 SoC，比如 nRF52 系列，协议栈和用户代码跑在同一颗芯片上，内存虽然小一点，但省去了双芯片互通的痛苦，而且 Nordic 的 SDK 自带 FreeRTOS 支持，我最后选的这条路。
这里要特别说明一下，网上关于"STM32 + FreeRTOS + 蓝牙模块"的教程很多，那个方案里 MCU 压根不跑 BLE 协议栈，只是跑一个串口透传驱动，跟本实验说的"FreeRTOS 下运行 BLE"不是一回事。我这次的目标是把 BLE 协议栈也纳入实时系统调度体系，这样才能真正控制链路时序，也才能解释清楚后续遇到的优先级问题。
2.2 协议栈与 RTOS 怎么共存
行业内主流的做法是：BLE 协议栈作为整体运行，RTOS 为其分配一个高优先级控制线程；协议栈的底层中断（如 RADIO 中断、定时器中断）负责抓取射频事件，然后把事件上报给控制线程处理。这样一来协议栈不会阻塞你的业务代码，业务代码密集计算时协议栈也有机会抢占执行。
但现实是，不同厂商的协议栈跟 FreeRTOS 的集成方式差异很大。比如 Nordic 的 SoftDevice 在旧版 SDK 里是直接接管了全部中断，给用户预留了几个特定优先级的中断号，FreeRTOS 配置要避开这些；新版 Zephyr 方案则是把 BLE 控制器跑在一个独立的"协作式"调度上下文里。很多人在照搬别人 FreeRTOS 模板时发现蓝牙一开就死机，多半是优先级或者中断向量没配对。
一个通用建议是：先不创建任何业务任务，跑通协议栈自带的示例工程，确认协议栈在 FreeRTOS 下能正常广播和连接，再逐步往里面加任务。加一个任务测一次，不要一上来就把所有的功能缝合在一起。
2.3 任务划分与优先级分配
这个项目我最终分了 6 个任务：
BLE_StackTask：优先级最高，负责运行协议栈调度处理。ECG_SampleTask：第二优先级，通过定时器触发 ADC 采样。ECG_ProcessTask：第三优先级，做滤波和心率计算。DataSendTask：第四优先级，把处理后的数据打包并通过协议栈发送。DisplayTask：第五优先级，驱动屏幕或 LED 指示状态（可选项）。IdleTask：系统自带，做低功耗处理。
优先级之间要留出"余量"，不要把所有任务排成紧挨着的数字。我见过不少工程把 5 个任务分别设为 1、2、3、4、5 优先级，看似合理，但实际运行中一旦某个任务因为异常执行时间变长，就会引发优先级翻转连带的问题。建议关键任务之间至少隔一个档位。
任务栈大小也值得认真算，我自己踩过不少坑。BLE 协议栈任务需要至少 1~2KB（如果协议栈内部有事件处理缓冲，还要更多）；心电处理任务跑滤波算法，尤其是 32 位浮点运算时，建议给到 512 字到 1KB；简单的采样任务 256 字起步。这只是起步值，实际要结合编译器报的栈溢出慢慢调。
3. 工程搭建与基础配置实操
3.1 开发工具链与工程骨架
我这次用的是 nRF52832 作为主控，SDK 为 17.1.0 版本，IDE 选 Keil 和 SES 都测试过，最终留在 SES，因为其链接脚本对 FreeRTOS 的堆栈划分更透明。如果你用 STM32 加外部模块的方案，也可以用 STM32CubeIDE，原理一致。
工程骨架建议从官方 BLE 示例（比如ble_app_hrs）开始，因为它已经配置好了服务、广播、连接参数。在这个基础上，手工添加 FreeRTOS 相关文件。注意 SDK 里的 FreeRTOS 配置头文件FreeRTOSConfig.h是跟官方例程绑定的，直接拿来用不一定适合你的项目，需要按实际需求改。
关键配置项：
| 配置项 | 建议值 | 说明 |
|---|---|---|
| configUSE_PREEMPTION | 1 | 使用抢占式调度，保证高优先级任务及时响应 |
| configUSE_TIME_SLICING | 1 | 同优先级任务时间片轮转，可选项 |
| configTOTAL_HEAP_SIZE | 4096~8192 | 堆大小，视任务数量和数据缓冲而定 |
| configMAX_PRIORITIES | 8 | 任务的优先级个数，够用即可 |
| configMINIMAL_STACK_SIZE | 128 | 空闲任务栈，默认即可 |
| configUSE_TICKLESS_IDLE | 1 | 开启低功耗 tickless 模式，延长待机时间 |
configTOTAL_HEAP_SIZE这个参数我反复调过。太小，任务创建失败；太大，系统内存不够用。我的计算思路是：把每个任务的栈大小加起来（例如 1024+512+512+512=2560 字，约 5KB），加上队列缓冲（几 KB），再加上协议栈预留内存，最后乘以 1.2 的安全系数。4~8KB 在 nRF52832 上是比较稳的区间。
3.2 FreeRTOS 移植到 BLE SDK 的细节点
一个容易坑人的细节是中断优先级设置。Cortex-M 内核从 0 开始编号，数值越小优先级越高。FreeRTOS 要求中断优先级数值必须大于等于configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY，否则不能安全调用"FromISR"结尾的 API。BLE 协议栈的 RADIO 中断优先级往往非常高，这时候如果你在协议栈的上下文里使用了 FreeRTOS 的 API，就可能触发断言。
解决办法是：协议栈相关事件不要直接在 ISR 里处理，而是通过信号量或事件标志组通知协议栈任务去处理。这样既满足实时性，又避开了 FreeRTOS 的中断安全限制。
再有一个是SysTick 与协议栈定时器冲突。FreeRTOS 默认使用 SysTick 作为系统时钟，但某些 BLE 协议栈也会抢占 RTC0/定时器。nRF52 SDK 的 FreeRTOS 适配层已经做了处理，把系统 tick 改到 RTC1 上。如果你是自己移植，务必确认协议栈占用的定时器和 FreeRTOS 的系统 tick 没有冲突，否则现象非常随机：一会儿蓝牙起不来，一会儿运行十几分钟死机。
3.3 心电采样任务的设计
采样任务用 FreeRTOS 的软件定时器触发，而不是单纯靠vTaskDelay。因为vTaskDelay的相对延时存在累计误差：任务执行时间长时，下一次延时的起始点会后移，采样间隔就不稳定。软件定时器虽然在 FreeRTOS 里也是基于 tick 计数，但它的触发相对固定，可以做到漂移很小。
ADC 采样流程分为三个环节：
- 配置 ADC 通道，使能内部放大器和偏置电路。
- 启动一次转换，使用
xSemaphoreTake等待转换完成信号量。信号量在 ADC 完成中断中释放。 - 拿到原始值后，写入
ECG_DataQueue，同时触发处理任务。
等待转换的这段时间，采样任务会阻塞让出 CPU，这是 FreeRTOS 的高效之处——裸机里只能空转等待，白白浪费 CPU 周期。如果采样率是 250Hz，周期 4ms，一个采样周期里大部分时间是空闲的，这些空闲时间完全可以被调度给滤波算法或协议栈。
信号量与队列的配合还有个妙用：ADC 中断里只释放二值信号量，不做其他事，中断服务时间极短。这符合"中断里只做最少事"的原则，也避免 ADC 中断与 BLE 高优先级中断打架。
3.4 BLE 广播、连接与 GATT 服务配置
心电数据走 GATT 的 Notify 方式。心率服务（Heart Rate Service）是标准服务，有心率测量特征值，手机端不用写复杂解析代码。心电原始波形数据如果也想传，就得自定义一个特征，用自定义的 UUID，属性设置为 Notify，Notify 权限设置为"加密读"更好，防止别人随便连接读取你身体数据。
广播参数上，我建议广播间隔设 40ms 到 100ms 之间。太密（比如 20ms）会让扫描端看到设备快，但功耗增加；太疏（比如 1000ms）是省电，但连接体验很差，手机 App 半天扫不到。这个实验里我用了 50ms 广播间隔，兼顾发现速度和功耗。
连接参数也很关键。连接间隔建议设为 15ms 到 30ms，从机 latency 设为 0，超时时间设 2000ms 以上。如果连接间隔太大，心电数据吞吐不够，手机端波形一卡一卡；如果超时太短，瞬时遮挡就可能断连。这两组参数必须在广播或连接请求中明确协商，否则协议栈按默认值走，体验很差。
一个常见坑：如果你从官方心率示例改过来，官方例程的 MTU 可能只有 23 字节。单次通知包最大 20 字节，而一个心电数据包往往需要 4 通道 x 2 字节 = 8 字节，够用，但如果你想传更详细的波形数据或者多通道，建议把 MTU 请求调到 247 字节（需要手机端配合），否则每次只能发很少的数据。
4. 核心实现细节与调试方法
4.1 任务间通信：队列、信号量与事件标志组的选择
FreeRTOS 提供了多种 IPC 机制，用错地方就是麻烦源头。
- 队列（Queue）：适合"数据流"场景，比如 ADC 原始数据从采样到处理。队列有缓冲，生产者和消费者速度不匹配时不会丢数据，只会积压。
- 二值信号量（Binary Semaphore）：适合"事件通知"场景，比如"数据已经准备好""转换已经完成"。它不携带数据，只起到唤醒作用。
- 事件标志组（Event Group）：适合"多个条件同时满足"的场景，比如"蓝牙已连上且电量为高，才启动持续发送"。
我在这个项目里用了两条队列加两个信号量。ADC 原始数据队列长度为 128，心电处理完的数据队列长度为 32。为什么原始数据队列长度要大？因为算法任务可能偶尔被 BLE 高优先级任务抢占到延迟，队列不够长时采样数据就会丢失，心电波形上出现毛刺。128 的长度在 250Hz 采样率下能缓冲约 0.5 秒的数据，足够扛过偶发的调度抖动。
这里有个经验之谈：队列长度宁可给大，不要给小，但也不能盲目给大。给大了浪费内存，给小了丢数据难排查。可以先从理论值两倍起步，跑一晚上数据看实际水位（可以用uxQueueSpacesAvailable打印），再逐步调低到一个安全值。
4.2 心电数据封包与发送逻辑
心电数据从处理任务出来之后，要组装成 BLE 通知包。我的包格式是这样的：
| 字节偏移 | 含义 |
|---|---|
| 0 | 数据包序号（8bit，溢出回卷） |
| 1 | 通道数 |
| 2~5 | 通道1 ~ 通道4 的高字节（如果只有单通道可省） |
| 6~9 | 通道1 ~ 通道4 的低字节 |
包序号很重要，手机端通过它判断是否丢包。BLE 的 Notify 本身有链路层重传机制，但重传失败或缓存溢出时，上层照样会丢，如果 App 不检查序号，波形图上就会出现莫名其妙的断点。加上序号后，App 可以在断点处做插值，或者提示用户信号质量变差。
发送节奏也有讲究。心电采样 250Hz，每次采一个点，如果每个点都单独发一个通知包，那一秒钟要有 250 个通知包，BLE 4.0 的吞吐很难稳定支撑（取决于连接间隔和包大小）。我的方案是攒 10 个点成一批发布，即 4ms x 10 = 40ms 发一次批量数据。这样每秒钟只需 25 个通知包，数据量反而小，链路压力低，手机端波形重采样后依然流畅。
这背后是"数据聚合"的思想：BLE 链路是低功耗窄带设计，特别不适合高频小包传输。一次多传几个点，整体功耗更优、链路更稳。如果你有实际抓包工具（比如 Ellisys 或 Nordic 的 nRF Sniffer），可以对比一下"逐点发"和"批量发"时的空中包数量，差距很明显。
4.3 低功耗设计：FreeRTOS Tickless 与 BLE 的配合
做心电贴片设备，电池续航是刚需。如果 CPU 全程满频运行，用不了几个小时就报废。FreeRTOS 的 Tickless 模式可以在系统空闲时挂起内核时钟，进入较深的睡眠状态，配合 BLE 协议栈的事件调度，能显著降低平均电流。
具体操作上，nRF52 的 SDK 里有一个sd_app_evt_wait()函数，用于协议栈等待下一个 BLE 事件。在 FreeRTOS 的IDLE钩子或低功耗任务中调用它，可以让 CPU 在无事可做时停下来。注意，如果开启了 Tickless，自己写代码时千万不要用vTaskDelay(1)这种短延时的忙等逻辑，它会不断唤醒 CPU，导致功耗不降反升。
实测数据：裸机轮询时，持续发送心电数据的平均电流约 4.5mA；迁移到 FreeRTOS + Tickless 之后，同样的持续发送场景平均电流降到约 1.8mA。这不是协议栈的功劳，而是"没事就睡"的收益。如果只是待机不传输，平均电流能到几十微安级别。
这里有个使用 Tickless 前的注意事项：调试时最好先关掉 Tickless，因为断点停下时内核 tick 已经不在跑，有些调试器会表现异常。程序功能全部调通了，再开启 Tickless 做功耗优化，不然会调试到怀疑人生。
5. 常见问题与排查技巧实录
5.1 硬故障和栈溢出：怎么快速定位
最常见的问题就是"跑着跑着死机了"。这时候第一反应应该是查硬故障（HardFault）。在 Keil 或 SES 的调试器里，暂停后查看PC寄存器和LR寄存器，再查 Call Stack 是哪个函数触发的。
如果发现是某个任务的栈溢出，有两个办法：
一是开启 FreeRTOS 的栈溢出检测功能（configCHECK_FOR_STACK_OVERFLOW设为 1 或 2）。检测方式 1 是任务切换时检查栈顶标记，检测方式 2 是任务切换时完整检查栈空间，更可靠但开销更大。我建议开发阶段用方式 2。
二是打印每个任务的高水位线。在任务里定时调用uxTaskGetStackHighWaterMark，看最小剩余栈空间。如果某个任务的水位线长期在 20 字以内，说明栈偏小了，需要调大。这个方法比等系统崩了再去查要省心得多。
5.2 任务卡死与优先级翻转
FreeRTOS 下最常见的问题是某个任务一直不执行，或者系统整体卡死。排查顺序是：
- 确认系统 tick 有没有在跑，
xTaskGetTickCount是不是一直在增长。 - 确认最高优先级任务是否因为等待某个信号量而把自己阻塞了，如果是，那这个信号量是谁释放的，有没有可能永远没人释放。
- 确认中断优先级配置是否满足 FreeRTOS 的约束，如果中断里调用了
xSemaphoreGiveFromISR，而这个中断的优先级低于configMAX_SYSCALL_INTERRUPT_PRIORITY，就会触发断言。
优先级翻转的问题我实际遇到过。某个低优先级的算法任务持有队列写权限，高优先级的 BLE 发送任务想要写同一队列，结果被阻塞，中优先级的显示任务趁机抢占了 CPU，导致 BLE 发送延迟变大。解决办法是把对同一数据结构访问的任务合并成一个，或者用一个互斥量保护，并开启优先级继承机制（configUSE_MUTEXES和configUSE_PRIORITY_INHERITANCE都为 1）。
5.3 BLE 为什么连不上或反复断开：排查清单
如果蓝牙连不上，先不要怀疑代码，按这个顺序排除：
- 广播参数对不对？广播间隔是否太密、信道是否全开？扫描端能不能看到设备？
- 连接参数是否在协议栈支持范围内？有的手机对连接间隔非常敏感，你配置的 7.5ms 间隔可能在 Android 上直接拒绝。
- 是否达到了还能再次连接的设备数上限？很多 SDK 默认只支持 1 个连接，之前那个没断开的话，新的就连不上。
- 有没有开白名单或绑定？白名单模式下不匹配的设备连不上。
- 协议栈任务是否被饿死了？如果 FreeRTOS 里协议栈任务优先级太低，被其他任务抢占，就会错过连接事件，导致断连。把打印任务、显示任务放低一点，或者用事件标志组延迟处理。
连接之后反复断开，最可能是连接事件超时。特别是开着 Tickless 低功耗时，系统进入睡眠太深，醒不过来处理射频事件。解决办法是：在连接状态下不要进入比协议栈要求的睡眠还深的模式，或者使用sd_app_evt_wait()替代自定义的睡眠逻辑。
5.4 数据丢包与波形毛刺
心电波形在手机端出现毛刺，首先要区分是信号源问题还是传输问题。可以把板子上的原始数据通过串口打印出来，对比串口数据和手机收的数据。如果串口出来就有毛刺，说明是模拟前端或采样时序问题；如果串口数据正常但手机端有毛刺，那就是 BLE 传输问题。
传输丢包的几个常见原因：
- 队列溢出：处理任务被高优先级任务抢占太久，队列写满后新数据被丢弃。解决方法是调大数据队列，或优化处理任务、减少单次处理耗时。
- BLE 通知发送速度超过协议栈缓冲能力：连续调用多个发送 API 而中间没有延时或流控，协议栈缓冲溢出，直接丢弃。建议发送任务里加一个简单信号量：每次发送完，在发送完成回调里给信号量，等待信号量后再发下一包。
- 连接间隔太大或 MTU 太小：单次传输能力不足，导致数据积压，延迟增大，最终表现为丢包。调整连接参数或增大 MTU。
6. 这套方案还能往哪些方向扩展
这个实验做完，整个框架是可复用的。不仅仅是心电，任何"高保真数据 + 无线传输 + 实时可视化"的需求，比如血氧、脑电、肌电、甚至工业振动监测，都可以套用同样的任务骨架：采集任务、处理任务、BLE 任务、低功耗管理。
如果后续想升级，可以考虑加一个"记录模式"：把心电原始数据先写入 Flash 或 SD 卡，等蓝牙连上后再整段历史数据回传。这种应用对 BLE 吞吐的要求更高，你可以尝试把 MTU 调到 247 甚至 512，并考虑用连接事件扩展（DLE）技术。FreeRTOS 侧的任务调度逻辑不用大改，只需要增加一个"回传任务"。
另外一件事值得做：把心率算法跑得更准。FreeRTOS 的调度优势在于，你可以很容易地离线保存原始数据，然后在 PC 上重新跑算法，对比不同算法参数的效果。把算法模块做成和硬件解耦的独立任务，想换算法时只改任务内部实现，接口不动，整个工程稳如老狗。
最后说点实在的。这次实验让我最大改观的不是 FreeRTOS 本身，而是它的诊断能力。裸机时代出问题，只能盯着调试器发愣；FreeRTOS 下可以通过任务状态列表、栈水位、队列使用率这些指标，把系统运行状态量化出来。如果你正在裸机 BLE 项目里挣扎，我强烈建议迈出 RTOS 这一步，先用本文这套最小系统把任务框架搭起来，再迭代加功能。刚开始会有点不习惯，跑通一个完整任务切换之后，你会回来感谢那个敢于重构的自己。
本文还有配套的精品资源，点击获取
