01
引言
客戶在使用 BlueNRG-LP/LPS 芯片時,增加 OTA 服務后常常反饋說,編譯代碼區域超空間了,需要幫忙優化一下。后文主要通過下列步驟進行分析和優化 BlueNRG-LP/LPS 的代碼空間:
a. 通過分析 BlueNRG-LP/LPS 的 OTA 方式,讓客戶可以選擇合適的方式;
b. 通過整體分析 BlueNRG-LP/LPS 的鏈接文件(*.icf/*.sct/*.ld)了解默認工程的存儲分布;
c. 通過裁剪協議棧,選擇合適的協議棧功能,優化 BlueNRG-LP/LPS 的代碼空間;
d. 通過使用靜態協議棧,進一步優化 BlueNRG-LP/LPS 的代碼空間;
e. 其他方案;
總的來說通過兩個維度來節省空間:一個是協議棧的裁剪維度:主要是通過修改宏配置實現編譯對應應用需要的協議棧。另一個是 OTA 和靜態協議棧的維度:OTA 和靜態協議棧的選擇流程圖如下圖所示
02
BlueNRG-LP/BlueNRG-LPS的OTA
2.1 OTA 的框架
手機或者電腦做 GATT Client,給帶 OTA 服務的設備升級。
2.2 官方提供的 OTA 方式
默認提供的 OTA 應用和協議棧編譯在一個固件上。
a. 不帶備份的(右圖中的右半部分)
升級服務程序在 Boot 端(OTA Service manager)。
省空間(存放了 2 份協議棧,1 份應用)
管理簡單(只需管理一份應用)
b. 帶備份的(右圖中的左半部分)
升級服務程序在應用端
更消耗空間(存放了 2 份協議棧,2 份應用)
管理稍微麻煩(需要管理兩份應用,Lower 區域應用不能放置 Higher 區域運行)
更安全
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 中工程和配置如下圖所示:
a.BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager
b.BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用
2.3 使用帶備份類型 OTA 升級錯誤變磚頭問題
編譯器編譯的 Higher Application 如果放置在 Lower Application 的位置,程序無法運行。APP 程序可以知曉當前運行的固件是 Lower 還是 Higher APP??梢栽诰幾g固件 Higher Application 和 Lower Application 中加入一些標記,用于給升級工具識別,當前需要下載的是Higher Application 還是 Lower Application 或者是否混用。建議每次發布時兩個應用程序都編譯生成,不要人為來管理固件,否則容易造成混亂,應該讓升級 app 自動選擇對應的來升級。
03
BlueNRG-LP/LPS的存儲分析
3.1 linker 中宏定義作用范圍
Linker 中可定義一些宏、用于指定鏈接腳本文件所需的配置。這些宏定義不作用于.c文件或者.h文件,只作用于鏈接文件(.icf 或者.sct 或者 *.ld)。
3.2 鏈接腳本文件分析(代碼區域)
不同的 IDE 所使用的鏈接腳本文件的格式不同。比如,Keil 使用“*.sct”文件,IAR 使用“*.icf”文件,而 TrueStudio 使用 “*.ld”文件。
下面分析BlueNRG-LP最新SDK中BLE_SerialPort項目IAR工程目錄下的BlueNRG_LP.icf文件, 其他IDE一樣,可以進行類比。由于Flash的擦除必須是整頁操作的,寫Flash之前必須將對應的頁擦除,所以Flash的劃分需要2KB對齊。就算只使用到0.9KB,也需要劃分2KB區域。
默認SDK中提供了4種程序的鏈接配置:
CONFIG_OTA_HIGHER
CONFIG_OTA_LOWER
CONFIG_OTA_USE_SERVICE_MANAGER
其他
對于這四種鏈接配置編譯后,代碼區域放置在如下地址。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限制這個工程編譯的程序空間大小不能超過這個范圍。
如果在linker中沒有定義MEMORY_FLASH_APP_SIZE,則對應的4種配置分別是:
MEMORY_FLASH_APP_OFFSET: 定義程序編譯鏈接地址的偏移(非OTA程序)。如果在linker中沒有定義MEMORY_FLASH_APP_OFFSET,則對應的4種配置分別是:
前面提到默認SDK中提供了4種程序的鏈接配置,本質上只是計算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已,如果應用需要,也可以改動這個鏈接腳本文件。
04
通過協議棧的初步裁剪與自定義優化空間
SDK 中默認提供了 4 種默認配置的協議棧加一種自定義的協議棧配置(BLE_STACK_CUSTOM_CONF),如下圖所示。
上述 5 種不同協議棧的配置,本質上就是通過使用宏控制不同的特性功能是否打開。只是前面 4種提供了默認便捷的設置,而最后一種可以進行細粒度更細的自定義的協議棧。
可以在 Preprocesor Symbols 中定義相關的宏來配置使用哪種協議棧配置。
如果選用細粒度更細的 BLE_STACK_CUSTOM_CONF 協議棧配置,則在 其中在頭文件“custom_ble_stack_config.h”中開關不同功能特性,大致占用的代碼如下圖所示。
05
協議棧的進一步裁剪:使用靜態協議棧
5.1 靜態協議棧工程的 4 種默認的配置
ST 官方 SDK 中已經提供了靜態協議棧的 Demo,分為協議棧工程和應用工程兩部分,路徑為:C:Usersuser nameSTBlueNRG-LP DK 1.x.xProjectsBLE_ExamplesBLE_StaticStack 靜態協議棧工程默認提供了 4 種配置:
? Release
? Basic
? OTA_BTL_ResetManager
? OTA_BTL_ResetManager_Basic
C:Usersuser nameSTBlueNRG-LP DK 1.x.0ProjectsBLE_ExamplesBLE_SensorDemo_StaticStack
? Release
? LowerApp_OTA
? HigherApp_OTA
那它們有什么區別呢?它們可以分為兩組。
Release 和 Basic 是一組:它們運行時都是由協議棧程序直接跳轉到一個固定的應用上;
Release 和 Basic 的區別:Basic 的協議棧配置是 BLE_STACK_BASIC_CONF, 而 Release的協議棧配置是 BLE_STACK_FULL_CONF。
不同的協議棧配置,包含的功能和占用的 Flash 空間也不一致。
? 不同的協議棧配置包含的功能請查看 stack_user_cfg.h
? 占用的 Flash 空間可以通過編譯的 Map 文件查看? 宏 RESET_MANAGER_SIZE 用于協議棧程序的跳轉偏移,即預留多少空間給協議棧,因此這個宏的大小也會因為協議棧占用的空間不同而不同。
? Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定義程序可用的大小。即預留多少空間給協議棧,因此這個宏的大小也會因為協議棧占用的空間不同而不同。
OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一組:它們都是由協議棧程序跳轉到 Lower 應用程序或者 Higher 應用程序;
? OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的區別:OTA_BTL_ResetManager_Basic 的協議棧配置是 BLE_STACK_BASIC_CONF, 而OTA_BTL_ResetManager 的協議棧配置是 BLE_STACK_FULL_CONF
? 不同的協議棧配置,包含的功能和占用的 Flash 空間也不一致。
o 不同的協議棧配置包含的功能請查看 stack_user_cfg.h
o 占用的 Flash 空間可以通過編譯的 Map 文件查看
o 宏 RESET_MANAGER_SIZE 用于協議棧程序的跳轉偏移,即預留多少空間給協議棧,因此這個宏的大小也會因為協議棧占用的空間不同而不同。
o Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定義程序可用的大小。即預留多少空間給協議棧,因此這個宏的大小也會因為協議棧占用的空間不同而不同。
其中,一個工程負責生成協議棧,另一個工程負責應用,那么這里 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.2 將工程實例化為靜態協議棧工程編程基礎
將工程實例化為靜態協議棧涉及比較多的步驟,可以參考官方的文檔 :BlueNRG-LP_LPS DK 1.2.0ProjectsBLE_ExamplesBLE_SensorDemo_StaticStackREADME.txt
以及 SDK 安裝目錄的 index.html 中的靜態協議棧的介紹如下圖所示。
如果在實例化 OTA 程序時,可能需要修改鏈接腳本和 Preprocesor Symbols 中下面幾個宏(具體不同應用,不同 OTA 類型,具體需要定義的宏和宏的數值也不同):
RESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET
5.3 使用默認配置的協議棧
如果使用了 OTA,發現空間不夠,可以考慮將應用協議棧和 OTA 協議棧合并使用如下圖所示。
上圖列舉的是基于 BlueNRG-LP 的默認提供的工程的大致數值(BlueNRG-LPS 類似,這里不再舉例)。如果遇到不同的應用,可以實際裁剪協議棧適配不同的應用需求。
5.4 使用自定義配置的協議棧
使用靜態協議??梢詫崿F更為精確的函數級別的裁剪:通過注釋協議棧工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中對應的函數,編譯時可以將不使用的協議棧函數裁減出協議棧。
5.5 使用靜態協議棧這種模式如何支持升級協議棧
當使用靜態協議棧,默認協議棧就無法升級。為了能夠支持協議棧也升級。需要增加一段 boot代碼,當升級協議棧時,先放置在 APP 區域,當升級完協議棧后,將 APP 區域的協議??截惖絽f議棧區域。接著繼續升級被擦除的應用程序。Boot 代碼決定搬運協議棧和跳轉到下一級。
06
優化后空間仍不足的其他方法
如果使用靜態協議棧和空間仍然不足,可以考慮將一些常用而不需修改的通用模塊編譯進協議棧的工程。如果空間仍然差距比較遠則考慮用片外 Falsh 或者選用 STM32WB 系列,再或者使用 STM32+協處理器模式。
審核編輯:劉清
-
IAR
+關注
關注
5文章
324瀏覽量
36343 -
OTA
+關注
關注
7文章
544瀏覽量
34716 -
BlueNRG
+關注
關注
0文章
15瀏覽量
9620
原文標題:實戰經驗 | 簡談 BlueNRG-LP 和-LPS 的代碼空間優化
文章出處:【微信號:STM32_STM8_MCU,微信公眾號:STM32單片機】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論