企业官网建设流程全解析

Zephyr 在多设备嵌入式项目里停留时间越长，越会发现一个现象：代码量增长带来的主要成本不是写功能，而是工程管理。尤其是当你在官方 sample 上做了几轮修改之后，某一天需要把它们整理成一个独立应用，或者把旧工程迁移到新的 Zephyr 版本时，构建系统、设备树、Kconfig 配置和缓存策略会一起变成阻力。第四课就围绕三个实际开发中高频出现的问题展开：项目如何从 sample 或旧目录迁移并新建为独立工程，构建缓存和内存缓存分别该怎样理解，以及按键输入从设备树配置到回调函数处理的标准做法。

本课面向已经能编译运行 Zephyr 最小程序的开发者。学完后，你会得到一个可复用的独立应用工程骨架，理解west build -p和删除build目录到底在解决什么问题，也能应对大部分 GPIO 按键输入导致的“按了没反应”或“按一下触发多次”的问题。

1. 先理解 Zephyr 工程迁移到底在迁什么

1.1 Zephyr 应用工程的基本构成

一个 Zephyr 应用工程，剥掉业务代码之后，本质上由四类文件决定：

最小应用往往只有前三类文件。例如：

my_app/ ├── CMakeLists.txt ├── prj.conf └── src/ └── main.c

CMakeLists.txt中最核心的是通过find_package(Zephyr)找到 Zephyr 根目录：

cmake_minimum_required(VERSION 3.20.0) find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) project(my_app) target_sources(app PRIVATE src/main.c)

这里的关键是ZEPHYR_BASE。构建系统不是靠“当前目录里有 zephyr 代码”来工作的，而是靠ZEPHYR_BASE环境变量或 CMake 包路径来定位 Zephyr 本体。所以工程迁移时，如果这个变量失效或者指向旧版本，整个工程就会在配置阶段失败。

1.2 为什么不能直接复制粘贴工程目录

很多第一次迁移 Zephyr 工程的人会先试“把整个工程目录复制一份，改个名字，直接编译”。这个动作在纯 C 工程里可能没问题，在 Zephyr 工程里却会遇到三类问题。

第一，旧的build目录不能跟着复制。build目录里面的CMakeCache.txt记录了大量绝对路径、工具链路径、Zephyr 仓库路径。换一台机器或换一个目录，这些缓存会让 CMake 在配置阶段报出各种“找不到路径”或“路径不匹配”的错误。

第二，west工作区结构变了。west通过west.yml管理多个仓库。应用工程如果从zephyr/samples/basic/button迁移到自己的独立仓库，依赖关系仍然指向整个zephyr仓库，不能只迁移应用目录而忽略顶层 workspace。

第三，Zephyr 版本变化会导致配置符号和设备树属性变化。比如某块板卡在新版本里 GPIO 中断配置的 Kconfig 符号被整合了，旧工程prj.conf里写的符号可能已经不再生效甚至直接报错。所以迁移不只是移动文件，而是“在新工程结构下重新确认每一层配置”。

1.3 迁移前需要确认的四个版本问题

建议在任何一次迁移动作之前，先记录下面四个信息。这在实际项目中能省下大量排查时间。

• Zephyr 版本：git -C zephyr describe --tags，或者west list zephyr查看版本。
• 工具链版本：west toolchains --info，记录编译器路径和版本。
• 原工程使用的 Kconfig 符号列表：prj.conf中每个CONFIG_*都要在目标版本里确认是否还存在。
• 设备树节点依赖：boards/下是否有自定义 overlay，节点 label、compatible、gpios属性是否仍然匹配。

确认完这四个信息之后，迁移过程才不是“复制文件碰运气”，而是“在明确版本约束下重建配置”。

2. 用 west 新建独立工程并把旧代码迁移过来

2.1 检查 Zephyr 环境是否就绪

在新建工程之前，先确认当前环境中的 west 和 Zephyr 仓库状态。下面命令的顺序很重要：

west --version west topdir west list

• west topdir会输出当前工作区的顶级目录。如果执行报错，说明你没有在 west workspace 内运行命令。
• west list会列出 manifest 管理的所有仓库。正常情况下至少能看到zephyr仓库以及可能存在的hal_*模块。

如果这些命令都正常，再确认ZEPHYR_BASE：

echo $ZEPHYR_BASE west build --help | grep -A2 pristine

