RuView 无硬件测试 ESP32-S3 固件QEMU 安装与 qemu-cli.sh 单次测试首跑【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView如果你手边没有 ESP32-S3 开发板但想在电脑上验证 RuView 的 ESP32-S3 CSI 节点固件能否正常启动和跑通数据处理管线项目提供了一条纯 QEMU 模拟的测试路径安装带 ESP32-S3 机器支持的 Espressif QEMU 分支然后执行bash scripts/qemu-cli.sh test完成一次单节点固件测试编译、合并 flash 镜像、在 QEMU 中启动、校验串口输出。整条路径不需要任何物理硬件适用环境为 Linux 或 macOS原生 Windows 不被安装脚本支持要求 Python 3.8且首次运行需要 ESP-IDF 工具链来编译固件。准备条件执行单次测试前文档列出的前置条件分三类QEMUEspressif 分支带esp32s3机器支持。标准发行版软件源里没有支持 ESP32-S3 的 QEMU 包必须从 Espressif 的 QEMU 分支构建这也是为什么项目自带安装脚本。Python 3.8。测试脚本用它合并 flash 镜像并运行输出校验。ESP-IDF 环境提供idf.py。qemu-cli.sh test的第一步就是调用idf.py -C firmware/esp32-csi-node -D SDKCONFIG_DEFAULTSsdkconfig.defaults;sdkconfig.qemu build编译固件所以首跑前必须先具备 ESP-IDF项目的 CI 使用espressif/idf:v5.4容器完成同样的事。如果你已经编译过固件可以用SKIP_BUILD1跳过这一步见后文。Windows 用户注意安装脚本检测到原生 Windows/MINGW 时直接报错退出退出码 3文档给出的替代路径是 WSLwsl bash scripts/install-qemu.sh、Docker或从 Espressif QEMU 分支的 releases 下载预构建二进制。安装 QEMU运行 install-qemu.sh推荐入口是项目安装脚本它也可以经qemu-cli.sh install触发# 在仓库根目录执行 bash scripts/install-qemu.sh这个脚本的副作用比较明确运行前需要了解它做什么通过包管理器apt/dnf/pacman/zyppermacOS 用 Homebrew以 sudo 安装系统构建依赖如git、build-essential、ninja-build、libslirp-dev、libgcrypt-dev等将 Espressif QEMU 分支默认分支esp-develop浅克隆克隆到~/.espressif/qemu执行./configure --target-listxtensa-softmmu --enable-slirp --enable-gcrypt --prefix~/.espressif/qemu/dist并make构建在~/.local/bin/qemu-system-xtensa建符号链接若~/.local/bin不在PATH中会提示你把export PATH$HOME/.local/bin:$PATH加进 shell 配置以pip3 install --user方式安装 Python 工具esptool、pyyaml、esp-idf-nvs-partition-gen失败只警告不中断。常用参数摘自脚本帮助--check只检查现有安装--install-dir DIR改安装目录默认~/.espressif/qemu--jobs N指定并行构建数默认nproc--skip-deps跳过系统依赖安装--uninstall删除安装目录和符号链接。脚本退出码含义0成功1依赖安装失败2构建失败提示检查构建输出、重装依赖、改用--jobs 1macOS 上确认已安装 Xcode CLT3不支持的操作系统。验证安装bash scripts/install-qemu.sh --check # 只验证是否已装好退出码 0 表示可用安装脚本最后会自行执行一次版本验证并检查-machine help输出中是否列出esp32s3机器类型。此外qemu-cli.sh提供统一的状态查看命令可一次看到 QEMU 版本与路径、IDF_PATH是否设置、Python/Clang 是否可用、固件是否已构建、swarm 预设列表bash scripts/qemu-cli.sh status若status显示 QEMU: not found说明二进制没被探测到。qemu-cli.sh按以下顺序寻找 QEMU环境变量QEMU_PATH→PATH中的qemu-system-xtensa→~/.espressif/qemu/build/qemu-system-xtensa。如果你手动构建在别处用QEMU_PATH指向它即可。如果不想用自动安装器文档也给出了手动安装路径克隆 Espressif QEMU 分支后执行./configure --target-listxtensa-softmmu --enable-slirp、make -j$(nproc)然后export QEMU_PATH$(pwd)/build/qemu-system-xtensa并pip install esptool pyyaml esp-idf-nvs-partition-gen。首跑单次测试qemu-cli.sh testQEMU 就绪后在仓库根目录执行bash scripts/qemu-cli.sh test等价的直接写法是bash scripts/qemu-esp32s3-test.sh两者内容一致test只是统一 CLI 的封装。脚本内部依次做四件事编译固件mock CSI 模式按sdkconfig.defaults;sdkconfig.qemu两个配置叠加层调用idf.py build。mock CSI 模式让固件不读真实 WiFi 信号而是由定时器注入合成的 CSI 帧模拟空房间、静止/走动的人、跌倒等场景。合并 flash 镜像用 esptool 把bootloader/bootloader.bin0x0、partition-table.bin0x8000、esp32-csi-node.bin0x20000等合并为单文件firmware/esp32-csi-node/build/qemu_flash.bin8MBdio/80m若构建目录里存在nvs_test.bin或你通过NVS_BIN指定了 NVS 分区会注入到 0x9000 偏移。QEMU 中运行qemu-system-xtensa -machine esp32s3 -nographic -drive file...,ifmtd,formatraw -serial mon:stdio -no-reboot默认超时 60 秒UART 输出实时打印并保存到firmware/esp32-csi-node/build/qemu_output.log。默认开启 SLIRP 用户态网络-nic user,modelopen_eth,net10.0.2.0/24,host10.0.2.2固件的 UDP 流会发往10.0.2.2设置QEMU_NET0可关闭。校验输出调用 scripts/validate_qemu_output.py 解析串口日志并打印校验报告。常用环境变量均来自脚本头部说明QEMU_TIMEOUT改超时秒数默认 60SKIP_BUILD1跳过idf.py build前提是构建产物已存在QEMU_PATH指定 QEMU 二进制QEMU_NET0关网络。慢机器上建议QEMU_TIMEOUT120 bash scripts/qemu-esp32s3-test.sh如何判断首跑成功用户指南说明该测试会对固件输出运行 16 项检查文档中的成功示例输出如下这是文档示例不是每次必须逐字一致的固定结果 QEMU ESP32-S3 Firmware Test (ADR-061) [PASS] Boot: Firmware booted successfully [PASS] NVS config: Configuration loaded from flash [PASS] Mock CSI: Synthetic WiFi data generator started [PASS] Edge processing: Signal analysis pipeline running [PASS] Frame serialization: Data packets formatted correctly [PASS] No crashes: No error conditions detected ... 16/16 checks passed Test Complete (exit code: 0) 判断依据是退出码退出码含义后续动作0PASS全部通过无需处理1WARN非关键检查失败查看报告中的 WARN 行QEMU 下没有真实 WiFi部分 WARN 属预期2FAIL关键检查失败按[FAIL]/ERROR行定位后重跑3FATAL无法启动或崩溃通常是缺工具、构建失败或崩溃先按报错信息补齐前置条件校验器关注的核心项包括启动出现app_main()或main_task:等启动标志无 panic、NVS 配置加载、mock CSI 生成器启动、边缘处理管线活动、无崩溃指标不出现Guru Meditation Error、assert failed、abort()、堆与栈无错误、无意外重启。其中崩溃、堆错误、栈溢出属于 FATAL 级出现即整体失败。另外注意脚本里 QEMU 因超时被timeout杀掉时退出码 124对一直循环运行的固件属预期现象不算失败。校验器默认在仅有 WARN 时仍返回 0加--strict参数则 WARN 也会以非零码退出。完整日志留在firmware/esp32-csi-node/build/qemu_output.log可事后用python3 scripts/validate_qemu_output.py firmware/esp32-csi-node/build/qemu_output.log复查。首跑常见报错与处理以下排查项均来自用户指南的 Troubleshooting 章节qemu-system-xtensa: command not found标准软件源不提供 ESP32-S3 版 QEMU。按前文手动安装步骤从 Espressif 分支构建或直接用QEMU_PATH/实际路径/qemu-system-xtensa bash scripts/qemu-esp32s3-test.sh指向已有构建。测试超时无输出QEMU 比真机慢用QEMU_TIMEOUT120提高超时若完全没有任何输出可能是固件构建失败去掉SKIP_BUILD重新完整跑一遍。esptool not found脚本用它合并 flash 镜像执行pip install esptool安装。构建失败对照安装脚本的排查建议——检查构建输出、不带--skip-deps重跑补依赖、--jobs 1降低并行度。这条路径测不到什么ADR-061 明确列出了 QEMU 测试的边界首跑成功只说明固件在模拟环境下启动和数据管线正常不代表真实射频行为已验证QEMU 无法模拟 ESP32-S3 的 WiFi 射频和 CSI 提取硬件测试数据全部来自 mock CSI 合成帧不含真实多径与干扰QEMU 时序不是 cycle-accurateFreeRTOS 节拍可能与硬件不同I2C OLED 显示、真实 GPIO、light-sleep 功耗管理、OTA 的完整 HTTP 流程等需要硬件或另行处理。后续如果要扩展到多节点场景同一 CLI 还提供qemu-cli.sh swarmswarm 配置器--preset smoke/standard等预设、qemu-cli.sh mesh N等命令多节点虚拟桥接仅支持 Linux 且需要 root。这些属于独立任务本文不再展开。更多设计细节可参考 ADR-061: QEMU ESP32-S3 Emulation 和 用户指南 QEMU 章节。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考