nRF5340（入门篇）之1.3 nRF5340开发平台之NCS入门

  

编辑

nrf5340开发指南汇总

---

目录

​​1.什么是NCS?​​

​​2.如何获取NCS？​​

​​3.NCS开发中使用的操作系统Zephyr​​

​​4.NCS开发的仓库​​

​​ 5.NCS的架构​​

​​5.1 内存​​

​​ 5.2 NCS的框架​​

​​ 5.3 蓝牙协议栈架构​​

​​6.nrf5340开发板的dts介绍​​

​​ 7.NCS多image的定义方式​​

​​7.1 rom配置​​

​​7.2 ram配置​​

​​ 7.3 多image举例​​

​​ 7.4 NCS child 应用​​

​​7.4.1 mcuboot​​

​​7.4.2 b0​​

​​ 7.4.3 spm​​

​​ 7.4.4 tfm​​

​​ 7.5 NCS child应用-网络核​​

​​ 7.5.1 b0n​​

​​ 7.5.2 hci_rpmsg​​

​​ 7.5.3 802154_rpmsg​​

​​ 7.5.4 multiprotocol_rpmsg​​

​​ 7.6 partition manager​​

​​ 7.7 最终内存布局​​

​​ 8.变量和命名规则​​

​​8.1 编译系统变量​​

​​8.2 imag专用变量​​

​​8.3 conf文件命名规则及编译顺序​​

​​8.4 overlay文件命名规则及编译顺序​​

---

1.什么是NCS?

NCS全称是nRF Connect SDK。

RF Connect SDK介绍的官方链接:​​nRF Connect SDK - nordicsemi.com​​。

NCS最新版本开发者文档链接：​​https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/getting_started.html​​

 NCS是Nordic的最新的SDK开发平台，我们使用的nrf52系列或者最新的nrf5340（截止2022年8月30日还是最新），都可以基于此SDK进行开发，当然Nordic的所有产品线都支持NCS。

所以放弃以前老的nRF5 sdk的开发吧。NCS是Nordic以后的主流或者唯一开发平台。

​

编辑

2.如何获取NCS？

 通过安装的nRF Connect for Desk 去安装NCS

编辑

nRF5340（入门篇）之1.0 windows下开发环境搭建中博主具体了说明了nRF Connect for Desk下载和安装。这里就不在赘述了。

3.NCS开发中使用的操作系统Zephyr

关于Zephy的介绍，可以查看博主的专栏《物联网操作系统Zephyr学习笔记》。

NCS的编译其实就是从Zephyr projeck编译来的，可以说是沿用了Zephy的编译方式，其继承了Zephyr的配置系统。

4.NCS开发的仓库

github仓库网址：​​https://github.com/nrfconnect​​

编辑

 5.NCS的架构

5.1 内存

​

编辑

 5.2 NCS的框架

​

编辑

 5.3 蓝牙协议栈架构

先看下图nrf老的SDK 蓝牙协议架构如图，变化到NRF Connect SDK蓝牙协议架构

​

编辑

​

编辑

6.nrf5340开发板的dts介绍

nrf的所有开发板都在zephyr下boards\arm\下

编辑

 开发板中的commom.dts是几块开发板大部分特性都是相同的，只有少数组件不一样，然后取他们公共部分就组成了commom.dts.

举个例子，zephyr\boards\arm\nrf5340dk_nrf5340其中nrf5340dk_nrf5340_cpu.dts和nrf5340dk_nrf5340_cpuappns.dts，这两块开发板的内容基本上是一致的，然后把相同的部分组成了nrf5340_cpuapp_common.dts，然后nrf5340dk_nrf5340_cpu.dts和nrf5340dk_nrf5340_cpuappns.dts再引用nrf5340_cpuapp_common.dts。

• cpuapp,应用核安全应用
• cpuapp_ns,应用核 非安全应用
• cpunet,网络核

 如果你要个人开发的话，这里建议使用nrf5340dk_nrf5340_cpu.dts进行开发。

 7.NCS多image的定义方式

7.1 rom配置

Kconfig

• CONFIG_FLASH_BASE_ADDRESS=0x0
• CONFIG_FLASH_LOAD_OFFSET=0

DeviceTree

• CONFIG_USE_DT_PAPTITION=n

Partition Manger

单image开发使用Kconfig,多imag使用Patition Manger

7.2 ram配置

不管单image还是多image都通过Device Tree配置

编辑

 7.3 多image举例

下面的工程编译后，生产子image-网络核，主image是应用核。

编辑

编辑

 7.4 NCS child 应用

7.4.1 mcuboot

路径：

编辑

 这个目录文件是第三方可升级的BootLoader,由CONFIG_BOOTLOADER_MCUBOOT控制是否加载这个bootloader。

7.4.2 b0

这个是官方的Bootloader，且不可升级，CONFIG_SECURE_BOOT控制这个bootloader是否加载。

编辑 7.4.3 spm

这个是官方开发的Cortex-M33非安全应用引导程序，由CONFIG_SPM控制是否加载。

路径：

编辑

 7.4.4 tfm

这个是第三方开发，路径：

编辑

 7.5 NCS child应用-网络核

 7.5.1 b0n