west build --help中的-p参数会直接影响后面的缓存清理操作。当前主流版本支持-p auto、-p always和-p never三档，含义分别是自动判断、总是清理后构建、从不清理。

2.2 基于官方模板新建独立应用

Zephyr 官方提供west create来从一个模板初始化应用。常见做法：

west create -t zephyr my_app

这个命令会在当前目录下创建my_app目录，并且从 zephyr 仓库中的模板复制一份基础结构。不过不同版本的west支持的模板可能存在差异，所以更稳妥的做法是手动创建目录结构，再通过west build来构建：

mkdir -p my_app/src touch my_app/CMakeLists.txt touch my_app/prj.conf touch my_app/src/main.c

手动创建的好处是结构完全可控，不受模板版本影响。对迁移场景来说，手动创建更适合，因为你不需要模板里的多余 sample 代码。

2.3 迁移旧代码时 CMakeLists.txt 和 prj.conf 怎么处理

迁移时不要把旧工程的CMakeLists.txt原样带过来。建议先用最小形式重建，再逐步加回业务代码。

最小CMakeLists.txt：

cmake_minimum_required(VERSION 3.20.0) find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) project(my_app) target_sources(app PRIVATE src/main.c)

prj.conf也建议最小化开始。对于“按键输入”这个主题，先只开启 GPIO 和日志：

CONFIG_GPIO=y CONFIG_LOG=y

注意：不同 Zephyr 版本里 GPIO 相关 Kconfig 符号不完全一致。某些版本需要额外开启CONFIG_GPIO_INTERRUPT_SUPPORT=y，某些版本默认包含。安全做法是先编译一次，根据 CMake 或 Kconfig 报错再补。

旧的业务代码迁移时，建议先让 main.c 只做一件事：编译通过并打印日志。确认工程能跑起来之后，再加入按键、缓存、外设访问等复杂逻辑。这样把“工程迁移”和“功能开发”两个风险分开。

2.4 迁移后删除构建缓存再重新编译

这一条看起来简单，却是迁移后最常见的失败点。旧工程目录里如果残留了build目录，新工程第一次构建就可能命中旧的 CMake 缓存，导致配置不更新、源文件路径不对、设备树还是旧节点等诡异问题。

推荐做法是显式清理后再构建：

rm -rf build west build -b <your_board> .

或者直接用 west 的 primary 参数：

west build -p always -b <your_board> .

-p always等价于每次构建前清理所有生成文件。虽然它会增加编译时间，但在迁移初期、配置频繁调整阶段非常值得用。等工程稳定后再改用-p auto享受增量编译。

3. 按键输入：从 GPIO 引脚到回调函数

3.1 先理解 GPIO 输入和中断触发方式

按键输入在 Zephyr 里的本质是：把一个 GPIO 引脚配置为输入模式，监听它从高电平到低电平或低电平到高电平的变化，然后在中断回调里做业务处理。

这里有几个容易混淆的概念。

• 输入模式：GPIO_INPUT，告诉引脚控制器这个引脚用于读取外部信号。
• 上拉/下拉：GPIO_PULL_UP或GPIO_PULL_DOWN，用于在没有外部电路时确定引脚默认电平。按键常见接法是按键一端接 GND，另一端接 GPIO，此时需要启用上拉电阻。按键按下时引脚被拉低，释放时恢复高。
• 有效电平：GPIO_ACTIVE_LOW表示低电平有效，GPIO_ACTIVE_HIGH表示高电平有效。
• 中断触发方式：GPIO_INT_EDGE_RISING、GPIO_INT_EDGE_FALLING、GPIO_INT_EDGE_BOTH、GPIO_INT_EDGE_TO_ACTIVE、GPIO_INT_EDGE_TO_INACTIVE。

对于“低电平有效”的按键，常用配置是：

GPIO_ACTIVE_LOW + GPIO_INT_EDGE_TO_ACTIVE

GPIO_INT_EDGE_TO_ACTIVE的意思是在电平跳向有效状态的边沿触发中断。好处是逻辑上不需要关心具体是高跳低还是低跳高，设备树里定义了 active level 之后，代码自动适配。

3.2 在设备树中确认按键节点

在 Zephyr 中，推荐方式是在设备树 overlay 里定义按键节点，然后在 C 代码里用设备树宏引用它。这样如果换了板卡，只需要改 overlay，不用改 C 代码。

