1. 项目缘起与整体方案拆解
1.1 为什么选 RA4M2 搭配 DA14531 这套组合
手头这个项目最初的诉求很朴素：一块主控板要采集几路传感器数据，然后把这些数据实时发到手机上显示，同时手机端还能下发几条控制指令回来。说白了就是双向透传，只不过链路是 BLE 而不是经典蓝牙串口。
选型阶段我对比过几种常见做法。一种是主控直接挂一个 HC-05 之类的经典蓝牙模块，走 SPP 协议，开发确实简单，但功耗高、手机端兼容性越来越差，尤其是 iOS 对 SPP 基本关门。另一种是主控自己带 BLE 射频，比如某些集成度高的 SoC，但这类芯片往往把射频和协议栈绑死，调试起来黑盒感很强。最后落到RA4M2 + DA14531这个组合，核心原因是分工清晰：RA4M2 负责业务逻辑和传感器采集，DA14531 专职跑 BLE 协议栈，两者之间用UART这条最朴素的链路连接。
RA4M2 是瑞萨 RA 系列里偏主流的一颗 Cortex-M33，主频 100MHz，带 TrustZone，外设资源对一般的数据采集场景绰绰有余。DA14531 则是 Dialog（现属瑞萨）的 BLE 5.1 SoC，号称当时世界上最小的 BLE 方案之一，功耗极低，官方 SDK 里自带完整的 GATT、GAP 协议栈和一堆例程。把这两颗芯片拼在一起，本质上是把“应用处理”和“无线通信”解耦，各干各擅长的事。
提示：这种“主控 + 独立 BLE 模块”的架构，在工业采集、穿戴设备、智能家居节点里非常常见。它的最大好处是 BLE 部分可以单独升级、单独认证，主控固件不用跟着射频协议栈一起改。
1.2 整体数据流长什么样
先把数据流讲清楚，后面所有代码和配置都是围绕这条链路展开的。
手机 App 通过 BLE 连接 DA14531，DA14531 把收到的数据从 BLE 特征值里取出来，通过 UART 发给 RA4M2；反过来，RA4M2 把要上报的数据通过 UART 发给 DA14531，DA14531 再塞进 BLE 通知（Notify）里推给手机。整条链路是全双工的，两个方向可以同时跑。
这里有个关键点：DA14531 在中间其实扮演了一个“翻译官”的角色，它不关心数据内容是什么，只负责把 BLE 的字节流和 UART 的字节流互相搬运。这种设计叫透传，好处是主控端完全不用懂 BLE 协议，手机端也完全不用懂 UART，两边各说各的话，中间有人翻译。
1.3 方案选型背后的几个取舍
第一个取舍是波特率。DA14531 的 UART 在低功耗模式下速率有限，我最终定在 115200。这个速率对传感器数据（几十到几百字节每秒）完全够用，而且和大多数调试工具默认速率一致，省得来回改。如果你要传音频或者大批量固件，那得往上提到 921600，但那样 DA14531 的功耗会明显上升。
第二个取舍是流控。理论上 UART 加 RTS/CTS 硬件流控最稳，但 DA14531 的引脚本来就紧张，我实测在 115200 下不加流控，只要主控端发送时注意节奏，基本不会丢包。所以最终没接流控，省了两根线。
第三个取舍是MTU 大小。BLE 默认 ATT MTU 是 23 字节，实际可用载荷 20 字节。如果每次只发 20 字节，数据一多就会频繁分包，效率低。我在连接后主动发起 MTU 协商，把它提到 247，这样单次通知能带 244 字节，透传效率提升非常明显。
2. 硬件连接与 UART 底层配置
2.1 引脚对接与电平确认
RA4M2 和 DA14531 之间的 UART 连接，说白了就是四根线：TX、RX、GND，外加可选的 VCC。交叉接法是铁律——RA4M2 的 TX 接 DA14531 的 RX，RA4M2 的 RX 接 DA14531 的 TX，GND 必须共地，否则电平参考不一致，收到的全是乱码。
电平这块要特别注意。RA4M2 的 IO 电压取决于它的供电域，常见是 3.3V；DA14531 也是 3.3V 逻辑，所以两者可以直接对接，不需要电平转换。但如果你用的是 5V 主控，那就必须加电平转换芯片，直接怼上去会把 DA14531 的 IO 打坏。
我实际用的引脚分配是这样的：
| 信号 | RA4M2 引脚 | DA14531 引脚 | 说明 |
|---|---|---|---|
| UART TX | P410 | P0_5 | 主控发，模块收 |
| UART RX | P411 | P0_4 | 主控收，模块发 |
| GND | GND | GND | 必须共地 |
| VCC | 3.3V | VBAT | 供电，注意电流余量 |
注意：DA14531 在发射瞬间电流会有尖峰，供电走线要粗一点，旁边并一个 10uF 加 0.1uF 的电容，否则容易出现连接上了但一发数据就掉线的情况。这个坑我踩过，排查了半天以为是协议问题，结果是电源纹波。
2.2 RA4M2 侧 UART 初始化要点
RA4M2 用的是瑞萨的 FSP（Flexible Software Package）配置工具，UART 外设叫 SCI。配置的时候有几个参数必须和 DA14531 侧严格一致，否则通信必挂：
- 波特率：115200
- 数据位：8
- 停止位：1
- 校验位：None
- 流控：None
在 FSP 里新建一个 UART 栈，选好通道，把上面参数填进去，生成代码后调用R_SCI_UART_Open打开。这里有个细节，接收我建议用中断 + 环形缓冲区的方式，而不是轮询。因为 BLE 数据到达是异步的，轮询要么浪费 CPU，要么响应不及时。
环形缓冲区的实现思路很简单：开一个固定大小的数组，一个写指针给中断用，一个读指针给主循环用。中断里每收到一个字节就写进去并移动写指针，主循环里判断读写指针不相等就说明有数据可读。这样即使主循环在忙别的事，也不会丢字节。
#define UART_RX_BUF_SIZE 512 static volatile uint8_t rx_buf[UART_RX_BUF_SIZE]; static volatile uint16_t rx_wr = 0; static volatile uint16_t rx_rd = 0; void uart_callback(uart_callback_args_t *p_args) { if (p_args->event == UART_EVENT_RX_CHAR) { uint16_t next = (rx_wr + 1) % UART_RX_BUF_SIZE; if (next != rx_rd) { rx_buf[rx_wr] = (uint8_t)p_args->data; rx_wr = next; } } }这段代码里next != rx_rd的判断就是防止缓冲区写满后覆盖未读数据。缓冲区大小我给了 512，对透传场景足够，如果你数据量大可以再放大。
2.3 DA14531 侧 UART 配置
DA14531 的 SDK 里 UART 配置相对固定，主要改波特率和引脚映射。它默认的 UART 引脚不一定是你板子上引出来的那两个，需要在user_periph_setup.h里改UART_TX_PIN和UART_RX_PIN的宏定义。
波特率设置有个坑：DA14531 的 UART 时钟源分频计算比较特殊，SDK 里给了一个UART_BAUDRATE_115200的宏，直接用就行，别自己算。我曾经试图手动改分频寄存器，结果波特率偏了 3%，通信时好时坏，折腾了很久才发现是分频系数取整误差。
DA14531 的 UART 接收同样建议用中断或者 DMA，不要在主循环里死等。它的 SDK 提供了uart_receive的回调注册机制，收到数据后触发回调，你在回调里把数据往 BLE 的发送缓冲里塞。
3. BLE 服务与特征值设计
3.1 透传服务怎么定义
BLE 的数据交互全靠 GATT 里的服务和特征值。透传场景最省事的做法是自定义一个服务，里面放两个特征值：一个用来手机写、模块读（下行），一个用来模块写、手机读/订阅（上行）。
我用的是 128 位自定义 UUID，没有用蓝牙 SIG 定义的标准 UUID，因为标准里没有现成的透传服务。UUID 随便生成两个不冲突的就行，手机端和模块端保持一致即可。
| 角色 | 属性 | 方向 | 用途 |
|---|---|---|---|
| 下行特征值 | Write / Write Without Response | 手机 → 模块 | 手机下发指令 |
| 上行特征值 | Notify | 模块 → 手机 | 模块上报数据 |
下行我同时开了 Write 和 Write Without Response。带响应的写更可靠，但每次都要等 ACK，速度慢；不带响应的写快，但丢了不知道。实际用的时候，控制指令用带响应的，大批量数据用不带响应的。
3.2 通知（Notify）的开启流程
上行数据要能推到手机，必须让手机先“订阅”这个特征值，也就是往 CCCD（客户端特征配置描述符）里写 0x0001。这个动作是手机端 App 发起的，模块端要做的就是在 CCCD 被写入时记录下订阅状态，只有订阅了才发通知，否则发了也白发。
DA14531 的 SDK 里，CCCD 的写事件会在gatt_write_req回调里体现，你判断 handle 是不是那个上行特征值的 CCCD，然后置一个标志位。这个标志位在发送通知前必须检查，我见过有人不检查直接发，结果手机没订阅，数据全丢，还以为是 UART 的问题。
3.3 MTU 协商与数据分包
前面提到默认 MTU 是 23，我主动协商到 247。协商的发起方可以是手机也可以是模块，我选择在模块端连接建立后主动发起att_mtu_exchange。协商成功后，单次通知的最大载荷从 20 字节变成 244 字节。
但要注意，即使协商成功，也不是所有手机都买账。有些安卓机型会拒绝或者回一个较小的值，所以发送端必须根据实际协商结果动态调整每次发送的长度，不能写死 244。我的做法是维护一个current_mtu变量，发送时按current_mtu - 3来切分数据。
4. 双向透传的完整实现
4.1 下行链路：手机到主控
下行数据的路径是：手机写特征值 → DA14531 收到写请求 → 通过 UART 转发给 RA4M2 → RA4M2 解析处理。
DA14531 在gatt_write_req回调里拿到手机写来的数据，直接调用 UART 发送函数把它吐出去。这里有个细节：如果手机写得很快，而 UART 发送又比较慢，回调里可能会阻塞。我的处理是把要发的数据先丢进一个发送队列，回调里只负责入队，真正的 UART 发送在另一个上下文里做。
RA4M2 这边收到数据后，先判断是不是完整的帧。透传场景下我建议加一个简单的帧头帧尾或者长度字段，否则粘包了没法区分。我用的是最朴素的“长度 + 载荷”格式，第一个字节是长度，后面跟对应字节数的数据。
4.2 上行链路：主控到手机
上行路径反过来：RA4M2 通过 UART 发数据 → DA14531 收到 → 塞进通知推给手机。
DA14531 的 UART 接收回调里，把收到的数据攒起来，然后调用gatt_notify推送。这里必须检查前面说的订阅标志位，没订阅就丢弃。另外，如果一次 UART 收到的数据超过当前 MTU 能承载的长度，要分多次通知发送。
RA4M2 侧发送就简单了，把要上报的数据按帧格式打包，调用 UART 发送即可。但要注意发送节奏，别一股脑全怼出去，DA14531 的接收缓冲有限，发太快会溢出。我的做法是每帧之间留一点间隔，或者等 DA14531 回一个流控信号。
4.3 关键参数与实测数据
我把实测的几个关键数据整理成表，方便你对照：
| 参数 | 设定值 | 实测表现 |
|---|---|---|
| UART 波特率 | 115200 | 稳定，无丢包 |
| BLE MTU | 247 | 协商成功，载荷 244 |
| 连接间隔 | 30ms | 延迟与功耗平衡 |
| 单次通知载荷 | 244 字节 | 手机端正常接收 |
| 连续透传速率 | 约 8KB/s | 满足传感器场景 |
连接间隔这个参数值得说一下。它决定了手机和模块多久通信一次，间隔越小延迟越低但功耗越高。30ms 是我在响应速度和功耗之间找到的平衡点，如果你做的是实时控制，可以降到 15ms；如果是电池供电的采集节点，可以放宽到 100ms 以上。
5. 常见问题与排查实录
5.1 连不上、连上就断
这是最高频的问题。排查顺序我总结成一张表：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 搜不到设备 | 模块没启动 / 广播没开 | 查供电、查广播配置 |
| 连上立刻断 | 供电不足 / 参数不匹配 | 示波器看电源纹波 |
| 连上但无服务 | GATT 数据库没建对 | 用调试 App 看服务列表 |
| 能连能读不能写 | 特征值权限没开 | 检查 Write 属性 |
供电问题我要单独强调。DA14531 发射时电流尖峰能到十几毫安，如果供电走线细或者电容不够，电压瞬间跌落就会导致复位断连。我最初的板子就是这个问题，后来在模块电源脚旁边加了 10uF 电容才解决。
5.2 UART 收到乱码
乱码九成是波特率不一致或者地没共。先确认两边波特率、数据位、停止位、校验位完全一致，再确认 GND 确实连上了。如果都对了还乱码，用示波器或者逻辑分析仪抓一下 TX 线上的波形，量一下位宽，反推实际波特率，看是不是晶振或者分频的问题。
还有一种情况是电平不匹配。3.3V 和 5V 混接，高电平识别错误，也会乱码。这种必须加电平转换，别心存侥幸。
5.3 数据丢包
丢包分两种：UART 丢和 BLE 丢。
UART 丢包通常是接收缓冲溢出，解决办法是加大缓冲、用中断接收、加流控。BLE 丢包通常是没订阅就发通知，或者发送太快超过了连接间隔能承载的量。我的经验是，如果每秒发送的数据量乘以 8 再除以连接间隔，得到的瞬时速率超过了链路能承受的上限，就一定会丢。
5.4 手机端兼容性差异
安卓和 iOS 在 BLE 行为上有不少差异。iOS 对连接参数管得很严，你请求的连接间隔它不一定给；安卓相对宽松但各家 ROM 又有自己的脾气。MTU 协商也是，iOS 一般能给到 185 左右，部分安卓能给 517，但也有只给 23 的。
应对策略就是不要假设，所有参数都以协商结果为准，代码里做动态适配。我吃过亏，一开始按 244 写死发送长度，结果换了个手机全乱套，后来改成读协商结果才稳定。
6. 调试工具与效率技巧
6.1 抓包看 BLE 交互
调 BLE 最有效的工具是抓包。手机端可以用一些 BLE 调试 App 直接看服务、特征值、读写通知，非常直观。如果想看空口交互，需要专门的抓包设备配合分析软件，能看到连接建立、MTU 协商、每一次读写的完整过程。
抓包最大的价值是确认数据到底有没有发出去。很多时候你以为是模块没发，抓包一看其实发了，是手机端没处理；或者反过来，手机写了但模块没收到。这一步能省掉大量瞎猜的时间。
6.2 串口调试助手
UART 这边，一个趁手的串口调试助手是必备的。我习惯用能同时显示 HEX 和 ASCII 的，方便对照。调试透传的时候，我会在 RA4M2 侧和 DA14531 侧各接一个串口，中间用逻辑分析仪或者双通道串口工具监听，这样数据在每一段的表现都清清楚楚。
6.3 分阶段验证的思路
不要一上来就调整个链路。我的做法是分三段验证：
- 先单独调通 RA4M2 的 UART 收发，用串口助手对发。
- 再单独调通 DA14531 的 BLE，用手机 App 读写特征值。
- 最后把两段接起来，调透传。
这样任何一段出问题都能快速定位，不会出现“整条链路都不通但不知道哪坏了”的尴尬。
7. 一些实操心得
透传看着简单，但真正做稳定了要处理的细节不少。我最大的体会是缓冲和流控这两个词贯穿始终。UART 有缓冲，BLE 有缓冲，两边速率不匹配的时候，缓冲就是救命稻草，但缓冲也会满，满了就得有流控或者丢弃策略。
另一个体会是参数一定要动态适配。MTU、连接间隔、甚至每次发送的长度，都不能写死。手机型号千差万别，写死的代码在你这台手机上跑得好好的，换一台就出问题。
最后分享一个小技巧：在透传数据里加一个自增的序号字段。这样一旦丢包，你能立刻从序号跳变看出来丢了多少、丢在哪，排查效率比盲猜高太多。这个字段占一个字节，成本极低，但价值极高。
