没开发板也能跑 Zephyr：Windows + QEMU 模拟 Cortex-M3 实战

很多嵌入式开发者刚接触 Zephyr 时，第一反应往往是：“开发板准备好了吗？”其实，在正式连接硬件之前，我们完全可以先在模拟器中完成应用验证、功能测试甚至调试工作。

如果把 Zephyr 比作一本精心编写的菜谱，那么 Cortex-M3 就是今天要烹饪的菜品，而 QEMU 则是承载一切的锅灶。真正开始做菜之前，我们首先需要确认菜谱、食材和锅具是否已经准备就绪。同样，在学习 Zephyr 的过程中，安装并配置好模拟器环境，是迈出高效开发的第一步。

本文默认你已经完成了 Zephyr 开发环境的搭建（West、Zephyr SDK 等工具均已配置完成），接下来将带你在 Windows 环境下借助 MSYS2 安装 QEMU，并运行 Zephyr 官方 Hello World 示例，最终实现自定义应用在 Cortex-M3 模拟器上的运行。即使手边没有开发板，也能提前开启 Zephyr 的学习与开发之旅。

一、为什么需要先把“锅”装好：MSYS2 安装 QEMU（Windows 专用）

Windows 原生环境里并不自带合适的 qemu-system-arm。我们用 MSYS2 来补齐这口“锅”。步骤如下：

1. 安装 MSYS2

打开 https://www.msys2.org/ ，按页内引导安装后，启动 “MSYS2 MINGW64” 终端。

小贴士：不要在 “MSYS” 或 “UCRT64” 里随手乱装，本文统一用 “MINGW64”。

2. 更新包管理器与核心包

在 “MSYS2 MINGW64” 终端执行：

pacman -Syu

如提示重启终端，照做，再次执行：

pacman -Syu

3. 安装 QEMU（64 位）

pacman -S mingw-w64-x86_64-qemu

安装完成后，QEMU 可执行文件位于：

C:\msys64\mingw64\bin\qemu-system-arm.exe

为了在 PowerShell 里也能直接用，建议把 C:\msys64\mingw64\bin 加入系统 PATH。完成后在 PowerShell 验证：

qemu-system-arm --version

至此，灶台与锅具就绪：MSYS2 提供包管理，QEMU 提供“能把指令煮熟”的火力。

二、点火试锅：先跑官方样例，确认油温合适

以 Zephyr 自带的 hello_world 为例，目标板选择 qemu_cortex_m3：

# 在 PowerShell 或者你常用的终端里
cd %ZEPHYR_BASE%
west build -b qemu_cortex_m3 samples/hello_world -p always
west build -t run

如果能看到 “Hello World! qemu_cortex_m3”，说明一切正常，接下来就可以把你自己的菜下锅了。

三、把自家菜谱下锅：构建并运行你的应用

我们推荐将应用放在 Zephyr 源码树之外（out-of-tree），目录最小骨架如下：

my_app/
CMakeLists.txt
prj.conf
src/main.c

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)

src/main.c 随便来个“热锅起油”的心跳：

#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>

int main(void)
{
    printk("Cortex-M3 起锅预热...\n");
    while (1) {
        printk("嘀嗒\n");
        k_sleep(K_MSEC(1000));
    }
    return 0;
}

构建并运行：

west build -b qemu_cortex_m3 D:\path\to\my_app -p always
west build -t run

屏幕每秒“嘀嗒”一次，就像灶台火候稳定，锅里的油温起伏合理——调度节拍、线程睡眠/唤醒、控制台输出都正常。

四、让菜更有层次：Kconfig 推荐开关

在 prj.conf 里先把基本的“声色味”打开，出问题时你能更快闻到焦糊味：

# 基本输出与日志
CONFIG_PRINTK=y
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=3

栈与异常（最重要的“防糊锅”设置）：

CONFIG_INIT_STACKS=y
CONFIG_STACK_SENTINEL=y
CONFIG_EXCEPTION_DEBUG=y

初期把栈开大一些，别省油：

CONFIG_MAIN_STACK_SIZE=2048
CONFIG_ISR_STACK_SIZE=2048

如果暂时不需要外设驱动，初期可关掉，避免 QEMU 不支持的外设初始化导致异常：

CONFIG_GPIO=n
CONFIG_I2C=n
CONFIG_SPI=n
CONFIG_FLASH=n
CONFIG_PWM=n

等主菜稳定，再逐个小料回放，哪个小料一放就糊，问题就指向谁。

五、现场急救：常见翻车与止血

1. 一运行就黑屏退场

多为非法访问或栈太小。先把 MAIN_STACK_SIZE、ISR_STACK_SIZE 调到 4096，并打开 CONFIG_EXCEPTION_DEBUG 捕获异常上下文。

2. 没有任何输出

确认板子是 qemu_cortex_m3 而不是 native_sim。后者是主机进程平台，不会拉起 QEMU。

3. QEMU 报 “Lockup: can't escalate to HardFault”

高概率是异常里又发生异常（比如栈坏、LR/PC 异常、外设寄存器不存在）。别慌，下一篇“调试篇”会教你把火撤下来，从锅底找焦点。

写在最后

至此，我们已经完成了从 QEMU 安装、Zephyr 官方示例验证，到自定义应用构建与运行的完整流程。借助 QEMU 模拟器，即使没有实际硬件，也能够快速验证代码逻辑、熟悉 Zephyr 开发框架，并提前发现系统配置和应用设计中的问题。

对于日常开发而言，模拟器不仅能缩短验证周期，更是学习 Zephyr 内核机制、线程调度以及异常处理的重要工具。先在 QEMU 中确认功能正确，再移植到真实硬件上，往往能够节省大量调试时间。

当然，程序能够运行只是第一步。当系统出现异常、发生 HardFault、线程莫名崩溃时，真正考验开发者的往往是调试能力。下一篇文章，我们将深入 Zephyr 调试实战，结合 Cortex-M3 与 QEMU 环境，带大家定位异常现场、分析调用栈，并快速找出导致系统“翻车”的根源，让你的 Zephyr 开发真正做到“知其然，更知其所以然”。

如果你也在折腾 Zephyr 或嵌入式模拟器，欢迎到云栈社区和更多开发者一起交流避坑经验。