|
01引言+ r* X7 `. L8 T. S! I3 W1 k 客户在使用 BlueNRG-LP/LPS 芯片时，增加 OTA 服务后常常反馈说，编译代码区域超空间了，需要帮忙优化一下。后文主要通过下列步骤进行分析和优化 BlueNRG-LP/LPS 的代码空间：1 j$ M7 h) ^. _& S7 r a. 通过分析 BlueNRG-LP/LPS 的 OTA 方式，让客户可以选择合适的方式；) b: d" o1 V- |% l; e. }/ z* W0 @% Y$ x b. 通过整体分析 BlueNRG-LP/LPS 的链接文件（*.icf/*.sct/*.ld）了解默认工程的存储分布；" Z8 ^3 r1 O3 I3 I' p c. 通过裁剪协议栈，选择合适的协议栈功能，优化 BlueNRG-LP/LPS 的代码空间； d. 通过使用静态协议栈，进一步优化 BlueNRG-LP/LPS 的代码空间； e. 其他方案； 6 V. t/ P6 [6 u. S- _- g- n 
. }* U+ e7 o4 r% e1 [3 k' S 总的来说通过两个维度来节省空间：一个是协议栈的裁剪维度：主要是通过修改宏配置实现编译对应应用需要的协议栈。另一个是 OTA 和静态协议栈的维度：OTA 和静态协议栈的选择流程图如下图所示0 Q, q, e) H% v- f 02BlueNRG-LP/BlueNRG-LPS的OTA 2.1 OTA 的框架3 h' U0 _5 P7 s8 |: n+ m% o9 l 手机或者电脑做 GATT Client，给带 OTA 服务的设备升级。6 y- O. E6 R' Q. q+ z# D' y 3 w/ |' b8 S$ Z 
; u7 K' `2 ~* J! ~$ L4 C0 F0 S I 2.2 官方提供的 OTA 方式/ M K0 K! _8 a# V3 [ 默认提供的 OTA 应用和协议栈编译在一个固件上。3 @* ]+ F( w9 d8 }- y a. 不带备份的(右图中的右半部分): N. S# {5 w) P, P' ]0 w 升级服务程序在 Boot 端(OTA Service manager)。 省空间（存放了 2 份协议栈，1 份应用） 管理简单（只需管理一份应用）- X2 |- d' V q% K r5 w b. 带备份的(右图中的左半部分) 升级服务程序在应用端 更消耗空间（存放了 2 份协议栈，2 份应用） 管理稍微麻烦（需要管理两份应用，Lower 区域应用不能放置 Higher 区域运行）% b& D Y3 J6 R* Q3 ` 更安全 8 D. N& f V9 @4 d 
5 p2 ?2 i& X) s4 o9 z( y a. 不带备份的方式由以下组件构成：9 e5 s% {0 w& D- @$ ^4 i/ J) {$ \ BLE_OTA_ServiceManager+ application b. 带备份的由以下组件构成： BLE_OTA_ResetManager +Lower Application (with BLE OTA service) orBLE_OTA_ResetManager + Higher Application (with BLE OTA service) h* k) X3 v6 x) t8 g 对应在 SDK 中工程和配置如下图所示：% x( w5 a; Q1 A* J" V a.BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager b.BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用0 n, ?* w( h% t $ G5 p3 A# p( `) A& J, s+ z 
: f. \* t, r- g- b9 i( a 2.3 使用带备份类型 OTA 升级错误变砖头问题* o9 i1 f: P$ o) N! i y 编译器编译的 Higher Application 如果放置在 Lower Application 的位置，程序无法运行。APP 程序可以知晓当前运行的固件是 Lower 还是 Higher APP。可以在编译固件 Higher Application 和 Lower Application 中加入一些标记，用于给升级工具识别，当前需要下载的是Higher Application 还是 Lower Application 或者是否混用。建议每次发布时两个应用程序都编译生成，不要人为来管理固件，否则容易造成混乱，应该让升级 app 自动选择对应的来升级。 ' v2 k- t8 O8 [: Q# M. _ 
# t! ^6 w+ x* G$ z; ` u7 O: y- S+ q8 a, h 9 V% t$ A: ?/ K5 [8 Y 03BlueNRG-LP/LPS的存储分析 3.1 linker 中宏定义作用范围& j i; z; c( I4 `7 J0 u Linker 中可定义一些宏、用于指定链接脚本文件所需的配置。这些宏定义不作用于.c文件或者.h文件，只作用于链接文件（.icf 或者.sct 或者 *.ld）。 9 s, b4 D* `! X( l i ; F; ?( Z2 S5 Z: ? 3.2 链接脚本文件分析（代码区域）) W) j( C3 X _0 K+ W6 a 不同的 IDE 所使用的链接脚本文件的格式不同。比如，Keil 使用“*.sct”文件，IAR 使用“*.icf”文件，而 TrueStudio 使用 “*.ld”文件。 & y6 c! D3 n; u& l* |0 T+ T 8 s7 i1 F# D. g' x4 ` 下面分析BlueNRG-LP最新SDK中BLE_SerialPort项目IAR工程目录下的BlueNRG_LP.icf文件, 其他IDE一样，可以进行类比。由于Flash的擦除必须是整页操作的，写Flash之前必须将对应的页擦除，所以Flash的划分需要2KB对齐。就算只使用到0.9KB，也需要划分2KB区域。( o4 \5 o6 n6 W3 S. Z7 h9 {' O! D 默认SDK中提供了4种程序的链接配置: 1.CONFIG_OTA_HIGHER5 ~4 f8 y( @. \" k% W 2.CONFIG_OTA_LOWER- U1 z, h9 A/ J9 C6 H5 l% q 3.CONFIG_OTA_USE_SERVICE_MANAGER 4.其他" V% `+ d- u8 G: R1 ?; y+ o3 p 
* K. B9 R: k1 S6 f; \ 对于这四种链接配置编译后，代码区域放置在如下地址。BLE_OTA_ServiceManager 工程使用的是非 OTA 程序，而 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager 工程使用的是CONFIG_OTA_USE_SERVICE_MANAGER。 9 x# i0 q" k; i1 }6 U7 ] 
上述4种程序的链接配置由以下宏定义来指定：MEMORY_FLASH_APP_SIZE: 定义程序使用Flash的大小。以工程BLE_OTA_ServiceManager为例子，在linker中定义了MEMORY_FLASH_APP_SIZE = 0x3000, 则表明BLE_OTA_ServiceManager的大小不能超过0x3000（12*1024） 字节。BLE_OTA_ServiceManager是一个带OTA服务的启动程序，宏定义MEMORY_FLASH_APP_SIZE限制这个工程编译的程序空间大小不能超过这个范围。# v( ^3 I4 W' e- d 如果在linker中没有定义MEMORY_FLASH_APP_SIZE，则对应的4种配置分别是： 
7 Q( c4 z7 o/ x$ X MEMORY_FLASH_APP_OFFSET: 定义程序编译链接地址的偏移（非OTA程序）。如果在linker中没有定义MEMORY_FLASH_APP_OFFSET，则对应的4种配置分别是： \& D7 W; g0 y& l: G1 Z 
4 W& I2 z/ J/ a2 [9 O9 y9 O 前面提到默认SDK中提供了4种程序的链接配置，本质上只是计算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已，如果应用需要，也可以改动这个链接脚本文件。: x; r6 g i! t% Z2 w/ ^ b) ~: J3 ^5 z9 ^5 t2 g+ r- M6 v; L w1 s5 V+ B* H( S9 o7 c: k 04通过协议栈的初步裁剪与自定义优化空间+ W6 P% b( K6 d) h" X+ z0 p- | SDK 中默认提供了 4 种默认配置的协议栈加一种自定义的协议栈配置（BLE_STACK_CUSTOM_CONF），如下图所示。 & d5 K2 O2 f9 G' S$ s% B. c 
. S6 P3 {9 K, V, |! S 上述 5 种不同协议栈的配置，本质上就是通过使用宏控制不同的特性功能是否打开。只是前面 4种提供了默认便捷的设置，而最后一种可以进行细粒度更细的自定义的协议栈。 . l7 R: `0 K( @ 可以在 Preprocesor Symbols 中定义相关的宏来配置使用哪种协议栈配置。" x. K4 E0 |! g* q' g! b 5 x, U/ x4 P5 a1 Q9 E 
如果选用细粒度更细的 BLE_STACK_CUSTOM_CONF 协议栈配置，则在 其中在头文件“custom_ble_stack_config.h”中开关不同功能特性，大致占用的代码如下图所示。' z+ X' _9 \' B 
g: H- S% f* t* C, Y6 h; j# U 05协议栈的进一步裁剪:使用静态协议栈 5.1 静态协议栈工程的 4 种默认的配置% S% l, R7 l- ]( @7 J( m! u+ o1 y9 W ST 官方 SDK 中已经提供了静态协议栈的 Demo，分为协议栈工程和应用工程两部分，路径为：C:\Users\user name\ST\BlueNRG-LP DK 1.x.x\Projects\BLE_Examples\BLE_StaticStack 静态协议栈工程默认提供了 4 种配置：4 V, ^ u9 r+ `$ F# ]% p3 b, L: x- ~ • Release • Basic • OTA_BTL_ResetManager- f% B# f# e% V1 E) h • OTA_BTL_ResetManager_Basic " L. }* R, E6 _3 v6 D: Y C:\Users\user name\ST\BlueNRG-LP DK 1.x.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack" X! N+ V: t- `( W# H) S& q6 G/ ^* @ • Release • LowerApp_OTA • HigherApp_OTA( \& \6 O9 k6 r7 U/ Y) m; \ 8 _ |) H) o H 
; H: \4 P1 L+ l; o- b+ m* B$ D; W 那它们有什么区别呢？它们可以分为两组。 i# l! P% \# S4 F, u% u Release 和 Basic 是一组：它们运行时都是由协议栈程序直接跳转到一个固定的应用上；0 j7 q; k& s8 n; O8 U" S* G Release 和 Basic 的区别：Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而 Release的协议栈配置是 BLE_STACK_FULL_CONF。8 }8 m5 f! U% J" U; ^0 V5 b" N ) {! z8 X/ J" v" j! i1 Q+ R 不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。/ Y" a% A& C0 O7 ]' D • 不同的协议栈配置包含的功能请查看 stack_user_cfg.h • 占用的 Flash 空间可以通过编译的 Map 文件查看• 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。 • Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。 - Q, A2 |9 h* S2 f) ~, f1 }, H OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一组：它们都是由协议栈程序跳转到 Lower 应用程序或者 Higher 应用程序； % }( U, i1 \2 U' }1 D6 a% e7 S/ S • OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的区别：OTA_BTL_ResetManager_Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而OTA_BTL_ResetManager 的协议栈配置是 BLE_STACK_FULL_CONF) r0 R* X i3 T& w • 不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。) x c% E3 S" O" S! {% I9 P o 不同的协议栈配置包含的功能请查看 stack_user_cfg.h o 占用的 Flash 空间可以通过编译的 Map 文件查看 o 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。 o Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。 ( K" u, K, r; t/ ?" J 其中，一个工程负责生成协议栈，另一个工程负责应用，那么这里 BLE_StaticStack 中的Release or Basic 与 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic 怎么和Release，LowerApp_OTA 和 HigherApp_OTA 组合呢？ • BLE_StaticStack 中的 Release or Basic + BLE_SensorDemo_StaticStack 中的Release //不带备份 OTA 的使用固定协议栈的方法 • BLE_StaticStack 中的 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic + BLE_SensorDemo_StaticStack 中的 LowerApp_OTA or HigherApp_OTA //带备份OTA 的使用固定协议栈的方法 ' _5 m3 ^6 Y6 y% I 5.2 将工程实例化为静态协议栈工程编程基础 将工程实例化为静态协议栈涉及比较多的步骤，可以参考官方的文档 :BlueNRG-LP_LPS DK 1.2.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack\README.txt! q, n* @8 s- R+ f" i % Y; i3 a2 ?5 E. A! d 以及 SDK 安装目录的 index.html 中的静态协议栈的介绍如下图所示。3 Q; Z$ F1 z0 T) u$ i % @6 M/ s5 L( s! S 
如果在实例化 OTA 程序时，可能需要修改链接脚本和 Preprocesor Symbols 中下面几个宏（具体不同应用，不同 OTA 类型，具体需要定义的宏和宏的数值也不同）： 1 L0 h- Y8 s3 U RESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET " l7 h' m3 X9 R* ]% ^6 y2 c 5.3 使用默认配置的协议栈 如果使用了 OTA，发现空间不够，可以考虑将应用协议栈和 OTA 协议栈合并使用如下图所示。: X( u. C. u! G9 G 
# w* D8 j! W: I 上图列举的是基于 BlueNRG-LP 的默认提供的工程的大致数值（BlueNRG-LPS 类似，这里不再举例）。如果遇到不同的应用，可以实际裁剪协议栈适配不同的应用需求。 5.4 使用自定义配置的协议栈 使用静态协议栈可以实现更为精确的函数级别的裁剪:通过注释协议栈工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中对应的函数，编译时可以将不使用的协议栈函数裁减出协议栈。 ! A. @% N* r1 N4 y 
5.5 使用静态协议栈这种模式如何支持升级协议栈/ n, l. p7 o | s/ W 当使用静态协议栈，默认协议栈就无法升级。为了能够支持协议栈也升级。需要增加一段 boot代码，当升级协议栈时，先放置在 APP 区域，当升级完协议栈后，将 APP 区域的协议栈拷贝到协议栈区域。接着继续升级被擦除的应用程序。Boot 代码决定搬运协议栈和跳转到下一级。 * N6 J( L; U3 E1 l8 i/ O8 P 
06优化后空间仍不足的其他方法 如果使用静态协议栈和空间仍然不足，可以考虑将一些常用而不需修改的通用模块编译进协议栈的工程。如果空间仍然差距比较远则考虑用片外 Falsh 或者选用 STM32WB 系列，再或者使用 STM32+协处理器模式。 . i9 C& H0 r9 M% B* W# c% \ 转载自：记帖5 S* I! c' K$ T, A: B 如有侵权请联系删除3 |8 \2 L3 `( y * u1 p" t, T- f& N8 f 0 x# I9 f6 f N1 d9 K0 X- z1 ` |
微信公众号
手机版