下面是一个按键节点的示例：

/ { gpio_keys { compatible = "gpio-keys"; button0: button_0 { label = "Button0"; gpios = <&gpio0 11 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>; }; }; };

注意：gpio-keys是 Zephyr 官方维护的 compatible，适用于一个节点下有多个按键。button0是这个节点的 label，用于在设备树中生成引用。gpios属性里第一个参数是 GPIO 控制器引用，第二个是引脚号，第三个是标志位。

如果要使用DT_ALIAS，还可以在根节点定义别名：

/ { aliases { sw0 = &button0; }; };

然后在 C 代码中：

#define BUTTON_NODE DT_ALIAS(sw0)

如果不想使用gpio-keyscompatible，也可以直接在根节点下自定义节点，但需要保证 compatible 能够被对应驱动识别，或者只使用DT_NODELABEL获取节点描述并手动初始化。这里推荐使用 Zephyr 标准方式，因为后续如果要接入 input 子系统或功耗管理时更顺。

3.3 编写按键初始化代码

对应上面的设备树，main.c 里可以先做三件事：获取按键描述、检查设备是否就绪、配置引脚为输入并启用中断。

#include <zephyr/kernel.h> #include <zephyr/device.h> #include <zephyr/drivers/gpio.h> #include <zephyr/logging/log.h> LOG_MODULE_REGISTER(main, LOG_LEVEL_INF); #define SW0_NODE DT_ALIAS(sw0) static struct gpio_callback button_cb_data; static void button_pressed(const struct device *dev, struct gpio_callback *cb, uint32_t pins) { printk("Button pressed at uptime: %" PRIu64 "\n", k_uptime_get()); } int main(void) { const struct gpio_dt_spec button = GPIO_DT_SPEC_GET(SW0_NODE, gpios); if (!gpio_is_ready_dt(&button)) { LOG_ERR("Button GPIO port is not ready"); return -ENODEV; } int ret = gpio_pin_configure_dt(&button, GPIO_INPUT); if (ret < 0) { LOG_ERR("Failed to configure button pin, code: %d", ret); return ret; } ret = gpio_pin_interrupt_configure_dt(&button, GPIO_INT_EDGE_TO_ACTIVE); if (ret < 0) { LOG_ERR("Failed to configure button interrupt, code: %d", ret); return ret; } gpio_init_callback(&button_cb_data, button_pressed, BIT(button.pin)); gpio_add_callback(button.port, &button_cb_data); LOG_INF("Button demo started"); return 0; }

关键点有三个。

第一，GPIO_DT_SPEC_GET使用设备树宏直接从节点中展开struct gpio_dt_spec，包含 port、pin、dt_flags 三个字段。后续的gpio_pin_configure_dt和gpio_pin_interrupt_configure_dt都使用这个 spec，不需要手动维护引脚编号和标志位。

第二，gpio_pin_interrupt_configure_dt必须在gpio_pin_configure_dt之后调用。顺序反了，很多驱动会返回-EINVAL或-ENOTSUP。

第三，回调函数运行在中断上下文。不要在里面调用阻塞函数、信号量获取超时或长时间循环。如果必须做重量级操作，应该在回调里提交一个 work 项，然后在非中断上下文中处理。

3.4 软件防抖不能省

机械按键按下时，金属触点会经历几十毫秒的抖动，表现为电平高速切换。如果没有防抖，一次按键可能触发多次中断。常见现象是“按一次，日志打三次”。

硬件防抖是并联电容或使用施密特触发器，但并不是所有板子都有这个电路。软件防抖更通用。

一个简洁做法：在中断回调里启动一个k_work_delayable，只有在延时结束后的状态仍然符合按压状态时才响应。

#include <zephyr/kernel.h> #include <zephyr/drivers/gpio.h> static struct k_work_delayable debounce_work; static const struct gpio_dt_spec button = GPIO_DT_SPEC_GET(SW0_NODE, gpios); static void button_work_handler(struct k_work *work) { int val = gpio_pin_get_dt(&button); if (val == 1) { return; } printk("Button confirmed pressed\n"); } static void button_isr(const struct device *dev, struct gpio_callback *cb, uint32_t pins) { k_work_schedule(&debounce_work, K_MSEC(20)); } int main(void) { k_work_init_delayable(&debounce_work, button_work_handler); // 其余 GPIO 初始化逻辑同前 return 0; }

