告别硬件依赖！手把手搭建 Zephyr Native_Sim仿真环境，WSL下实现高效开发与测试

在嵌入式软件开发过程中，经常会遇到这样的场景：项目刚刚起步，硬件尚未到位；或者仅仅需要验证应用逻辑、执行单元测试，却不得不等待开发板资源。面对这些需求，软件仿真平台成为提升开发效率的重要手段。

此前，我们已经介绍过如何利用QEMU搭建Zephyr软件仿真环境。而今天，小编将为大家带来另一条更加轻量化的技术路线：Zephyr Native_Sim平台。

Native_Sim是Zephyr官方提供的软件仿真方案。它基于Linux主机的POSIX支持，将Zephyr应用直接编译为本机可执行程序，无需任何目标硬件即可运行和调试，非常适合功能验证、自动化测试以及持续集成（CI）场景。

本文将基于WSL（Windows Subsystem for Linux）环境，从零开始完成Native_Sim环境搭建，并重点讲解以下内容：

• 安装Native_Sim所需依赖

• 配置Python开发环境和West工具

• 使用系统GCC工具链进行编译

• 构建默认32位Native_Sim

• 构建64 位Native_Sim

• 解析BOARD_NATIVE_SIM_NATIVE_64的来源与作用

• 常见错误排查与解决方案

一、安装 Native_Sim 运行环境

首先更新系统软件源：

| sudo apt update |

安装Native_Sim所需的基础开发工具和依赖库：

| sudo apt install -y build-essential   libc6-dev ninja-build cmake device-tree-compiler gcc-multilib |

各组件作用如下：

• build-essential：提供GCC、G++、Make等基础开发工具
• ninja-build：Zephyr默认使用Ninja作为构建后端
• cmake：Zephyr构建系统核心组件
• device-tree-compiler（dtc）：用于设备树编译
• gcc-multilib：提供32位编译与运行支持

需要注意的是，Native_Sim默认生成32位程序。如果系统缺少对应运行库，执行生成的程序时可能出现错误,因此建议提前安装多架构支持，以避免后续编译运行问题。

二、创建Python虚拟环境并安装West

虽然Native_Sim不依赖Zephyr SDK，但West作为Zephyr的官方项目管理工具仍然是必不可少的。

创建Python虚拟环境：

| python3 -m venv ~/zephyr-venv   source ~/zephyr-venv/bin/activate |

随后即可通过pip安装和管理West及相关工具链组件。

采用虚拟环境的好处在于能够避免系统Python环境被污染，同时便于维护不同版本的开发环境。

三、使用系统GCC工具链

对于Native_Sim平台而言，并不强制要求安装Zephyr SDK。

由于目标程序最终运行在当前Linux主机上，因此直接使用系统GCC即可完成编译，这种方式更加轻量，也更适合快速验证和测试。

只需设置一个环境变量，即可让Zephyr使用主机工具链：

| export ZEPHYR_TOOLCHAIN_VARIANT=host |

如果需要显式指定编译器，还可以额外设置：

| export CC=gcc   export CXX=g++ |

四、构建默认32位Native_Sim（默认方式）

Zephyr的Native_Sim默认工作在32位模式。

执行构建：

| west build -b native_sim -p

生成的程序位于：

build/zephyr/zephyr.exe

可以直接运行：

./build/zephyr/zephyr.exe |

需要特别注意的是，如果使用WSL环境且未安装32位兼容库，程序可能无法正常启动。因此建议提前安装前文提到的多架构支持包。

五、构建64位Native_Sim（推荐）

实际开发中，很多工程师更倾向于使用 64 位程序，因为它能够：

• 减少对 i386 运行库的依赖

• 提供更加现代的运行环境

• 与当前主流 Linux 发行版保持一致

• 更方便后续集成调试工具

这里需要强调一个常见误区：

仅仅给CFLAGS添加-m64是无效的，因为Zephyr的native_sim内部会自动插入-m32。

正确的方法有两种：

方法一：通过Kconfig开启64位支持（推荐）

在工程的 prj.conf 文件中增加：这是官方推荐的配置方式，也是兼容性最好的方案。

| 在 prj.conf 中加入：

CONFIG_BOARD_NATIVE_SIM_NATIVE_64=y

然后重建：

west build -t pristine --pristine -d   build   west build -b native_sim -d build

检查是否成功：

file build/zephyr/zephyr

输出应为：

ELF 64-bit LSB executable, x86-64 |

方法二：直接指定64位Board（Zephyr新版支持）

一些Zephyr版本支持指定：

west build -b native_sim/native/64 -p

这种方法依赖于具体版本的Board目录结构。

因此从长期维护和兼容性角度考虑，仍建议优先使用Kconfig配置方案。

六、深入理解BOARD_NATIVE_SIM_NATIVE_64

在查看构建日志或源码时，经常能够看到：

BOARD_NATIVE_SIM_NATIVE_64

这个宏不是CMake定义的，也不是编译器生成的，而是来自native_sim的Kconfig。

路径位置：boards/native/native_sim/Kconfig

其中包含以下配置项：

config BOARD_NATIVE_SIM_NATIVE_64bool "Build native_sim as 64-bit"

当Kconfig选择此项后：- Zephyr会自动生成#define CONFIG_BOARD_NATIVE_SIM_NATIVE_64 1- CMake根据此宏，将ARCH_FLAG设置为-m64- 编译器生成64-bit ELF程序

因此，该宏的本质：它是一个Kconfig选项控制的编译特性，而不是工具链或CMake自主决定的。

七、常见问题排查

1. Exec format error

原因：系统缺少32位运行环境。

解决方案：

| sudo dpkg --add-architecture i386   sudo apt update   sudo apt install libc6:i386 libstdc++6:i386 libgcc-s1:i386 |

2. Could NOT find Dtc

| 安装 dtc：

sudo apt install device-tree-compiler |

3. CMake was unable to find Ninja

| 安装 ninja：

sudo apt install ninja-build |

4. 添加-m64后仍然生成32位程序

| 原因：Zephyr内部强制加了-m32。解决：必须使用Kconfig：

CONFIG_BOARD_NATIVE_SIM_NATIVE_64=y |

八、结语

Native_Sim是Zephyr生态中非常实用的一款软件仿真平台。与QEMU相比，它无需模拟完整硬件系统，而是直接将Zephyr应用编译为Linux本机程序，因此拥有更快的编译速度、更高的运行效率以及更简洁的调试流程。

通过本文介绍的方法，我们不仅完成了WSL环境下Native_Sim的搭建，还深入分析了默认32位构建机制、64位切换方案以及BOARD_NATIVE_SIM_NATIVE_64的实现原理。

掌握Native_Sim后，即使没有任何目标硬件，也能够快速验证应用逻辑、执行自动化测试，并大幅提升Zephyr项目的开发效率。对于日常开发、单元测试以及CI/CD场景而言，这无疑是一把不可多得的“效率利器”。

如果你正在使用Zephyr进行嵌入式开发，不妨将Native_Sim纳入日常开发流程，让软件验证不再受硬件资源限制。