|
01引言: t: G' \6 c T 客户在使用 BlueNRG-LP/LPS 芯片时,增加 OTA 服务后常常反馈说,编译代码区域超空间了,需要帮忙优化一下。后文主要通过下列步骤进行分析和优化 BlueNRG-LP/LPS 的代码空间: a. 通过分析 BlueNRG-LP/LPS 的 OTA 方式,让客户可以选择合适的方式;! }& `6 i! Y, p ]' u* Y c1 G3 C b. 通过整体分析 BlueNRG-LP/LPS 的链接文件(*.icf/*.sct/*.ld)了解默认工程的存储分布; c. 通过裁剪协议栈,选择合适的协议栈功能,优化 BlueNRG-LP/LPS 的代码空间;0 e% ^5 G% u7 \1 c/ }: P) w n i5 n d. 通过使用静态协议栈,进一步优化 BlueNRG-LP/LPS 的代码空间; e. 其他方案; 8 W! M- B/ r8 J& Z ) z4 {% J+ Z. S) b7 A
1 m/ x( t0 m+ } L# Q, t# v 总的来说通过两个维度来节省空间:一个是协议栈的裁剪维度:主要是通过修改宏配置实现编译对应应用需要的协议栈。另一个是 OTA 和静态协议栈的维度:OTA 和静态协议栈的选择流程图如下图所示 ! L9 z7 b9 n7 J6 c$ r 02BlueNRG-LP/BlueNRG-LPS的OTA 2.1 OTA 的框架 手机或者电脑做 GATT Client,给带 OTA 服务的设备升级。 4 [& ^3 i* Z, v$ `% F* {( e" P
2.2 官方提供的 OTA 方式( k$ d3 @) u! `- o 默认提供的 OTA 应用和协议栈编译在一个固件上。 a. 不带备份的(右图中的右半部分)* t- s: M) x, |/ q) Y: |4 @& F 升级服务程序在 Boot 端(OTA Service manager)。" x/ _6 B1 ?. U. N' A6 l 省空间(存放了 2 份协议栈,1 份应用)# N0 w7 Z8 \% ?+ d1 i; v 管理简单(只需管理一份应用)1 J9 a2 @2 s) H b. 带备份的(右图中的左半部分)) Z/ I- K( K3 g1 |; Q, o# L 升级服务程序在应用端) q& J4 m5 _* D, s9 S; z7 n# U 更消耗空间(存放了 2 份协议栈,2 份应用)6 H. N0 E* _' |- P 管理稍微麻烦(需要管理两份应用,Lower 区域应用不能放置 Higher 区域运行)3 K! I5 c$ Y& X1 k& k2 v9 j# r 更安全 7 _% Q, p9 l1 t# l
$ c* x. m9 r, o8 k9 {: `% w a. 不带备份的方式由以下组件构成: BLE_OTA_ServiceManager+ application b. 带备份的由以下组件构成: BLE_OTA_ResetManager +Lower Application (with BLE OTA service) orBLE_OTA_ResetManager + Higher Application (with BLE OTA service) 对应在 SDK 中工程和配置如下图所示:+ y+ k8 \8 w' G6 E8 W a.BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager b.BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用 2 r3 V% c" Z6 l
) x9 ^0 X* o/ y. W$ K0 L 2.3 使用带备份类型 OTA 升级错误变砖头问题% ^5 y+ h' \# e4 @2 ^5 Y 编译器编译的 Higher Application 如果放置在 Lower Application 的位置,程序无法运行。APP 程序可以知晓当前运行的固件是 Lower 还是 Higher APP。可以在编译固件 Higher Application 和 Lower Application 中加入一些标记,用于给升级工具识别,当前需要下载的是Higher Application 还是 Lower Application 或者是否混用。建议每次发布时两个应用程序都编译生成,不要人为来管理固件,否则容易造成混乱,应该让升级 app 自动选择对应的来升级。( ]7 I$ e1 \4 T2 w 9 x4 d0 @6 C( }/ ^ - X# _$ _8 [- { N7 M& A# m
+ z% }. E* Z# z' X0 E7 ~ 03BlueNRG-LP/LPS的存储分析 3.1 linker 中宏定义作用范围 Linker 中可定义一些宏、用于指定链接脚本文件所需的配置。这些宏定义不作用于.c文件或者.h文件,只作用于链接文件(.icf 或者.sct 或者 *.ld)。 . w. e! N& d5 q 3.2 链接脚本文件分析(代码区域)! H8 h8 i$ r9 T/ N 不同的 IDE 所使用的链接脚本文件的格式不同。比如,Keil 使用“*.sct”文件,IAR 使用“*.icf”文件,而 TrueStudio 使用 “*.ld”文件。 7 U/ h, {, s! m" ^- k3 w: B 下面分析BlueNRG-LP最新SDK中BLE_SerialPort项目IAR工程目录下的BlueNRG_LP.icf文件, 其他IDE一样,可以进行类比。由于Flash的擦除必须是整页操作的,写Flash之前必须将对应的页擦除,所以Flash的划分需要2KB对齐。就算只使用到0.9KB,也需要划分2KB区域。+ p c5 _: z4 T% W# I 0 i' W6 K) b) _# d$ }4 q v 默认SDK中提供了4种程序的链接配置:8 K7 {7 s$ F9 f7 g9 q 1.CONFIG_OTA_HIGHER0 N& C; v& j2 @4 ` 2.CONFIG_OTA_LOWER 3.CONFIG_OTA_USE_SERVICE_MANAGER 4.其他
1 n( l7 M8 I' Q+ O$ h4 D9 R 对于这四种链接配置编译后,代码区域放置在如下地址。BLE_OTA_ServiceManager 工程使用的是非 OTA 程序,而 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager 工程使用的是CONFIG_OTA_USE_SERVICE_MANAGER。
上述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限制这个工程编译的程序空间大小不能超过这个范围。 * b/ I! G* O( v, B( s 如果在linker中没有定义MEMORY_FLASH_APP_SIZE,则对应的4种配置分别是:2 |/ p+ D0 {! r. G
MEMORY_FLASH_APP_OFFSET: 定义程序编译链接地址的偏移(非OTA程序)。如果在linker中没有定义MEMORY_FLASH_APP_OFFSET,则对应的4种配置分别是: ! u' {* [9 K4 C6 b! E7 W9 Q
前面提到默认SDK中提供了4种程序的链接配置,本质上只是计算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已,如果应用需要,也可以改动这个链接脚本文件。' m. {5 C d0 g+ e- s. ` 04通过协议栈的初步裁剪与自定义优化空间 SDK 中默认提供了 4 种默认配置的协议栈加一种自定义的协议栈配置(BLE_STACK_CUSTOM_CONF),如下图所示。 $ Q# P! Z# A3 O& r4 z
f6 z/ v9 D7 u$ ]8 I1 x0 r5 B 上述 5 种不同协议栈的配置,本质上就是通过使用宏控制不同的特性功能是否打开。只是前面 4种提供了默认便捷的设置,而最后一种可以进行细粒度更细的自定义的协议栈。 可以在 Preprocesor Symbols 中定义相关的宏来配置使用哪种协议栈配置。 - d, G: U5 B, ^+ C0 s" x6 a
如果选用细粒度更细的 BLE_STACK_CUSTOM_CONF 协议栈配置,则在 其中在头文件“custom_ble_stack_config.h”中开关不同功能特性,大致占用的代码如下图所示。 5 m2 r9 l/ r5 \$ H/ `8 F
$ B* z l( `7 o( a% V1 j 05协议栈的进一步裁剪:使用静态协议栈 5.1 静态协议栈工程的 4 种默认的配置; X8 g' P( R, m& Z3 m) N ST 官方 SDK 中已经提供了静态协议栈的 Demo,分为协议栈工程和应用工程两部分,路径为:C:\Users\user name\ST\BlueNRG-LP DK 1.x.x\Projects\BLE_Examples\BLE_StaticStack 静态协议栈工程默认提供了 4 种配置:0 Y; r9 @6 D* V" V • Release • Basic • OTA_BTL_ResetManager2 F: Z( J) Y9 Q j c' @ • OTA_BTL_ResetManager_Basic C:\Users\user name\ST\BlueNRG-LP DK 1.x.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack2 R/ J) p9 X& Y N • Release • LowerApp_OTA/ ]( \) P8 r$ ^# C1 H) L/ P • HigherApp_OTA4 ?2 P0 ^8 ]: d: ^5 q' H( x6 H6 J - T9 z( E* {. x
+ d l4 e3 a0 V: U4 R& F 那它们有什么区别呢?它们可以分为两组。, s1 o+ T+ x5 e/ V: k \ Release 和 Basic 是一组:它们运行时都是由协议栈程序直接跳转到一个固定的应用上;0 E# ]( ?7 O+ Q1 M% z, t3 w! I( U6 d Release 和 Basic 的区别:Basic 的协议栈配置是 BLE_STACK_BASIC_CONF, 而 Release的协议栈配置是 BLE_STACK_FULL_CONF。 9 ~! Y# ]8 ]7 X7 t4 A6 L: L% ~ 不同的协议栈配置,包含的功能和占用的 Flash 空间也不一致。 • 不同的协议栈配置包含的功能请查看 stack_user_cfg.h3 C- {- o7 ^5 S* s# |, C2 _) m# y • 占用的 Flash 空间可以通过编译的 Map 文件查看• 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移,即预留多少空间给协议栈,因此这个宏的大小也会因为协议栈占用的空间不同而不同。 • Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈,因此这个宏的大小也会因为协议栈占用的空间不同而不同。 OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一组:它们都是由协议栈程序跳转到 Lower 应用程序或者 Higher 应用程序; % t( R& A3 M8 x% Z( q0 e" e • OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的区别:OTA_BTL_ResetManager_Basic 的协议栈配置是 BLE_STACK_BASIC_CONF, 而OTA_BTL_ResetManager 的协议栈配置是 BLE_STACK_FULL_CONF ' J& J+ d0 U- F! R1 w • 不同的协议栈配置,包含的功能和占用的 Flash 空间也不一致。( B& L4 s. u9 P+ `' x1 i o 不同的协议栈配置包含的功能请查看 stack_user_cfg.h o 占用的 Flash 空间可以通过编译的 Map 文件查看 o 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移,即预留多少空间给协议栈,因此这个宏的大小也会因为协议栈占用的空间不同而不同。) s& v$ X1 S: ~( Z( y9 d7 W) ` o Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈,因此这个宏的大小也会因为协议栈占用的空间不同而不同。 其中,一个工程负责生成协议栈,另一个工程负责应用,那么这里 BLE_StaticStack 中的Release or Basic 与 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic 怎么和Release,LowerApp_OTA 和 HigherApp_OTA 组合呢?; E1 F) X. V2 ]9 U c* i • BLE_StaticStack 中的 Release or Basic + BLE_SensorDemo_StaticStack 中的Release //不带备份 OTA 的使用固定协议栈的方法# S* D; g5 R6 I3 Z0 F) `% G • BLE_StaticStack 中的 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic + BLE_SensorDemo_StaticStack 中的 LowerApp_OTA or HigherApp_OTA //带备份OTA 的使用固定协议栈的方法 / b, ^" d3 a$ x" E, b 5.2 将工程实例化为静态协议栈工程编程基础 将工程实例化为静态协议栈涉及比较多的步骤,可以参考官方的文档 :BlueNRG-LP_LPS DK 1.2.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack\README.txt 以及 SDK 安装目录的 index.html 中的静态协议栈的介绍如下图所示。 ) i6 k- U8 P0 h% [) H
: y1 x& L- R7 x" C9 v, t8 [9 Q 如果在实例化 OTA 程序时,可能需要修改链接脚本和 Preprocesor Symbols 中下面几个宏(具体不同应用,不同 OTA 类型,具体需要定义的宏和宏的数值也不同): . }$ x M9 \2 ^% ^* Q+ G& H 0 m) P# p- F3 B/ v/ o! x b RESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET& r5 g- i4 \* a! A. m7 X 5.3 使用默认配置的协议栈 如果使用了 OTA,发现空间不够,可以考虑将应用协议栈和 OTA 协议栈合并使用如下图所示。
上图列举的是基于 BlueNRG-LP 的默认提供的工程的大致数值(BlueNRG-LPS 类似,这里不再举例)。如果遇到不同的应用,可以实际裁剪协议栈适配不同的应用需求。) r% @8 x8 ~; L/ {' f 5.4 使用自定义配置的协议栈4 s k1 F2 v$ P$ c X- \9 A 使用静态协议栈可以实现更为精确的函数级别的裁剪:通过注释协议栈工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中对应的函数,编译时可以将不使用的协议栈函数裁减出协议栈。7 w# M1 n, G3 Q6 Q% Q/ J# P
8 d7 j0 Y2 r* z& P" u; h5 e 5.5 使用静态协议栈这种模式如何支持升级协议栈" S& ~) ?% S* e5 L2 e+ d% W0 L+ V! r1 Y 当使用静态协议栈,默认协议栈就无法升级。为了能够支持协议栈也升级。需要增加一段 boot代码,当升级协议栈时,先放置在 APP 区域,当升级完协议栈后,将 APP 区域的协议栈拷贝到协议栈区域。接着继续升级被擦除的应用程序。Boot 代码决定搬运协议栈和跳转到下一级。
' I& u# y& ?; d8 C% ?5 _, @2 o 06优化后空间仍不足的其他方法 如果使用静态协议栈和空间仍然不足,可以考虑将一些常用而不需修改的通用模块编译进协议栈的工程。如果空间仍然差距比较远则考虑用片外 Falsh 或者选用 STM32WB 系列,再或者使用 STM32+协处理器模式。( f# Q+ y; B- ]! S1 A 7 g) C* d7 r, w H. E0 { M 转载自:记帖 如有侵权请联系删除% r. C8 I( f! E ! [# s3 h; }4 d |
微信公众号
手机版