这段代码把防抖逻辑放在延迟工作项里。中断触发后先等 20ms，再读一次引脚电平。如果确认仍为按下状态，才执行实际操作。注意gpio_pin_get_dt返回 1 表示有效电平（active level）被确认，具体和GPIO_ACTIVE_LOW有关，返回值已经做了电平归一化。

防抖时间的选取需要平衡响应速度和误触率。20ms 对多数机械按键够用，静音微动开关可能需要 30ms 到 50ms。实际项目里要在示波器上观察按下波形后确定，或者做成可配置参数。

4. 缓存与 Zephyr 构建系统：为什么改配置不生效

4.1 构建缓存的组成

Zephyr 工程里谈到“缓存”，很容易产生歧义。嵌入式场景最常遇到的其实是两种：构建缓存和 CPU 数据缓存。两者作用完全不同，但在开发和调参阶段，构建缓存的问题出现频率更高。

build目录下有几个关键缓存文件：

构建缓存是一种“加速机制”，但它的前提是缓存与源文件一致。当你修改prj.conf、overlay 或CMakeLists.txt后，如果 CMake 没有重新执行配置阶段，就会继续使用旧缓存，表现就是“代码改了，结果没变”。

4.2 关键缓存清理操作

处理配置不生效的标准路径按顺序做：

west build -t menuconfig

先打开 Kconfig 图形配置，确认最终CONFIG_*值。如果这里没有变化，说明问题出在构建系统的配置重跑机制上，而不是你的配置写法。

下一步是清理甚至完全删除构建目录：

rm -rf build west build -b <your_board> .

如果想要更规范的方式，使用 west 提供的 pristine 参数：

west build -p always -b <your_board> .

-p always会在这次构建前自动清理生成文件，然后重新配置并编译。-p auto则在检测到构建配置变化时才会清理，适合日常迭代。迁移工程或怀疑缓存失效时，直接使用-p always，不要心疼那几分钟编译时间。

4.3 内存缓存：使用 DMA 或外部内存时的缓存一致性问题

除了构建缓存，Zephyr 中还有 CPU 数据缓存。这个在带 MMU/Cache 的平台上尤其重要，比如 ARM Cortex-A 系列。对没有 cache 的 Cortex-M 内核，问题通常不明显，但一旦进入带缓存的高性能 MCU 或 SoC，就会出现难以排查的数据不一致问题。

经典场景是 DMA 搬运数据。CPU 侧修改一块内存后启动 DMA 搬运，如果这块内存还被 CPU 写缓存命中，DMA 看到的数据可能不是最新的。反过来，DMA 写入一块内存后，CPU 读取时如果读到了缓存里的旧数据，同样得不到新结果。

Zephyr 提供 cache 管理 API 来主动做两件事：

• flush：把 cache 中的脏数据写回内存，保证 DMA 或外设读到的数据是最新的。
• invalidate：让 cache 失效，迫使 CPU 下次访问时重新从内存加载，从而读到外设或 DMA 写的最新数据。

头文件：

#include <zephyr/cache.h>

函数原型按当前版本大致如下：

int sys_cache_data_flush_range(void *addr, size_t size); int sys_cache_data_invd_range(void *addr, size_t size);

使用示例（示意，根据平台确认）：

uint8_t rx_buf[1024] __aligned(32); /* CPU 写完后，启动 DMA 前刷回 */ sys_cache_data_flush_range(rx_buf, sizeof(rx_buf)); /* DMA 完成后，CPU 读取前作废 cache */ sys_cache_data_invd_range(rx_buf, sizeof(rx_buf));

注意：不是所有平台都提供 cache 驱动支持。如果平台没有 cache controller，这些 API 可能只是空操作，或者编译时直接不可用。正式代码里应当先确认平台 Kconfig 中是否启用了 cache 驱动，再看这些函数是否真正执行了操作。

还有一个容易被忽略的实践：涉及 DMA 的 buffer 通常要求地址对齐，比如 32 字节对齐。Zephyr 中可以用__aligned(32)声明，或者在设备树缓冲区描述中定义对齐要求。未对齐的地址传给 flush/invalidate 函数，可能有未定义行为。

5. 最小验证：按键控制一个 LED 熄灭或点亮

5.1 工程完整结构

