1. 课程导入与开发环境搭建
Nordic nRF系列是低功耗蓝牙与2.4 GHz无线产品中最常见的SoC平台之一。要把外设驱动和板级适配做扎实，第一步不是急着写寄存器，而是把“芯片—SDK—工具链—编辑器—开发板”这条链路搭通。本章围绕nRF芯片选型、nRF Connect SDK与Zephyr工具链安装、VS Code插件配置，以及第一个blinky工程的编译烧录，建立后续所有实验的公共基础。
一、先选芯片：从封装、外设与协议栈需求出发
nRF系列型号较多，选型时建议按四个维度判断：无线协议能力、Flash/RAM容量、外设资源、封装与供电。以常见型号为例：nRF52810适合成本敏感、仅需BLE从机的场景，Flash 192 KB、RAM 24 KB；nRF52832是经典通用型，Flash 512 KB、RAM 64 KB，带FPU，适合多数教学与产品原型；nRF52840在52832基础上增强，Flash 1 MB、RAM 256 KB，支持USB、蓝牙5长距离与802.15.4，适合多协议网关；nRF5340是双核架构，应用核与网络核分离，适合需要蓝牙5.2、Thread、Zigbee并发的复杂产品；nRF9160则集成LTE-M/NB-IoT，面向蜂窝物联网。
选型时不要只看“性能最强”。如果项目只需要BLE从机加几个GPIO，选nRF52840会浪费成本与功耗预算；反之，若需要USB DFU、蓝牙Mesh或大量传感器缓存，nRF52832的RAM可能很快吃紧。一个实用的判断顺序是：先确定无线协议与并发需求，再估算协议栈占用后的可用RAM，最后核对所需外设（SPI、I2C、PWM、ADC、UART）数量与引脚复用是否冲突。
二、nRF Connect SDK与Zephyr工具链
nRF Connect SDK（NCS）是Nordic官方基于Zephyr RTOS构建的软件开发套件，包含协议栈、驱动、示例与构建系统。它和早期nRF5 SDK的最大区别在于：NCS使用Zephyr的设备树（Devicetree）与Kconfig描述硬件和功能，驱动以Zephyr设备模型组织，因此板级适配的核心工作从“改寄存器宏”变成了“改设备树与配置”。
安装推荐使用nRF Connect for VS Code的Toolchain Manager，或直接使用命令行工具nrfutil。以Windows为例，安装完成后在终端执行：
nrfutil toolchain-manager install --ncs-version v2.6.0
nrfutil toolchain-manager launch --ncs-version v2.6.0 -- west --version
第一条命令安装指定版本的NCS工具链，第二条进入该工具链环境并验证west。west是Zephyr的多仓库管理工具，负责拉取模块、构建与烧录。若使用VS Code，可在扩展市场安装“nRF Connect for VS Code Extension Pack”，它会自动识别已安装的工具链，并在侧边栏提供“Applications”“Toolchains”“Boards”等视图。
三、VS Code插件配置与工程结构
安装插件后，按Ctrl+Shift+P打开命令面板，执行“nRF Connect: Open Welcome”，在Welcome页中确认工具链路径、SDK版本与已连接开发板。随后创建或打开一个示例工程，例如zephyr/samples/basic/blinky。NCS工程通常包含以下关键文件：
CMakeLists.txt：声明工程名、引入Zephyr包、添加源文件；prj.conf：Kconfig配置，开启GPIO、日志、串口等；boards/<board>.overlay：板级设备树覆盖，用于改引脚、加节点；src/main.c：应用入口。
VS Code插件的价值在于把“配置—构建—烧录—调试”串成图形化流程：在“Applications”视图中选择工程与board，点击Build即可生成build/zephyr/zephyr.hex；点击Flash通过J-Link或板载调试器烧录；点击Debug可进入GDB会话。若构建报错，优先查看“Problems”与终端中的CMake输出，常见原因是工具链未激活、board名拼写错误或overlay语法错误。
四、第一个blinky：从设备树到LED闪烁
blinky示例的逻辑非常简洁：通过设备树别名led0获取GPIO设备，配置为输出，然后在循环中翻转电平并延时。核心代码如下：
#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>
#define LED0_NODE DT_ALIAS(led0)
static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);
int main(void)
{
if (!gpio_is_ready_dt(&led)) return 0;
gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);
while (1) {
gpio_pin_toggle_dt(&led);
k_msleep(500);
}
}
这段代码没有出现任何具体引脚号，引脚信息来自设备树中led0别名指向的节点。以nRF52840 DK为例，led0通常对应P0.13，低电平点亮。若换到自定义板，只需在overlay中重新定义该节点，应用代码无需修改，这正是Zephyr板级适配的优势。
构建与烧录命令如下：
west build -b nrf52840dk_nrf52840
west flash
烧录成功后，开发板上的LED0应以约1 Hz频率闪烁。若LED不亮，按以下顺序排查：确认board名与实际硬件一致；用west build -t guiconfig检查GPIO驱动是否使能；确认overlay中led0的引脚与原理图一致；用万用表测量引脚电平是否翻转。若电平翻转但灯不亮，则问题在硬件侧，如限流电阻或LED极性。
五、常见问题与判断依据
环境搭建阶段最容易卡在三处。第一，工具链未激活：在VS Code中构建时提示找不到west或arm-zephyr-eabi-gcc，此时应在Toolchain Manager中确认版本已安装，并在终端执行nrfutil toolchain-manager launch进入环境。第二，board名错误：nRF52840 DK的board名为nrf52840dk_nrf52840，若写成nrf52840_dk会直接报错，可用west boards列出所有支持板卡。第三，overlay未生效：若修改了LED引脚但现象不变，检查overlay文件名是否与board名一致，以及节点是否使用了正确的status = "okay"。
判断“环境是否搭好”的标准可以很具体：west build无错误退出，build/zephyr/zephyr.hex存在且大小合理，west flash后J-Link日志显示烧录成功，开发板LED按预期闪烁。这四点同时满足，说明芯片、SDK、工具链、编辑器和硬件已经连通，可以进入后续外设驱动章节。