nordic芯片开发环境配置

Posted on

nordic环境配置

开发环境配置说明

本项目的开发基于

1
2
SDK:               nRF Connect SDK v3.2.0
Toolchain:         nRF Connect SDK Toolchain v3.2.0

使用Zephyr作为操作系统，west为主要管理工具。

Vscode环境安装方式（建议）

  1. 安装nrfconnect扩展
    nrfconnect 搜索截图

  2. 扩展安装完成后，需要重启vscode，随后打开扩展进行配置
    nrfconnect 配置截图

    1. 安装sdk 选择 中国大陆 选择 nrf Connect SDK 安装全部的sdk（较大）随后选择 3.2.0版本 建议在默认位置进行安装
    2. 安装toolchain 选择3.2.0版本 【此过程耗时较长 需要30分钟以上】

  3. 等待SDK和工具链安装完毕后即可进行如下测试，如通过，则环境安装完成

开发流程

关于编译

对于一个zephyr的工程，首先要理解的是所有的代码和硬件bsp其实是完全解耦合的，只是在编译的过程中，west工具帮助拉取了对应的板子的dts和dtsi文件，获取了板子的CPU flash 引脚 外设等等信息后综合编译出结果。因此，我们在开发的时候首先要明确使用的板子型号是什么，west才可以根据板名进行工程的编译。

首先，我们需要加载带west的环境，请在nrf connect插件当中开启带有工具链环境变量的终端。
alt text

对于已经内置在工具链当中的板子

zephyr社区非常强大，很多已有的开发板已经有了经过考验的官方/社区版dts/dtsi，因此，我们应尽量使用兼容板子减少bug的出现。编译指令示例west build -b xiao_ble/nrf52840/sense，在这个示例中，我们使用的是xiao_ble的52840 sense变体，具体的名称请自行探索（ai/开发板官方应该有很详细的说明了）

对于自己的新板子

我的开发习惯是在本仓库开一个名为boards的文件夹，在内部配置当前工程需要的新板子，并将这个boards目录作为submodule插入主工程的仓库当中方便进行版本管理。

boards文件夹示例

因此，为了让west能找到我们的板子，编译的指令示例为west build -b pencilrecv -- -DBOARD_ROOT=$PWD

关于烧录和调试

入门阶段，我们先只讨论烧录的事情。

uf2

UF2（USB Flashing Format）是一种把固件封装成“可拖拽拷贝到U盘”的升级方式：设备在 UF2 Bootloader 模式下会枚举成一个 USB Mass Storage（看起来像U盘），你把 *.uf2 文件复制进去，Bootloader 会在后台把数据写入 MCU 的 Flash，然后自动重启运行新固件。

编译出来的uf2文件一般在build/nrf52-TouchPencil/zephyr/zephyr.uf2

xiao_nrf52840设备进入uf2的方式是双击rst按钮

我们自制的板子大多是这样的

J-Link 是 SEGGER 出的硬件调试器/下载器（debug probe），通过 SWD（ARM 常用）或 JTAG 连到 MCU，把电脑上的固件写进芯片 Flash，同时也能做单步调试、断点、读写寄存器/内存、RTT 日志等。

硬件最少要接

  • SWDIO、SWCLK、GND、VTref（目标电压参考）

烧录指令是 west flash -r jlink

简单的基于zephyr的工程结构说明

Zephyr 的工程一般分为两块：应用(app) + **板级/硬件描述(board)**。

1) prj.conf：Kconfig 配置入口（“开关”和参数）

路径：./prj.conf

它是 Zephyr 应用最常见的配置文件，用来设置 Kconfig 选项，决定“编译进哪些子系统/驱动/功能”以及它们的参数。