把前面几部分组合起来，可以得到一个最小但完整的按键控制工程。

my_app/ ├── CMakeLists.txt ├── prj.conf ├── boards/ │ └── your_board.overlay └── src/ └── main.c

your_board.overlay里的your_board要替换成你实际使用的板卡名。比如 STM32 系列某板子，可能叫stm32f413h_disco，nRF 系列可能叫nrf52840dk_nrf52840。如果不确定，先运行west boards查看完整板卡列表，再根据板卡名创建 overlay 文件。

5.2 prj.conf、overlay 和 main.c 组合

prj.conf最小配置：

CONFIG_GPIO=y CONFIG_LOG=y

boards/your_board.overlay增加按键和 LED 节点：

/ { gpio_keys { compatible = "gpio-keys"; button0: button_0 { label = "Button0"; gpios = <&gpio0 11 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>; }; }; gpio_leds { compatible = "gpio-leds"; led0: led_0 { label = "LED0"; gpios = <&gpio0 13 (GPIO_ACTIVE_LOW)>; }; }; aliases { sw0 = &button0; led0 = &led0; }; };

注意这里gpio0、引脚号 11 和 13 只是示例。实际板卡上接按键和 LED 的 GPIO 控制器、引脚号、有效电平都必须查板卡原理图或原厂 BSP。不要照搬。

src/main.c：

#include <zephyr/kernel.h> #include <zephyr/device.h> #include <zephyr/drivers/gpio.h> #include <zephyr/logging/log.h> LOG_MODULE_REGISTER(main, LOG_LEVEL_INF); #define SW0_NODE DT_ALIAS(sw0) #define LED0_NODE DT_ALIAS(led0) static const struct gpio_dt_spec button = GPIO_DT_SPEC_GET(SW0_NODE, gpios); static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); static struct gpio_callback button_cb_data; static struct k_work_delayable debounce_work; static bool led_state; static void button_work_handler(struct k_work *work) { int val = gpio_pin_get_dt(&button); if (val != 1) { return; } led_state = !led_state; gpio_pin_set_dt(&led, led_state); LOG_INF("LED %s", led_state ? "on" : "off"); } static void button_isr(const struct device *dev, struct gpio_callback *cb, uint32_t pins) { k_work_schedule(&debounce_work, K_MSEC(20)); } int main(void) { int ret; if (!gpio_is_ready_dt(&button)) { LOG_ERR("Button GPIO port not ready"); return -ENODEV; } if (!gpio_is_ready_dt(&led)) { LOG_ERR("LED GPIO port not ready"); return -ENODEV; } ret = gpio_pin_configure_dt(&button, GPIO_INPUT); if (ret < 0) { return ret; } ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT); if (ret < 0) { return ret; } ret = gpio_pin_interrupt_configure_dt(&button, GPIO_INT_EDGE_TO_ACTIVE); if (ret < 0) { LOG_ERR("Interrupt config failed, code: %d", ret); return ret; } k_work_init_delayable(&debounce_work, button_work_handler); gpio_init_callback(&button_cb_data, button_isr, BIT(button.pin)); gpio_add_callback(button.port, &button_cb_data); LOG_INF("Press button to toggle LED"); return 0; }

这段代码的运行逻辑是：按键触发中断，ISR 只做一件事——调度一个 20ms 后的延迟任务。延迟任务重新读按键状态，确认按下后翻转 LED 状态。ISR 中不做耗时操作，防抖放在工作线程上下文中执行。

5.3 构建、烧录与预期结果

构建命令：

cd my_app rm -rf build west build -p always -b your_board .

烧录命令因板卡而异，常见的是：

west flash

或者根据板卡使用 OpenOCD、pyOCD、J-Link 工具：

west flash --runner jlink

预期结果：

• 构建无错误。
• 烧录后串口终端打印Press button to toggle LED。
• 按下按键后，日志输出LED on，再按一次输出LED off。
• 快速连续按几次，不会出现一次按下触发多次电平翻转。

如果实现的是日志输出而不是 LED，那么验证标准就是日志内容出现次数与按下次数一致。

6. 常见问题排查

6.1 prj.conf 改了但编译结果没变化

这是构建缓存问题最高频的一组现象。核心判断依据永远是build/zephyr/.config，而不是prj.conf。只要最终 config 文件里的值没有变，修改就没生效。

6.2 按键中断不触发

按顺序排查：

