前言
像眾多的ble供應商,沁恆的ble同樣提供BLE協議棧與應用部分代碼分離方式
適用芯片:
- CH573/CH571
適配SDK版本
| SDK版本 | 支持情況 |
|---|---|
| CH573_EVT 1.2 | 支持 |
| CH573_EVT 1.3 | 支持 |
| CH573_EVT 1.4 | 支持 |
優缺點
- 優點
- OTA時候不需要帶協議升級,這樣可以把應用做的很小,幾十KB,甚至是幾KB
- 在一些小資源的芯片上做OTA成為可能
- 缺點
- 協議不容易做升級(實現起來復雜)
- 燒錄繁瑣,需要多個hex文件合並后再燒錄
准備工作
清楚認識不同芯片存儲區域映射
| 芯片 | code flash地址映射 | RAM地址映射 | 備注 |
|---|---|---|---|
| CH571 | [0x0000,0x30000) 192KB | [0x20003800,0x20008000) 18KB | |
| CH573 | [0x0000,0x70000) 448KB | [0x20003800,0x20008000) 18KB |
協議棧的FLASH存放存放位置,以及RAM需求地址
- FLASH: 0X10000-0x30000,從芯片flash的64KB開始,長度共128KB
- RAM: 0x20003800-0x20004800,從ram的0地址起始,前面4KB 固定空出來
- 不同的版本的,起flash/ram占用的起始地址,和大小可能會有所差異,依實際的sdk里面的說明為准
另外:0x20004800 以后需要仍然需要分配一個RAM區域給協議棧用,我們可以直接聲明一個數組數組即可,按照工程默認設置即可
修改工程
修改宏
把宏"CH57xBLE_ROM"加到工程的全局宏里面:
替換文件
把工程中的Ld文件夾,Stratup文件夾移除,然后使用本blog 附件部分的對應文件夾替換.
RAM地址配置
RAM 在上面拷貝過來的Link.ld文件中修改
這里RAM對應的就是工程的RAM設置
其中0x20003800 開始的4K 需要固定為協議棧保留,我們空出來,
app部分直接從0x20004800 開始
實際上,這里要為協議棧空出MEM_BUF 的空間,跟ch579 中一樣,默認程序中直接聲明一個大數組,ble初始化時候傳進去就好了,這里我們就不改了.
MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20004800, LENGTH = 14K
}
FLASH地址配置
同樣是在上面拷貝過來的Link.ld文件中,FLASH 也是需要在這里定義,
這里由於庫占用了64K-192K 的區域,(可以通過本blog 末提供的工具hexinfo.exe 來查看)
針對ch573 我們64K之前可以用,192K以后可以用
flash 的定義也是在
MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20004800, LENGTH = 14K
}
代碼修改
無需修改
編譯
編譯后,固件大小一般在10KB左右
燒錄
1,通過 wchisp工具燒錄
(燒錄教程見:https://www.cnblogs.com/iot-fan/p/13498088.html)
wchisp燒錄建議合並后再燒錄,
使用附件提供的工具 mergehex.exe 把編譯出的app固件跟協議棧固件合並后,再通過wch_isp工具進行燒錄
合並
mergehex.exe -m app.hex CH579BLE_ROM.hex -o all.hex