本仓库的 prj.conf 里主要做了这几类事情：

  • 日志与控制台：启用 CONFIG_LOG，并把后端切到 RTT（CONFIG_LOG_BACKEND_RTT / CONFIG_USE_SEGGER_RTT），同时关闭 UART console（CONFIG_UART_CONSOLE=n）
  • 蓝牙：启用 BLE 外设、LLPM 相关配置（例如 CONFIG_BT_CTLR_SDC_LLPM=y）
  • 传感器与外设：启用 CONFIG_SENSOR、CONFIG_I2C、CONFIG_SPI、CONFIG_ADC、以及 IMU 驱动（例如 CONFIG_LSM6DSL=y）
  • RAM/栈大小：针对 nRF52832 64KB RAM 做了栈大小优化（CONFIG_MAIN_STACK_SIZE 等）

简单理解：**prj.conf 决定“软件能力”**，例如有没有 BLE、有没有 ADC、日志走 RTT 还是 UART。

2) app.overlay：应用级 Devicetree Overlay（“通用硬件连线/节点增改”）

路径：./app.overlay

Devicetree（设备树）描述“板子上有什么硬件、用哪些引脚、设备地址是多少、有哪些别名(chosen/aliases)”等。
app.overlay 是对最终设备树的“补丁”，用于：

  • 增加/修改节点（例如按钮 gpio-keys、ADC channel、I2C 上的 IMU 节点等）
  • 启用/禁用外设节点（例如把某些外设 status = "okay"/"disabled"）
  • 增加 pinctrl 片段（例如 &pinctrl 下的 i2c0_default / spi1_default）

一个典型的 app.overlay 里能看到内容：

  • / { switches { compatible = "gpio-keys"; ... } }：定义按键
  • &adc { channel@0 ...; channel@1 ... }：定义 SAADC 两个通道（压力/电池）
  • &i2c0 { ... lsm6ds3tr-c@6a { ... } }：在 I2C0 上挂载 IMU（地址 0x6a）
  • &uicr { nfct-pins-as-gpios; }：把 NFC 引脚释放成 GPIO

它通常用于“跨多个板子共用的硬件描述”或“快速试验连线/外设开关”。

你可以在构建目录的 CMakeCache.txt 里看到它被设置到 DTC_OVERLAY_FILE（本仓库的 build 产物里记录为 .../app.overlay）。

3) board.dts（实际是 <board>.dts）：板级 Devicetree 主文件（“这块PCB到底长什么样”）

在 Zephyr 里，板级设备树通常是 boards/<board>/<board>.dts，并不会叫做字面上的 board.dts。

它的特点是：

  • #include <nordic/nrf52832_qfaa.dtsi>：先引入 SoC 的基础硬件描述（CPU、外设基址等）
  • chosen { ... }：指定 Zephyr 运行时“选用”的设备（console/shell-uart/flash/code-partition 等）
  • aliases { ... }：给应用提供稳定名字（例如 led-red/led-green/led-blue），让代码不必写死节点路径
  • 外设/引脚/分区：例如 &uart0 波特率、&i2c0、&flash0 { partitions { ... } }（MCUboot/slot0/slot1 等固定分区）

简单理解：**<board>.dts 是“硬件基线”**，描述这块板子从 SoC 到引脚、外设、分区的完整信息。

4) board.dtsi（实际是各种 *.dtsi）：可复用的设备树片段（常见用途：pinctrl）

.dtsi 通常是“被 include 的片段”，用来拆分板级设备树，避免一个 .dts 文件过大，也方便多个板子复用。

这些文件主要在 &pinctrl { ... } 下定义 psels，把外设功能映射到具体引脚（例如 UART0 TX/RX、I2C0 SDA/SCL、SPI1 SCK/MOSI 等），然后在 .dts 里通过：

1
2
3
pinctrl-0 = <&i2c0_default>;
pinctrl-1 = <&i2c0_sleep>;
pinctrl-names = "default", "sleep";

来选择运行态/低功耗态的引脚配置。

5) （补充）<board>.overlay：板级 Overlay（“只对某个板子做微调”）

有时“同一个应用”要跑在不同板子上，但某些节点需要按板子差异做改动，就会用板级 overlay。