【轻AI越影视觉开发板】fw_cli：被埋起来的命令行（不用 UI 直接驱动 NPU）

文章目录一、先把它找出来二、三组命令覆盖这块板的全部视觉能力三、实战一30 秒确认 NPU 是活的四、实战二把 NPU 压到极限以及一个必须修正的测法反过来还有个坑mac_utilization 是死数顺带测到的NPU 是单流时间片串行五、实战三换模型时撞到的 1.34 MB第一个条件容量上限约 1.34 MB第二个条件装得下的不管好坏都收六、六个必须知道的坑七、它比 UI 和聊天渠道好在哪八、给厂商的一句话九、命令速查出厂镜像里有一个命令行工具fw_cli三组命令、十几个子命令把摄像头、NPU 检测、人脸识别全部暴露成纯文本接口。它不在任何一篇官方文档里83 篇 docs 出现 0 次也不在 28 个官方 AI skill 里同样 0 次。唯一入口藏在apps/cv610_ev_board/references/factory_demo/ws73_lcd/——相对apps第 5 层目录名跟命令行毫无关系。但它是我在这块板上找到的最适合教学的 NPU 入口。这篇把它的用法、六个坑、以及用它测出来的性能数据一次讲完。一、先把它找出来板上直接就有rootcv610:~# ls -l /root/fw_cli-rwxr-xr-x1root root... /root/fw_cli rootcv610:~# ./fw_cliusage: fw_clicmd[args...]它随出厂镜像一起发不需要编译、不需要 rootfs 改造。源码在 SDK 里# 在 hi_aiot_solution 里找findapps-namefw_cli*-o-name*fw_cli*|head# → apps/cv610_ev_board/references/factory_demo/ws73_lcd/rootfs/...ws73_lcd这个名字是Wi-Fi 屏的出厂 demo所以除非你像我一样为了写评测把源码翻了一遍否则不会想到命令行工具藏在这里。二、三组命令覆盖这块板的全部视觉能力命令组子命令作用摄像头camera_open/camera_close/camera_capture开流 / 关流 / 抓拍落盘NPU 检测aidetect_create/aidetect_start/aidetect_listen/aidetect_stop/aidetect_destroy/aidetect_status建任务 / 启动 / 订阅结果 / 停止 / 销毁 / 查状态人脸识别fr_run/fr_register检测 特征提取级联 / 注册人脸注意它没有音频命令。这三组就是全部——也正好说明这块板的出厂定位是纯视觉。想看喇叭响不响fw_cli帮不了你这也是我在评测里把放音自检列为建议的原因。三、实战一30 秒确认 NPU 是活的这是fw_cli最有用的场景。三条命令# 1. 建任务模型 检测间隔毫秒./fw_cli aidetect_create /root/det_hvf_hor.bin5# 2. 启动./fw_cli aidetect_start0# 3. 订阅结果抓 20 帧./fw_cli aidetect_listen020输出长这样[aidetect][task 0] frame#1: 0 objects [aidetect][task 0] frame#2: 1 objects [aidetect][task 0] frame#3: 1 objects ... [aidetect] total 20 frames: 1 objects判据极简人走进画面0 objects变1 objects走出画面变回 0。对比一下点触屏看框后者也能看到框但学生不知道框是哪来的、多久出一次、能不能改。前者把检测 一次函数调用 一个调度参数这件事直接摆在终端里讲原理的成本低一个数量级。四、实战二把 NPU 压到极限以及一个必须修正的测法出厂模型det_hvf_hor是 YOLOv8n 级、448×768、三分类人 / 人脸 / 车1.32 MB。测它的上限直觉做法是扫interval_msforivin10050453320101;do./fw_cli aidetect_create /root/det_hvf_hor.bin$iv./fw_cli aidetect_start0./fw_cli aidetect_listen0100./fw_cli aidetect_destroy0done用aidetect_listen数帧算出来的结果是interval_mslisten 实测 fps1009.115016.723322.29122.08看起来天花板 22 fps33 ms 之后就不动了。但这个读数是错的。listen本身要订阅结果、走 IPC、打印文本这些开销都算进了你的测量里。要拿到真值得找一个不经过应用层的计数器。这块板上有# 每次推理恰好 1 个中断cat/proc/umap/svp_npu|greptotal_irq_cnt交叉验证TEST A不监听irq 716 次 / 30 s 23.87 /s TEST B同时监听irq 715 次 / 30 s 23.83 /s listen 数到 703 帧 23.43 fps → irq/frame 1.017每次推理 1 个中断所以 IRQ 增量就是真实推理次数。结论天花板是 24.3–24.5 fps不是 22 fps单帧 40.8 mslisten订阅带来约1.8%开销抓固定 100 帧的方式又叠加了命令启停开销共同把读数压到 22.1。这是这次评测里最有价值的方法论教训在嵌入式板上任何通过应用层观察得到的性能数字都必须用一个不经过应用层的计数器交叉验证。否则你测的是框架开销不是硬件。顺便还能读到硬件忙闲比它和帧率严格线性interval_msIRQ/s真值hw_utilization1009.3030.4 %5017.2054.4 %4520.5066.0 %3324.3077.6 %124.5078.0 %hw_utilization / fps ≈ 3.19全程恒定、无拐点每帧消耗约 3.19% 的硬件时间单位。有意思的是饱和之后帧率不再上涨硬件却仍有22%的空闲。这 22% 是任务切换、DDR 等待、驱动开销产生的气泡。理论上限是24.5 ÷ 0.78 ≈ 31 fps——说明这块板的 NPU 瓶颈不在 MAC 阵列在数据供给。反过来还有个坑mac_utilization是死数同一张表里mac_utilization恒为44空闲态hw_status0读 44压到 1 ms 仍是 44。这个字段不随负载变化不能用于任何分析。照着字面理解MAC 只用 44%会得出完全错误的结论。顺带测到的NPU 是单流时间片串行同时建 N 个任务同一个 om测 25 秒的总 IRQ 增量同时任务数总 IRQ/s折算单任务 fps123.9223.92224.0012.00324.888.29加任务不增加总吞吐只是分摊。这也回答了那个教学场景里的经典问题——“能不能同时跑目标检测 人脸识别”能跑但两个模型各自只剩约 12 fps。官方fr_run检测 特征提取双模型级联实际就是这个量级。五、实战三换模型时撞到的 1.34 MBaidetect_create的第一个参数就是模型路径看起来换模型不用改一行代码./fw_cli aidetect_create /root/my_model.bin5实测下来这句话有条件。第一个条件容量上限约 1.34 MB拿官方的yolo11s-pose_610_SVPNNN.om10.89 MB直接喂失败只回一句create_task: ipc_ret0x0 ret-1593737209 create_task ipc failed: 0x0 ret-1593737209 aidetect create_task failed 0xffffffff三种封装裸 om、补 32 字节 MD5 头、补 64 字节双 ID 头全部失败。改用内容有效、只改文件大小的零填充扫描才找到真因文件大小create1,382,752原始✅1,403,23220 KB✅1,433,60050 KB❌2 / 4 / 8 / 11.4 MB❌上限约 1.34 MB。旁证很硬出厂模型正好 1.32 MB贴着上限——厂商是按通道容量反推选的模型不是按任务需要选的。所以准确说法不是这块板跑不了 pose而是出厂的 aidetect 通道装不下 pose。同一块板走 ACL 直连svp_acl_mdl_load_from_file能跑 10.89 MB 的 poseSDK 自带的 resnet50.om 甚至 26 MB。第二个条件装得下的不管好坏都收用截断 / 填充构造 7 组输入全走create → start → listen输入createstartlisten判定完整模型 1.32 MB✅✅正常出帧基线截断到 1.00 MB缺 24%✅✅正常出帧0 objects静默接受截断到 100 KB / 4 KB / 64 B❌——拒绝1 MB 随机数据❌——拒绝模型文件格式是32 字节 ASCII MD5 串 模型数据头部值是f97d7c27...。校验头存在但从来没被用上。这是最坏的一类故障模型损坏传输中断、写盘未 sync、存储 bit rot时系统报一切正常只是永远0 objects。用户会判断成画面里没人而不是模型坏了。课堂 30 个人同时部署谁的模型传坏了完全看不出来。六、六个必须知道的坑#坑现象正确做法1interval_ms传 0 ≠ 不限速日志create_task ok, chn0 interval100ms0 回落到默认 100 ms约 10 fps。要测峰值传 10 / 12listen输出只有数量frame#N: 0 objects没有类别、坐标、置信度。只能测帧率与有没有检出做不了精度评估3count边界不精确listen 0 5实际打印 frame#1~#7测帧率用大 count 摊薄4任务生命周期与进程不绑CLI 退出后服务端打印cleanup task_id0但再start 0仍成功它实际是绑定 chn 0 的常驻通道对象。串行敲命令没问题写长跑脚本要小心5create与start是两段式create ok之后毫无动静create 只做注册start 才下发到 NPU。换模型能不能用光看 create ok 毫无意义必须跑到 listen 看 objects6start是异步的start 后立刻查status读running0等约 1 秒才翻转。不是失败做自动化脚本容易误判另外补两条报错层面的坑这是可诊断性最差的地方0xffffffff至少对应3 种完全不同的原因文件超 1.34 MB、格式不符、MMZ 未释放连续 create 多个任务后后续 create 会连续失败必须先aidetect_destroy清干净。ret-15937372090x5EFE7FF9不是任何标准错误码形态像被截断的地址——说明错误分支上的ret未初始化。七、它比 UI 和聊天渠道好在哪维度触摸 UI聊天渠道QQ/飞书fw_cli依赖网络否是否本地命令可脚本化否否是输出可记录/可 diff否半是纯文本门槛最低低需要 ssh适合场景演示、验硬件远程看画面教学、性能测绘、自动化三者不是替代关系。我在评测里的用法是UI 负责看起来能用fw_cli负责证明它真的在算。八、给厂商的一句话fw_cli是这块板上投入产出比最高的一个改进点在 README 首屏加一节「不做 UI 也能验证的 5 条命令」五条就够——camera_open、aidetect_create、aidetect_start、aidetect_listen、camera_capture。成本是半小时的文档工作量。收益是用户拿到板子的第一分钟就能在终端里看到0 objects → 1 objects而不是先学会连 Wi-Fi、配网、点触屏、找到检测页。顺带两个小建议把0xffffffff拆开。现在的三种原因共用同一个返回值而它们的处置方式完全不同换小模型 / 换格式 / 销毁旧任务。把 1.34 MB 的上限写进aidetect_create的文档和报错里。现在它是个只存在于实测里的隐形天花板而按官方指引换模型的第一件事就是撞它。九、命令速查# 基础./fw_cli camera_open# 开流./fw_cli camera_close# 关流./fw_cli camera_capture /mnt/cap11# 抓 1 张到 chn1JPEG参数是 base_path 不带后缀./fw_cli aidetect_createmodel.bininterval_ms./fw_cli aidetect_starttask_id./fw_cli aidetect_listentask_idcount./fw_cli aidetect_stoptask_id./fw_cli aidetect_destroytask_id./fw_cli aidetect_statustask_id./fw_cli fr_run...# 检测 特征提取级联./fw_cli fr_register...# 性能观测不经过应用层cat/proc/umap/svp_npu|grep-Etotal_irq_cnt|hw_utilization|last_hw_task_timecat/proc/umap/vpss|grepsend_ok# 帧计数增量cat/proc/umap/vi|head-30两个与camera_capture有关的实测提醒通道号决定格式chn 0出的是H.265 单帧裸流文件头00 00 00 01 40 01chn 1才是真 JPEG。两者都命名为.jpg接口不做任何提示。命名规则是base .jpg从不检查 base 是否已带扩展名——传/mnt/cap.jpg会得到/mnt/cap.jpg.jpg。一句话总结fw_cli是这块板上能力已经做好、只差被看见的典型。它藏在第 5 层目录却在终端里把整条 NPU 链路讲得比任何文档都清楚。如果你手上正好有一块这个板子第一件该做的事不是点开 UI而是 ssh 上去敲那五条命令。