note - bug fix - large data definition causes unstable ble connection

note - bug fix - large data definition causes unstable ble connection

1 功耗和数据量的关系

1.1 背景介绍

1.1.1 嵌入式软件链接段

通常 gcc 将 c语言编译为可执行文件或者二进制文件的过程分为：

• 预编译 - 将所有 include 包含内容替换为 .h，同时进行宏定义替换，得到 .c；
• 编译 - 将所有 .c 编译为 .s；
• 汇编 - 将所有 .s 汇编为可执行文件 .o；
• 链接 - 将不同 .o 链接为 .a 可直接执行，或者生成 bin 用于下载到嵌入式设备上执行。

通常链接阶段可自定程序分为以下几个段：

• text - 程序段，即 .c 中定义的函数；
• ro - read only，通常为 const 类型数据或直接自定的字符串；
• data - 数据段，在定义中直接有初值的数据，需存入生成的固件；
• bss - 数据段，在定义中为 0 或未初始化的数据，此段不需要存入生成的固件，上电需初始化为 0。

1.1.2 芯片启动流程

通常芯片上电后：

1. 读取 0 地址（通常为 reset 指令或地址），跳转到 reset；
2. 设置栈地址，准备 c语言 执行环境；
3. 初始化 data 段，将对应 flash 保存的 data 段 copy 到 sram 中；
4. 初始化 bss 段，初始化为0；
5. 跳转到 main，执行 c语言。

1.1.3 ble 连接简单介绍

ble（bluetooth low energy）为低功耗蓝牙，通常分为主从设备，central/peripheral;

• 连接：通常由 peripheral 发起广播，central 接收到广播选项是否连接、配对；
• 配对：通常由 central 主动发起，也可有 peripheral 主动请求，主要为加密设备交互；
• 交互：serve - client交互，peripheral 内置 gatt service table，为 sever 端，用于给 central （client 端）提供读写服务；
• 安全：配对过程通常包含 smp 实现数据传输加密；此外还有跳频算法防止 sniffer 抓包；此处较为复杂，可参考官方手册。

以上交互基于 2.4GHz 无线频段；通常 ble 有以下参数定义连接状态：

• interval - 连接间隔，例如10ms，即 central 与 peripheral 每 10ms 交互一次；
• latency - 潜伏时间，例 99，表示 peripheral 可连续 99 次不响应 central，但是第（latency+1）次需要响应，用于 peripheral 设备实现低功耗，注：latency 为 peripheral 可一段时间不响应，通常 central 每个 interval 还是会发送对包，这种做法可保证 peripheral 某次错过对包窗口，可于后续几个 interval 继续等到，找回连接；
• timeout - 超时时间，超过该参数定义的时间未对包，则视为超时断链，通常为 ((latency+1)*interval) 五倍以上，保证断链前有多次几率可以重新对包成功。

其中每次对包窗口通常为百 us 级。

为了实现低功耗蓝牙，以上述参数为例，interval=10ms，latency=99，timeout=5s，意味着 peripheral 需要每 （(99+1)*10ms=1000ms）对包一次即可，对包完成可进入休眠，在下次对包时间点前提前唤醒完成对包则可保持连接。

1.2 现象

当设备处于蓝牙连接状态时，功耗较 demo 比大了一至两倍，demo 通常为15uA，被测设备为50uA级，而且容易出现断链现象。

1.3 原因

由上述可知，为实现低功耗蓝牙，peripheral 每 1s 唤醒一次即可保持连接，连接窗口期通常为百 us 级，在 demo 设备中由于仅需实现 ble 相关功能，所以数据量较小，20k以内，定义提前唤醒时间 200us 即可；当数据量到了80k，导致唤醒阶段 copy data 和初始化 bss 段时间较长，导致直接 ble 对包函数时已错过窗口期，此时有两种可能：

1. 丢包为跳频节点，导致无法对上后续包，断链；
2. 软件处理中当丢失某一包，会保持唤醒等到后续连续几个 interval 回包，如果成功对包则找回连接。

由于数据量较大，导致低功耗唤醒耗时较长，导致错过 ble 对包窗口，轻则在后续几个 interval 中找回连接，但是增加几个 interval 功耗，可以与上述现象中，比 demo设备大上几倍功耗相对应，重则直接丢失连接。

1.4 解决办法

1. 软件开发至此，肯定无法大规模优化数据；但是存在部分数据可以每次在程序中通过软件进行初始化，如此可以在 link 阶段自定义一个 section，脱离于 data，bss 段，无需每次上电或者低功耗唤醒后都要初始化一遍；
2. 增加提前唤醒时间，每次都能完成对包并休眠，总比每次唤醒都要连续多个 interval 才能对包成功再休眠要好，所以适当增加提前唤醒时间，将功耗从15 uA 提高到 25uA 级别，可保证连接稳定性，同时满足功耗要求。

tips：简单估算以两节7号电池，800 mAh*2 = 1600 mAh为例，25uA 可保证设备在休眠状态下使用 1200/0.025=64000h=2666Days≈7years；不过此为休眠状态，算上正常使用状态、电池衰减等原因，通常满足一年以上使用情况即合格。