1. 这不是“装几个软件”的事Zephyr 开发环境配置的本质是嵌入式开发范式的切换Zephyr、开发环境配置、Ubuntu、Vscode、Zephyr RTOS——这几个词凑在一起表面看是教你怎么在 Linux 上装个 IDE 和 SDK但实际踩进去才发现这根本不是“下载安装包→双击→下一步”就能搞定的流程。我带过三届嵌入式方向的实习生几乎所有人第一次配 Zephyr 环境都卡在第 3 步不是因为命令敲错了而是压根没理解 Zephyr 的构建哲学和依赖链条。它不像 Arduino 那样把所有东西打包进一个 IDE也不像 STM32CubeIDE 那样用图形界面屏蔽底层细节Zephyr 是一套基于 CMake Kconfig Devicetree 的声明式构建系统你配的不是“工具”而是一整套编译时决策机制的入口。Ubuntu 不是随便选的“兼容性好”而是因为 Zephyr 官方 CI 全跑在 Ubuntu 22.04 LTS 上所有 Python 脚本、west 工具链、GCC ARM Embedded Toolchain 的版本兼容性验证全基于这个发行版。Vscode 更不是图个界面好看——它靠的是 C/C 扩展 CMake Tools Devicetree Language Support 这三个插件组合才能实时解析 .dts 文件里的 pinmux 配置、自动生成 symbol.h 头文件、跳转到驱动源码里定义的 CONFIG_* 宏。很多人装完 vscode 插件却没法跳转不是插件没装对而是没运行过 west build --pristine导致 build 目录下的 compile_commands.json 根本没生成。所以这篇教程不叫“Zephyr 安装步骤”它叫“Zephyr 开发环境配置教程”重点在“配置”二字配置路径、配置权限、配置缓存策略、配置 west manifest 的同步方式、配置 Vscode 的 launch.json 与 gdb-server 的握手协议。适合谁适合已经写过裸机驱动、能看懂 startup.s 汇编、知道 linker script 里 .text 段怎么映射到 Flash 地址的人不适合刚学完 C 语言语法、连 makefile 都没写过的纯新手——那得先补《嵌入式 Linux 基础工具链》再来看这篇。如果你正为 “ubuntu 安装 gcc 失败” 或 “vscode 配置 stm32 开发环境” 这类问题搜到这儿说明你可能还在用传统 MCU 开发思维套 Zephyr那我们得先掰开讲清楚Zephyr 的“开发环境”本质是你和编译系统之间的一份信任契约。2. 整体设计逻辑为什么必须用 west CMake Ubuntu 原生环境2.1 west 不是“另一个 git”它是 Zephyr 的元构建协调器Zephyr 的代码仓库结构是典型的“单体仓库子模块镜像”混合模式主仓库 zephyrproject/zephyr 只存核心内核和通用驱动而板级支持包BSP、第三方中间件如 mbedtls、tinycbor、硬件抽象层HAL全部以 Git 子模块形式分散在独立仓库中。如果只用 git clone你会得到一个空壳——所有子模块目录都是空的。这时候有人会说“那我 cd 进去一个个 git submodule update --init --recursive 不就行了”理论上可以但实操中会立刻撞墙Zephyr 2.7 之后引入了 west manifest 文件west.yml它不仅声明子模块 URL还精确控制每个子模块的 commit hash、分支策略、是否启用、依赖顺序。比如 nrfxlibNordic 的专有无线协议栈默认是 disabled必须在 west.yml 中显式设为 enabled: true否则即使你手动 clone 下来CMake 在 configure 阶段也会报错 “nrfxlib not found”。west 就是专门解决这个问题的它读取 west.yml按拓扑顺序拉取、检出、打标签还能自动处理跨仓库的 patch 应用比如你给 hal_stm32 提交了一个 fixwest 可以帮你把 patch 同步到所有引用该 HAL 的 BSP 中。我试过不用 west纯脚本管理 12 个子模块三天后发现某个子模块的 SHA-1 被上游 force push 覆盖本地 build 失败却查不出原因——因为 git log 显示一切正常但 west status 一眼就能看出 “nrfxlib: out of sync with manifest”。所以 west 不是可选项是 Zephyr 生态的基础设施层就像 Linux 内核的 kbuild 一样不可绕过。2.2 CMake 是唯一被官方支持的构建系统Kconfig 是配置引擎的心脏Zephyr 官方文档明确写着“The only supported build system is CMake.” 这句话背后是十年演进的结果。早期 Zephyr 用过 Makefile但随着驱动数量爆炸式增长现在超过 800 个驱动Makefile 的隐式依赖和并行构建问题越来越严重。CMake 的优势在于它把“配置”和“构建”彻底分离。configure 阶段west build -s -d build只做三件事解析 Kconfig 生成 autoconf.h、展开 devicetree 生成 dts_fixup.h 和 generated_dts_board.h、生成 build.ninja 文件。整个过程不碰任何 C 源码纯元数据处理。而 build 阶段ninja -C build才真正调用 GCC 编译。这种分离带来两个关键好处一是配置变更后只有受影响的 target 重新编译比如改了 CONFIG_GPIOy只会重编 gpio.c不会重编 uart.c二是你可以用 CMake GUI 或 ccmake 交互式修改 Kconfig比 vi config.conf 直观得多。Kconfig 则是这套机制的源头活水。它不是简单的宏开关而是带依赖关系的布尔代数系统。比如 CONFIG_SPIy 会自动启用 CONFIG_SPI_STM32F4y如果目标板是 stm32f429i-disco但如果你手动把 CONFIG_SPI_STM32F4nCMake configure 阶段就会报错“CONFIG_SPI_STM32F4 depends on CONFIG_SPI”。这种强约束保证了配置一致性避免出现“SPI 驱动编译了但控制器没使能”的低级错误。我见过太多人直接改 defconfig 文件硬编码 CONFIG_XXXy结果换板子时忘了改烧录后串口没输出——因为 CONFIG_UART_CONSOLE 默认依赖 CONFIG_UART而新板子的 UART 设备树节点名变了Kconfig 没触发自动关联。2.3 Ubuntu 原生环境是唯一经过全量 CI 验证的基线Zephyr 的 CI 流水线https://github.com/zephyrproject-rtos/zephyr/actions每天运行超过 5000 个 job覆盖 30 架构、200 板卡所有 job 都在 Ubuntu 22.04 LTS 的 Docker 容器中执行。这意味着Python 3.10.12 的 pip 包兼容性、GCC 12.3.0 的 ARM 架构支持、CMake 3.22.1 的 Ninja 生成器稳定性、west 1.2.0 的 manifest 解析逻辑……所有组合都在这个环境中被反复锤炼。你用 Ubuntu 20.04 可能遇到的问题pip install west 时提示 “No module named ‘setuptools’”是因为 setuptools 65.0 不再支持 Python 3.8 的旧 API你用 Ubuntu 24.04 可能遇到的问题GCC 13.2.0 编译某些 Cortex-M0 代码时触发 ICEInternal Compiler Error因为 Zephyr 的汇编启动代码还没适配新 GCC 的 inline asm 语义。而 Ubuntu 22.04 是官方明确标注的“Supported Host OS”。这不是保守是工程确定性。VMware 虚拟机安装 Ubuntu 是可行的但要注意必须开启 CPU 虚拟化Intel VT-x / AMD-V否则 QEMU 模拟器无法运行必须分配至少 4GB 内存因为 west update 拉取所有子模块时内存峰值超 3GB磁盘空间建议 50GB 起步zephyr 主仓库加所有子模块解压后占 25GBbuild 目录单次编译就 2GB。至于 WSL2它其实比原生 Ubuntu 更稳——因为微软已将 WSL2 内核升级到 5.15完全兼容 Zephyr 的 syscall 调用且 I/O 性能接近物理机。我自己的主力开发环境就是 WSL2 Ubuntu 22.04west update 速度比 VMware 快 40%。3. 核心细节拆解从零开始配置的每一步都藏着坑3.1 系统级依赖安装别急着 pip先搞定底层工具链很多教程一上来就pip3 install west这是最危险的起点。Zephyr 的构建链依赖三个层级系统级apt、Python 级pip、Zephyr 级west。跳过第一层后面全是雷。首先确认系统基础工具sudo apt update sudo apt upgrade -y sudo apt install -y git cmake ninja-build gperf ccache libssl-dev libxml2-dev libpython3-dev \ python3-pip python3-setuptools python3-wheel xz-utils file make gcc-arm-none-eabi这里要重点解释几个易错点gcc-arm-none-eabi这是 GNU Arm Embedded Toolchain 的 Ubuntu 包名。Zephyr 官方推荐使用 10-2020-q4-major 版本对应 GCC 10.2.1但 Ubuntu 22.04 默认源里是 12.2.0。新版 GCC 对某些老芯片如 nRF51的 inline asm 支持有 breaking change所以如果你开发 nRF51822必须降级sudo apt install gcc-arm-none-eabi15:10.3.1gnu-1ubuntu1~22.04.1 sudo apt-mark hold gcc-arm-none-eabi # 锁定版本防止 apt upgrade 覆盖ccache这不是可选优化项是必备。Zephyr 的 build 目录里有上千个 .o 文件每次 clean rebuild 都要重编译。ccache 把编译结果缓存到 ~/.ccache首次 build 后后续修改单个 .c 文件编译时间从 3 分钟降到 8 秒。但默认缓存路径在 /tmp重启就清空。必须配置echo export CCACHE_DIR$HOME/.ccache ~/.bashrc echo export CCACHE_BASEDIR$HOME ~/.bashrc source ~/.bashrc ccache -M 10G # 设置缓存上限 10GBpython3-pipUbuntu 22.04 自带 pip 22.0.2但 Zephyr 要求 pip 21.0.1。检查方法pip3 --version如果低于要求升级python3 -m pip install --upgrade pip提示绝对不要用sudo pip3 install这会导致系统 Python 包和用户包混杂west 更新时可能破坏 apt 管理的包。所有 pip 安装必须用pip3 install --user然后把$HOME/.local/bin加入 PATHecho export PATH$HOME/.local/bin:$PATH ~/.bashrc source ~/.bashrc3.2 west 初始化不是 clone是 manifest 驱动的多仓库协同west 的初始化分三步安装 west、初始化 workspace、拉取 manifest。很多人卡在第二步。第一步安装 westpip3 install --user west验证west --version # 应输出 west 1.2.0第二步创建 workspace 并初始化mkdir ~/zephyrproject cd ~/zephyrproject west init -m https://github.com/zephyrproject-rtos/zephyr注意-m参数它指定 manifest 仓库地址。官方默认是https://github.com/zephyrproject-rtos/zephyr但国内访问 GitHub 很慢。你可以用清华镜像west init -m https://mirrors.tuna.tsinghua.edu.cn/github-zephyr/zephyr但必须确认镜像是否同步——清华镜像每天 04:00 同步一次如果官网刚发布 v3.5.0镜像可能还没更新。此时west init会失败报错 “manifest repo not found”。解决方案临时切回官方源或等几小时。第三步拉取所有子模块west update这是最耗时的步骤首次约 15-30 分钟。关键监控点查看west status所有子模块状态应为clean无out of sync。检查zephyr/.west/config里面应有[manifest]段path zephyrurl https://github.com/zephyrproject-rtos/zephyr。如果中途断网west update会中断但下次运行会续传不会重下整个仓库。注意west update默认拉取main分支。但生产项目必须锁定版本方法是在.west/config中添加[manifest] path zephyr url https://github.com/zephyrproject-rtos/zephyr revision v3.4.0然后west update。revision 可以是 tagv3.4.0、branchrelease-v3.4、commit hasha1b2c3d。tag 最安全branch 有更新风险。3.3 Vscode 配置CMake Tools 插件的隐藏参数才是关键Vscode 的 Zephyr 开发体验90% 取决于 CMake Tools 插件的配置。默认设置只能编译不能调试、不能跳转、不能查看符号。首先安装必要插件C/Cms-vscode.cpptoolsCMake Toolsms-vscode.cmake-toolsDevicetree Language Supportmarus25.cortex-debugCortex-Debugmarus25.cortex-debug——注意不是 “Cortex Debug”名字差一个横线然后配置settings.jsonCtrlShiftP → “Preferences: Open Settings (JSON)”{ cmake.configureOnOpen: true, cmake.buildDirectory: ${workspaceFolder}/build, cmake.generator: Ninja, cmake.cmakePath: /usr/bin/cmake, cmake.ninjaPath: /usr/bin/ninja, cmake.configureArgs: [ -DBOARDstm32f429i-disco, -DZEPHYR_BASE${workspaceFolder}/zephyr, -DWEST_DIR${workspaceFolder}/.west ], cmake.environment: { ZEPHYR_BASE: ${workspaceFolder}/zephyr, WEST_DIR: ${workspaceFolder}/.west } }关键参数解读cmake.buildDirectory强制 build 目录在 workspace 根目录下避免 Vscode 在.vscode/下建 build导致west build和 Vscode build 路径不一致。cmake.configureArgs这是灵魂。-DBOARD指定目标板必须和zephyr/boards/arm/stm32f429i-disco目录名完全一致区分大小写-DZEPHYR_BASE告诉 CMake Zephyr 核心代码在哪-DWEST_DIR让 CMake 能找到 west manifest。cmake.environment环境变量必须和 configureArgs 里的 -D 参数一致否则 CMake Tools 在 configure 时会找不到 Zephyr。配置完成后按 CtrlShiftP → “CMake: Configure”Vscode 会在右下角显示 “Configuring project…”。成功后状态栏会显示 Board 名和 Build Type通常是 debug。此时打开src/main.c按 CtrlClick 能跳转到zephyr/include/kernel.h证明符号解析成功。实操心得如果跳转失败90% 是因为没运行过west build。CMake Tools 的 IntelliSense 依赖build/compile_commands.json而这个文件只在west build或cmake --build build后生成。所以首次配置务必先在终端运行cd ~/zephyrproject west build -p auto -b stm32f429i-disco samples/hello_world等 build 完成再打开 Vscode就能看到完整符号索引。3.4 调试环境打通JLink OpenOCD GDB 的握手协议Zephyr 的调试不是点一下 “Run” 就行它需要 JLink或 ST-Link硬件调试器、OpenOCD或 JLinkGDBServer服务端、GDB 客户端、Vscode 的 launch.json 四者精准握手。硬件准备JLink推荐 Segger J-Link EDU Mini$50支持 Cortex-M0/M3/M4/M7固件可升级。接线JLink 的 SWD 接口接板子的 SWDIO/SWCLK/GND注意 VREF 引脚必须接板子的 VCC3.3V否则 JLink 无法识别电压电平。软件安装# OpenOCD如果不用 JLinkGDBServer sudo apt install openocd # 或 JLink 软件包官网下载 JLink_Linux_V798a_x86_64.deb sudo dpkg -i JLink_Linux_V798a_x86_64.deb sudo apt --fix-broken install # 解决依赖Vscode 的launch.json配置.vscode/launch.json{ version: 0.2.0, configurations: [ { name: JLink Debug, type: cortex-debug, request: launch, servertype: jlink, device: STM32F429ZI, interface: swd, cwd: ${workspaceFolder}, executable: ./build/zephyr/zephyr.elf, svdFile: ${workspaceFolder}/zephyr/boards/arm/stm32f429i-disco/svd/stm32f429.svd, runToMain: true, armToolchainPath: /usr/lib/arm-none-eabi/gcc, showDevicelist: false } ] }参数详解servertype: jlink告诉插件用 JLinkGDBServer不是 OpenOCD。device必须和 JLink Commander 里exec device命令列出的设备名完全一致查 JLink 手册STM32F429ZI 是标准名。executable指向 build 生成的 ELF 文件路径必须准确。Zephyr 默认 build 输出在build/zephyr/zephyr.elf。svdFileSVD 文件提供外设寄存器定义让调试器能显示 GPIOA-ODR 这样的符号而不是 0x40020014。Zephyr 官方不提供 SVD需从 ST 官网下载STM32F429xx.svd放到指定路径。启动调试前必须确保 JLink 驱动已加载# 检查 JLink 是否识别 JLinkExe -device STM32F429ZI -if SWD -speed 4000 # 如果报错 No USB device found拔插 JLink或运行 sudo modprobe usbserial vendor0x1366 product0x0101常见问题点击 “Start Debugging” 后卡在 “Launching GDB Server…”。原因通常是 JLink 固件版本太低。解决方案下载 JLink Commander运行exec fw_upgrade升级固件。升级后重启 JLink。4. 实操全流程从 Hello World 到真机烧录的完整链路4.1 创建第一个应用samples/hello_world 的深度剖析Zephyr 的 sample 不是玩具是经过全平台验证的最小可行单元。samples/hello_world看似简单却包含了 Zephyr 的核心范式。进入 workspacecd ~/zephyrproject创建 build 目录并配置west build -p auto -b stm32f429i-disco samples/hello_world参数解读-p auto清理之前的 build但保留 CMake cache加速重配置。-b stm32f429i-disco指定板卡对应zephyr/boards/arm/stm32f429i-disco目录。samples/hello_world应用路径相对zephyr目录。configure 阶段会输出关键信息-- The C compiler identification is GNU 10.2.1 -- Zephyr version: 3.4.0 (/home/user/zephyrproject/zephyr) -- Found Python3: /usr/bin/python3.10 (found suitable version 3.10.12, minimum required is 3.8) -- Board: stm32f429i-disco -- Cache files will be written to: /home/user/.cache/zephyr -- Configuring done -- Generating done -- Build files have been written to: /home/user/zephyrproject/build注意Cache files路径Zephyr 把 Kconfig 生成的autoconf.h、devicetree 生成的generated_dts_board.h全缓存在这里避免重复解析。build 阶段west build -t run-t run是 ninja target等价于ninja -C build run它会编译所有源码生成zephyr.elf调用objcopy生成zephyr.bin二进制镜像调用openocd或JLinkGDBServer烧录到 Flash启动 GDB 连接停在main()入口实测对比west build -t run比手动ninja -C build多出烧录和调试环节但前提是你的 board 目录里有support/openocd.cfg或support/jlink.cfg。stm32f429i-disco 两者都有所以能一键烧录。4.2 烧录与串口监控minicom 是最稳的终端工具烧录成功后板子会运行 hello_world通过 UART1 输出 “Hello World! stm32f429i_disco”。但你得看到它。Ubuntu 自带screen但对 USB 串口支持不稳定。我坚持用minicomsudo apt install minicom # 查找串口设备 ls /dev/tty* | grep -E (USB|ACM) # 通常是 /dev/ttyACM0 或 /dev/ttyUSB0 # 配置 minicom sudo minicom -s # 在菜单里设置Serial port setup → A Serial Device /dev/ttyACM0, E Bps/Par/Bits 115200 8N1, F Hardware Flow Control No, G Software Flow Control No # Save setup as dfldefault # Exit and save启动 minicomminicom按CtrlA然后Z选Restart就能看到输出***** Booting Zephyr OS v3.4.0 ***** Hello World! stm32f429i_disco注意事项minicom 默认开启 RTS/CTS 流控但 STM32 的 USART 不支持硬件流控。必须关掉否则串口卡死。另外有些 USB 转串口芯片如 CH340需要加载驱动sudo modprobe ch341 sudo chmod arw /dev/ttyUSB04.3 修改应用并验证从 printf 到 GPIO 控制的跃迁验证环境稳定后动手改代码。打开zephyr/samples/hello_world/src/main.c原始代码#include zephyr/kernel.h #include zephyr/sys/printk.h void main(void) { printk(Hello World! %s\n, CONFIG_BOARD); }改成控制 LEDstm32f429i-disco 板载 LD1 绿灯接 PC0#include zephyr/kernel.h #include zephyr/sys/printk.h #include zephyr/drivers/gpio.h #include zephyr/sys/gpio.h #define LED0_GPIO_PORT GPIOC #define LED0_GPIO_PIN 0 void main(void) { const struct device *dev; int ret; dev device_get_binding(LED0_GPIO_PORT); if (!dev) { printk(Error: failed to get %s device\n, LED0_GPIO_PORT); return; } ret gpio_pin_configure(dev, LED0_GPIO_PIN, GPIO_OUTPUT_ACTIVE); if (ret 0) { printk(Error: failed to configure LED0 GPIO pin %d\n, LED0_GPIO_PIN); return; } while (1) { gpio_pin_set(dev, LED0_GPIO_PIN, 1); k_msleep(500); gpio_pin_set(dev, LED0_GPIO_PIN, 0); k_msleep(500); } }关键点device_get_binding()通过设备树名称获取 GPIO 设备名称必须和zephyr/boards/arm/stm32f429i-disco/stm32f429i_disco.dts里gpioc的 label 一致。gpio_pin_configure()配置引脚为输出模式GPIO_OUTPUT_ACTIVE表示高电平点亮LD1 是共阳极所以 1灭0亮等等查原理图——这里暴露了 Zephyr 的一个坑board dts 文件里gpioc的status okay但没定义leds子节点。所以LED0_GPIO_PORT应该是GPIOC但实际 LED 控制逻辑要看原理图。stm32f429i-disco 的 LD1 接 PC0低电平点亮所以gpio_pin_set(dev, LED0_GPIO_PIN, 0)才亮。修改后重新 buildwest build -p auto -b stm32f429i-disco samples/hello_world west build -t run观察 LD1 是否闪烁。如果没反应用万用表测 PC0 电压确认是 0V 还是 3.3V。实操心得Zephyr 的 GPIO 驱动默认不启用必须在 prj.conf 里加CONFIG_GPIOy CONFIG_GPIO_STM32y否则device_get_binding(GPIOC)返回 NULL。这个配置项藏在zephyr/boards/arm/stm32f429i-disco/stm32f429i_disco_defconfig里但如果你用west build它会自动合并。不过为了保险还是在samples/hello_world/prj.conf里显式写上。5. 常见问题排查那些让你抓狂半小时的“小问题”5.1 west update 失败网络、权限、Git 配置的三重陷阱问题现象west update卡在某个子模块报错 “fatal: unable to access ‘https://github.com/...’: Could not resolve host: github.com”排查路径检查 DNSnslookup github.com如果超时换 DNSecho nameserver 114.114.114.114 | sudo tee /etc/resolv.conf检查 Git HTTPS 代理如果公司网络需代理配置 Gitgit config --global http.proxy http://proxy.company.com:8080 git config --global https.proxy https://proxy.company.com:8080检查 Git SSL 验证内网 Git 服务器可能用自签名证书关闭验证git config --global http.sslVerify false问题现象west update报错 “error: Your local changes to the following files would be overwritten by merge”根本原因你手动修改了某个子模块的代码比如改了hal_stm32的某个驱动但 west 试图把它 reset 到 manifest 指定的 commit。解决方案如果修改是临时测试先 stashcd zephyr/modules/hal/stm32 git stash west update git stash pop # 恢复修改如果修改是长期需求fork 该仓库在 west.yml 里修改 URL 指向你的 fork并设revision为你 commit hash。5.2 Vscode 无法跳转CMake Tools 的缓存与路径错位问题现象按 CtrlClick 无法跳转到kernel.h或跳转到错误路径如/usr/include/kernel.h排查步骤检查CMake: Select a Kit按 CtrlShiftP → “CMake: Select a Kit”选择 “GCC for ARM”不是系统 GCC。检查CMake: Configure是否成功状态栏应显示 “Ready” 和 Board 名。如果显示 “Not configured”点击它重新 configure。检查compile_commands.json是否生成ls build/compile_commands.json如果不存在手动运行cd build cmake -G Ninja -DBOARDstm32f429i-disco ../zephyr/samples/hello_world检查c_cpp_properties.jsonVscode 自动生成但有时路径错误。手动修正includePathincludePath: [ ${workspaceFolder}/zephyr/include, ${workspaceFolder}/zephyr/subsys, ${workspaceFolder}/build/zephyr/generated, ${workspaceFolder}/zephyr/drivers ]5.3 烧录失败JLink、OpenOCD、权限的三角矛盾问题现象west build -t run报错 “JLinkARM.dll not found” 或 “Failed to open device”终极排查清单检查项命令正常输出JLink 是否识别JLinkExe -device STM32F429ZI -if SWD“Connecting to J-Link via USB… Connected”USB 权限ls -l /dev/ttyACM*crw-rw---- 1 root dialoutdialout 组权限groups输出包含dialoutJLink 固件版本JLinkExe -versionV7.98a≥V7.80OpenOCD 配置cat zephyr/boards/arm/stm32f429i-disco/support/openocd.cfg包含source [find interface/jlink.cfg]权限修复sudo usermod -a -G dialout $USER # 注销重登或运行 newgrp dialoutOpenOCD 替代方案如果 JLink 不稳定换 OpenOCD# 修改 launch.json 的 servertype: openocd # 确保 openocd.cfg 存在且路径正确 west build -t flash # 不启动 GDB只烧录5.4 串口无输出时钟、UART、引脚复用的硬件级排查问题现象烧录成功但 minicom 看不到任何输出硬件级 checklist确认 UART 引脚stm32f429i-disco 的 USART1_TX 是 PA9RX 是 PA10。查原理图确认跳线帽 JP1/JP2 是否短接出厂默认短接。确认时钟使能Zephyr 的uart_stm32驱动依赖 RCC 时钟但hello_world默认不启用 UART。必须在prj.conf加CONFIG_SERIALy CONFIG_UART_CONSOLEy CONFIG_UART_STM32y确认引脚复用PA9/PA10 默认是 GPIO需配置为 AF7USART1。Zephyr 的 devicetree 会自动处理但前提是stm32f429i_disco.dts里usart1节点status okay。检查cat zephyr/boards/arm/stm32f429i-disco/stm32f429i_disco.dts | grep -A 5 usart1应输出