这个是官方开发的不可升级的Bootloader，由CONFIG_SECURE_BOOT&&CONFIG_SOC_NRF5340_CPUNET控制是否加载

路径：

编辑

 7.5.2 hci_rpmsg

这是nRF5340 network核的蓝牙controller，由CONFIG_BT_RPMSG_NRF53&&CONFIG_SOC_NRF5340_CPUAPP控制是否加载

路径：

编辑

 7.5.3 802154_rpmsg

 nRF5340 network核的802.15.4 controller，由CONFIG_SOC_NRF5340_CPUAPP&&CONFIG_NRF_802154_SER_HOST控制是否加载。

路径：

zephyr\samples\boards\nrf\ieee802154\802154_rpmsg

编辑

 7.5.4 multiprotocol_rpmsg

nRF5340 network核的多协议共存controller，由CONFIG_BT_RPMSG_NRF53&&CONFIG_SOC_NRF5340_CPUAPP&&CONFIG_NRF_802154_SER_HOST控制是否加载。

路径

编辑

 7.6 partition manager

 简称PM,可以完成对多个image的管理，以及存储划分。

主应用称为parent应用，其他应用称为child应用，通过使能parnet应用的某些Kconfig,可以自动装载child应用，然后自动编译child应用，然后生成child应用的hex,并将child应用的hex和parent应用的hex合并在一起生成merged.hex，这一切都发生在parnet应用的build目录中。

PM首选假定一个app image,也就是parent应用，这个应用对应的hex就是zephy.hex，那么app image 放在flash什么地方呢？这个是由PM动态决定的，PM将根据各个image的相对位置，来决定最终image的排列，一般来说，parent，应用是默认应用，它不需要特别去指定自己的位置，而child 应用则需要告诉PM自己的位置在哪里，这个是通过child应用目录下面的pm.yml文件来实现的，pm.yml会告诉PM本child应用会放在那里。

pm.yml

pm.yml是按照相对位置来决定本child应用的位置的，而且里面会用到Kconfig或者Device Tree的宏定义

相对位置：start,end,app

 例如：\bootloader\mcuboot\boot\zephyr 下的pm.yml

编辑

编辑

 7.7 最终内存布局

可以从主应用的build目录下提现

partitions.yml，是多image最终布局，PM自动生成。

例如：perpipheral_uart下的build

博主编译过了这个例程，所以有build存在。

编辑

编辑

用户如何指定image分区

把partitions.yml复制到项目的根目录下，并重新命名为pm_static.yml

当PM检测到partent应用目录下有pm_static.yml文件，它就不会在自动去划分存储空间，而是直接使用这个静态存储空间layout。

例如路径： nrf\applications\nrf_desktop\configuration\nrf5340dk_nrf5340_cpuapp

编辑

编辑

 8.变量和命名规则

8.1 编译系统变量

• ZEPHYR_BASE，用来表示你的Zephyr代码仓库的绝对目录，比如取值：C：Nordic/NCS/SDK/Master/zephyr.
• BOARD,用来表示编译用的板子，比如取值:nrf5340dk_nrf5340.
• CONF_FILE,用来表示项目的conf文件，如果没有指定，默认用prj.conf。
• DTC_OVERLAY_FILE,用来表示项目的overlay文件，如果没有指定，默认用<board>.overlay。
• PM_STATIC_YML_FILE,用来表示parent应用，即app的pm_static文件，如果没有指定，默认用pm_static.yml。
• CMAKE_BUILD_TYPE,命令行自定义变量，可以通过它传递一个参数给CMakelists.txt或者其他build过程。

8.2 imag专用变量

• conf_file变量本身作用于app_image，实际上你可以把这个变量看成：app_conf_file，只不过默认都是app image，所以把app_ 省略。
• 当需要在parent应用中去设置child应用的conf_file，使用变量：childImageName_conf_file,比如mcuboot_conf_file

8.3 conf文件命名规则及编译顺序

 首选读取CONF_FILE变量，我们可以将多个conf文件都赋给这个变量（每个conf文件之间以分号或者空格隔开）

• 通过命令行方式传递：-DCONF_FILE=<file1.conf.file2.conf>
• 在CMakeLists.txt中并且必须在调用find_package(Zephyr)之前
• 通过CMake变量cache

否则，系统将使用应用目录下的prj_<build>.conf和boards/<BOARD>_<build>.conf两者合并结果

否则，系统将使用应用目录下的prj_<BOARD>.conf

否则，系统 将使用应用目录下的boards/<BOARD>.conf和prj.conf的合并结果

否则，系统将使用应用目录下的prj.conf

8.4 overlay文件命名规则及编译顺序

首选读取DTC_OVERLAY_FILE变量，我们可以同时将多个overlay文件赋给这个变量（每个overlay文件之间以分号或者空格隔开）,这些overlay文件最终合并为一个文件。我们可以 通过如下方式设置DTC_OVERLAY_FILE变量。

• 通过命令行方式传递：-DDTC_OVERLAY_FILE="file1.overlay;file2.overlay"
• 在CMakeLists.txt中并且必须在调用find_package(Zephyr)之前(也就是包含boilerplate.cmake之前)

 否则，系统 将使用应用目录下的boards/<BOARD>.overlay

否则，系统将使用应用目录下的<BOARD>.overlay