1. GPIO 是否就绪。gpio_is_ready_dt返回假时，设备树里的gpios可能引用了不存在的 controller，或者控制器驱动没有被编译。
2. 设备树节点是否真的被编译进去。检查build/zephyr/zephyr.dts，搜索button0。搜索不到说明 overlay 文件没生效，可能是文件名不匹配板卡名，或 overlay 语法错误。
3. 引脚是否被其他节点占用。一个 pin 在设备树中被两个节点同时引用，驱动初始化可能失败或行为异常。
4. 中断触发模式是否匹配。上拉按键用GPIO_INT_EDGE_TO_ACTIVE，但设备树里实际没有设置GPIO_ACTIVE_LOW，有效电平判断就会错。
5. 回调是否注册成功。gpio_add_callback的返回值需要检查，如果返回错误，通常是因为回调已经注册过或引脚号超出范围。

6.3 回调触发多次或抖动严重

抖动问题一般不是 Zephyr 本身的问题，而是对按键物理特性的处理不够。延长防抖时间通常可以缓解，但会牺牲响应速度。生产环境建议结合具体按键型号做实测。

6.4 cache API 调用无效或编译报错

如果代码里使用了sys_cache_data_flush_range但编译失败，先确认：

1. 是否包含了<zephyr/cache.h>。
2. 平台是否提供 cache 驱动支持。查看Kconfig中有没有CONFIG_CACHE相关选项。
3. 函数返回值是否被忽略。部分实现会返回-ENOTSUP，表示该平台不支持。

数据 cache 问题最难排查，因为它不会直接报错，而是造成“偶发数据错误”。如果 DMA 和外设共享 buffer 时出现随机数据错乱，优先检查对齐、flush 和 invalidate 的时机。

7. 最佳实践与扩展方向

7.1 Zephyr 工程迁移检查清单

在每次迁移或新建工程时，可以对照下面清单执行：

• 清理旧构建目录，或统一使用west build -p always。
• 确认west list正常且当前 Zephyr 版本符合预期。
• 使用最小化的CMakeLists.txt和prj.conf建立可编译基线。
• 逐个迁移源文件，每次迁移后至少完成一次编译。
• 迁移设备树 overlay 时，检查节点 label、compatible、gpios属性是否存在于目标版本。
• 配置项统一从build/zephyr/.config确认最终值，而不是只看prj.conf。
• 涉及 DMA 或共享内存时，确认 cache flush/invalidate 时机和 buffer 对齐。

7.2 生产环境需要注意的差异

学习环境里，按键回调里打日志、翻转 LED 就够用了。生产环境则要额外考虑几件事。

• 日志输出可能阻塞或引入时序抖动，需要把日志降级或移到后台任务。
• 按键中断可能需要参与低功耗唤醒管理，GPIO 配置要支持唤醒源，同时处理从低功耗状态恢复后的初始化。
• 如果设备需要频繁升级固件，工程迁移时要保留稳定的构建脚本或 CI 流程，不能依赖本地prj.conf手工维护。
• 涉及 cache 的缓冲区建议使用 DMA 专用的内存区域或 cache 管理 API，同时加入运行时断言检查对齐和大小。

软件防抖策略也不只一种。简单的延时方法适合大多数场景，但如果系统对响应时间敏感，可以采用状态机 + 固定的采样周期，或者使用定时器定时读取引脚状态而非依赖边沿中断。根据按键数量和应用场景选择，不要盲目复制代码。

7.3 下一步可以往哪个方向扩展

这一课的工程骨架已经具备按键输入和缓存相关概念。在此基础上，可以继续扩展几个方向。

• 使用 Zephyrinput子系统，把按键事件抽象为标准输入事件，后续接入 sensor 或 HID 时更容易。
• 引入工作队列和消息队列，把按键事件从中断上下文安全地传递到应用线程。
• 使用设备树chosen或 alias 机制，让同一个应用代码适配多块板卡。
• 查一下目标平台的 cache 驱动实现，理解flush和invalidate的底层操作，这在使用 DMA 驱动外设时几乎是必答题。

第四课的核心目标是让工程本身变得可迁移、可解释、可排查。做到这一点后，再往里面加业务功能，才不会一边增加功能一边积累技术债。项目迁移时保留的最小工程，后续会成为所有功能扩展的基础，值得在开发初期就把它整理干净。