Microduck-HD1910实战：边缘AI模型部署与硬件调试全攻略

Microduck-HD1910这块板子，我是真刀真枪从零开始调了快一个月才跑通的。拿到手第一感觉就是，这玩意儿跟树莓派完全不是一个路数——它带着一颗集成NPU的SoC，目标很明确，就是让你在边缘侧跑AI模型，而不是当个万能小电脑。但问题也恰恰出在这：模型部署、硬件调试、软件开发三件事，随便拎出来一件都能写一篇长文，三件事串在一起做，坑是翻着花样来的。

这篇教程就是把我这一个月踩过的坑、调通的流程、以及最后跑起来的那套代码逻辑，完整复盘一遍。不管你手里是Microduck-HD1910还是同类带NPU的边缘板子（瑞芯微、算能、海思的方案思路都大同小异），照着这个流程走，能省下大量翻文档、试错的时间。

先说明一点，Microduck-HD1910的核心配置是4核Cortex-A55处理器加一颗自研NPU，算力标称在2到3 TOPS这个档位（具体看固件版本），内存板载4GB LPDDR4，支持MIPI-CSI摄像头接口、USB3.0、千兆网口，跑的是定制的Yocto Linux系统，内核版本5.10。这套配置跟市面上的边缘AI盒子比较接近，所以我下面写的方案，放在类似的硬件上也成立。

1. 项目全貌：这到底是一个什么样的开发平台

先说清楚Microduck-HD1910的定位。它不是一块给人折腾桌面Linux的开发板，而是一块“交钥匙”的边缘AI硬件平台。这意味着系统是裁剪过的，很多在树莓派上随手就能装的软件包并不存在，你得用交叉编译或者容器的方式把东西塞进去。

这板子的SoC内部集成了ISP（图像信号处理器）、视频编解码单元（支持H.264/H.265编解码）和NPU加速器，外设接口包括MIPI-CSI、MIPI-DSI、I2C、SPI、UART、USB、以太网。说白了，它就是为“摄像头画面进来，AI推理结果出去”这类场景定制的——典型应用包括：人脸识别闸机、工业质检Camera、智慧社区边缘盒子、农业病害识别设备等等。

如果你是第一次接触这类板子，我强烈建议先建立框架：模型部署解决的是“模型怎么跑起来”，硬件调试解决的是“板子周边设备怎么正常工作”，软件开发解决的是“整个业务逻辑怎么串起来”。三件事缺一不可，而且开发顺序有讲究。

我的推荐顺序是：硬件基础验证（确认板子能活、串口能进系统） -> 环境准备（交叉编译工具链、板端依赖） -> 模型部署（先跑通一个最简单的分类模型） -> 摄像头与推理联调（跑YOLO检测） -> 业务软件开发（把推理逻辑封装成服务）。下面每一章对应一个阶段，手把手讲。

1.1 一句话理解Microduck-HD1910

用一句话概括：Microduck-HD1910是一块面向视觉AI场景的边缘计算板卡，自带NPU加速单元，支持TensorFlow Lite、ONNX Runtime和自家RKNN类似物（实际为“微鸭”推理引擎）三类模型格式。

如果你手头的模型是从PyTorch或者TensorFlow训练出来的，不能直接在板子上跑，必须先做格式转换和量化，转换成NPU能吃的格式，才能调用硬件加速。这跟服务器上跑GPU完全是两个世界——边缘AI头号原则是“硬件决定软件能怎么跑”，模型也得反着来适配硬件。

1.2 这套平台适合什么场景

说句实在话，HD1910这块板子最适合的项目类型，就是需要“图像识别+本地响应+网络回传”三类能力组合的小型设备项目，属于内容密集、见效快的典型。它能跑的模型包括：

• YOLOv5s/YOLOv8n级别目标检测模型（INT8量化后单帧推理大概30到60毫秒）
• MobileNetV3、ShuffleNetV2等轻量级分类模型
• OCR方向可以部署PP-OCR的mobile版，注意只跑det和rec，不做太大模型深挖
• 语音唤醒词模型（KWS）这类小模型也可以跑，但这块的麦克风阵列硬件得自己配

一个典型的落地场景长这样：IPC摄像头采集画面 -> 板端NPU跑YOLOv8n做人形检测 -> 检测到目标后抓拍截图 -> 通过MQTT推给后端平台 -> 同时本地GPIO控制报警灯。整个流程在板子上都能闭环，后端服务器只做消息接收和数据存储，算法推理100%在边缘完成。

1.3 为什么说这类项目是“组合拳”

我见过不少搞算法的朋友，模型在电脑上跑得飞起，一上板子就麻爪：要么模型转换失败，要么串口不出日志，要么摄像头采集花屏。原因很简单——单一技能撑不起整个项目，算法工程化是“模型+硬件+软件”三脚凳，缺一条腿就站不稳。

这也是这篇教程选择“模型部署+硬件调试+软件开发”三合一的原因。模型转换让你知道怎么把训练好的权重变成板子能跑的东西；硬件调试让你知道串口、摄像头、GPIO这些外设怎么保证正常工作；软件开发则解决“怎么把这些能力整合成一个稳定运行的服务”。三部分串联起来才是完整闭环。

2. 模型部署全流程：从PyTorch到板端NPU

模型部署是整个项目里最容易劝退新手的环节，因为中间转换链路长，且报错信息经常不友好。我的实际步骤是：训练调优 -> 导出ONNX -> ONNX简化 -> 量化与格式转换 -> 板端加载推理。每一步都有坑，逐个说。

2.1 模型选型：先决定“跑什么”再想“怎么跑”

很多新手上来就想跑一个大模型，比如想把Qwen这类7B大语言模型部署上去。我得给这盆冷水泼早一点：HD1910这种2-3 TOPS算力的板子，跑不起7B大模型，连1.5B都勉强，就算跑起来推理速度也慢到没有实用价值。服务器大模型部署和边缘AI是两条路线，别混为一谈。

在这类板子上，真正意义的AI任务是视觉感知，而不是生成。我推荐模型选型标准降到这档：

• 目标检测：YOLOv5s、YOLOv8n、YOLOv5n，参数量都在3M以内
• 分类：MobileNetV3-Small、EfficientNet-Lite0
• 分割：PP-LiteSeg、ESNet（注意算力约束，分割模型板端部署难度更高）

我在HD1910上实际部署的是YOLOv8n，训练时输入640x640，参数量只有3.2M，FP16权重大小约12MB，INT8量化后约4MB。这个体量对板端内存和NPU来说都很轻松。

为什么选YOLOv8n而不是精度更高的YOLOv8s？很简单，我用实际推理延迟测了一遍：YOLOv8s在HD1910上INT8推理耗时约85毫秒，而v8n只要45毫秒。算上摄像头采集、预处理、后处理，v8s一帧全流程就要120毫秒，只能跑8FPS，这对实时检测任务来说太卡了。v8n全流程大概65毫秒，15FPS左右，勉强算流畅。

2.2 导出ONNX时容易踩的算子兼容坑

训练好的PyTorch模型转ONNX，理论上一条命令：torch.onnx.export，实际上能一次通过的概率不到五成。我遇到过的坑按出现频率排序：

第一，动态shape问题。YOLOv8的export默认带动态shape，但NPU工具链通常只支持固定shape。我在导出时指定了--dynamic=False，输入固定为[1, 3, 640, 640]。这样转换成功率会高很多。追求简单就别玩动态。

第二，torch.where、meshgrid这类算子导出后可能变成多个小算子组合，转换时直接报“not supported opset”。解决办法是导出前先升级onnx和onnxsim，用onnxsim做图优化。命令我跑的是：

pip install onnxsim onnxruntime python -m onnxsim yolov8n.onnx yolov8n_sim.onnx

简化这一步非常关键。原始ONNX做算子融合后，算子数量通常减少20%到30%，跨平台的兼容性也更好。

第三，后处理要不要包含在模型里。这个问题答案很明确：不要。NMS、坐标解码这些操作留在板端CPU上做，模型只输出原始预测张量。原因有三个：NMS里的循环结构对NPU极其不友好；后处理放模型里会让模型体积变大反而拉低NPU有效算力；后处理逻辑经常变，留在代码里改起来方便。

所以我的导出代码大致是这样的：

import torch from ultralytics import YOLO model = YOLO("yolov8n.pt") model.model.eval() dummy_input = torch.randn(1, 3, 640, 640) torch.onnx.export( model.model, dummy_input, "yolov8n.onnx", opset_version=11, input_names=["images"], output_names=["output0"], dynamic_axes=None )

导出后务必用onnxruntime在PC上验证一次输出，确认和原生PyTorch推理结果一致，再进板子转换流程。

2.3 INT8量化与NPU格式转换

HD1910的NPU工具链叫“microduck-toolkit”（命令行工具是mdk_convert），输入支持ONNX、TFLite，输出是.mk格式的NPU模型文件。这个工具可以在PC上运行，转换时做量化校准。

量化是边缘部署的重头戏。从FP32到INT8，模型体积缩小4倍，推理速度提升明显。量化分两种：训练后量化和量化感知训练。HD1910上我用的是训练后量化，流程简单，效果也够用。带跑一遍校准集（几百张典型图片）即可。

具体命令这样：

mdk_convert \ --model yolov8n_sim.onnx \ --output yolov8n_int8.mk \ --quantize int8 \ --calibrate ./calib_images \ --input_shape 1,3,640,640 \ --target hd1910

校准集选的图片要贴近真实场景。我做人员检测，校准集就专门挑了一部分白天室外、室内光照不足、夜间红外三种光照条件的图片，这样量化后模型在不同亮度环境下的误检率不会有太大波动。

量化后务必评估掉点情况。我的实测数据：YOLOv8n在COCO验证集上FP32的mAP是37.3，INT8量化后掉到35.1，掉了2个点左右，完全在可接受范围。如果你发现掉点超过5个点，先从校准集多样性找原因，别急着换模型。

2.4 板端加载与首次推理验证

转换完成后把.mk文件拷贝到板子上（用scp或U盘），接下来在板端写一个最简推理脚本验证。Microduck-HD1910官方SDK提供了Python API，风格比较接近ONNX Runtime，上手非常快。

我的第一个板端推理脚本就是这样：

import numpy as np import microduck as md # 初始化NPU运行环境 md.init(device_id=0) # 加载模型 model = md.load_model("yolov8n_int8.mk") # 构造输入数据(640x640 RGB) input_data = np.random.rand(1, 3, 640, 640).astype(np.float32) # 实际应用时，这里应读取真实图片并做预处理 # 推理 outputs = model.inference(input_data) # 输出形状打印 for i, out in enumerate(outputs): print(f"Output {i}: shape={out.shape}, dtype={out.dtype}")

首次跑通时憨憨地先用随机数据试了一遍，确认NPU初始化正常、模型加载成功、推理一次能出结果后，才接真实图片。这里我特别想强调一个心态：不要一上来就串摄像头，先把虚拟数据跑通，再换真实数据，最后接外设。分步验证永远是最靠谱的排障策略。

3. 硬件调试：从点亮到系统真正稳定运行

硬件调试是模型部署成功之后必须做扎实的一步。说句实话，模型转换搞半天，结果发现摄像头供电不够、画面全绿，那才是真让人崩溃的。所以硬件调试的意识得提到前面来。

3.1 调试工具与上电前的准备工作

如果打算久玩这块板子，下面这几样工具建议备齐：

• USB转TTL串口模块（FT232RL或CP2102均可，3.3V电平，用来进系统shell）
• 万用表（测供电电压是否正常，排查短路必备）
• 示波器（预算允许就买台入门款，比如DSO150或者二手台式机，排查I2C、PWM波形问题很有用）
• 一张烧录好固件的TF卡或者写好的eMMC烧录器（Microduck-HD1910支持SD卡启动也能写eMMC，开发期推荐从TF卡启动，改系统更方便）

上电之前先做静态检查。我拿到板子习惯先测三个点：5V供电入口的对地阻抗（避免短路）、核心电压1.0V或0.8V是否正常、RTC电池是否装好（影响系统时钟和某些加密固件启动）。看似繁琐，但能提前排除掉很多“上电就红屏”的物理问题。

一个很关键的上电顺序：先接好USB转串口线（注意共地），再给板子上电，串口终端立刻能看到启动日志。如果串口敲回车没有反应，检查一下串口连接是否插错：Microduck-HD1910的调试串口一般是与GPIO复用的，出厂的DTS（设备树）会默认配置为UART调试口，如果你改动过设备树，极有可能把调试串口给关了。

3.2 UART串口调试：第一道生命线

串口是嵌入式开发者的眼睛。Microduck-HD1910的调试串口参数固定为115200、8N1，连接好后把串口软件打开（我常用minicom或Windows下MobaXterm），重新上电就能看到uboot和kernel的启动日志。

我的习惯是看到以下日志才算板子真正活了：

U-Boot 2020.04 (Apr 08 2024 - 10:00:00 +0800) ... Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.10.120 ... [ 1.234567] mmc1: new high speed SD card at address 0xabcd [ 2.031234] EXT4-fs (mmcblk1p2): mounted filesystem with write support [ 2.990001] Freeing unused kernel memory: 4096K Welcome to MicroDuck Linux (Yocto 4.0)

如果卡在某个地方不动，回车出不了登录提示符，大概率是从根文件系统启动阶段出了问题，常见原因包括：TF卡分区表不对、根文件系统损坏、dtb设备树文件不匹配。

会看启动日志是一项核心技能，它能帮你把问题快速定位到uboot阶段、内核阶段还是用户态阶段，而不是瞎猜。

3.3 外设逐个调试：GPIO、CSI摄像头、PWM风扇

外设调试我建议按“一看二测三代码”的顺序来。

“一看”是指先看设备树里这个外设有没有被正确描述。HD1910的设备树在SDK源码的kernel/arch/arm64/boot/dts/目录下，比如摄像头节点一般叫ov5645或者gc2053，你得确认对应的节点在dts里是status = "okay"而不是"disabled"。

“二测”是指用硬件工具测量关键信号。CSI摄像头如果上电后I2C读不到ID，就用示波器量MIPI-CSI供电引脚和MIPI时钟引脚，确认供电1.2V正常、MIPI时钟有输出。GPIO调试就更直接了，万用表测引脚电平，写一个简单内核模块或者用/sys/class/gpio操作，置高置低看实际电压变化。

“三代码”是指用板端跑一个小程序做功能验证。等外设信号正常后，写一个读取摄像头画面的测试程序，输出一张jpeg图下来看看画面颜色、曝光是否正确。

我在调试CSI摄像头时遇到过一个大坑：上电后摄像头能出画面，但颜色呈现整体偏绿，像加了滤镜。排查了很长时间，最后发现是ISP初始化时白平衡关键参数没设置，切到自动白平衡，画面立刻正常。这个问题的隐蔽性很高，因为在PC上跑USB摄像头你基本不会碰到这种底层配置问题。

3.4 电源和信号完整性问题：被低估的隐形杀手

很多“诡异”问题，最后追根溯源都是供电问题。HD1910的外设接口大多提供3.3V电源，但一些功耗较大的外设（比如4G模块、大功率补光灯、舵机）如果直接从板子取电，轻则电压跌落，重则烧坏主控。

我的经验法则是：凡是工作电流超过500mA的外设，一律外部独立供电，只和板子共地。尤其是给摄像头红外补光灯板供电时，共地不做好，画面会出现周期性条纹噪点，看起来像算法问题，其实是地环路干扰。

另外，如果是用劣质USB充电器给板子供电，负载波动时电压纹波大，轻则NPU推理莫名崩溃，重则TF卡文件系统损坏。我给板子配的电源是12V/2A的工业电源适配器，稳压效果明显好于手机充电头。做好电源这一环，系统稳定性会大幅度提升。

4. 软件开发：交叉编译、推理服务与业务封装

硬件基础打牢、模型也能在板端推理了，接下来就是“把三者串成一个产品”的软件开发环节。这块是内容最杂、工作量最大的一部分，也是很多人最陌生的一块。

4.1 交叉编译环境与板端依赖管理

Microduck-HD1910的SoC是ARM架构，板子上装的是Yocto Linux。这意味着大多数PC上的软件包不能直接丢上去，得用交叉编译工具链重新编译。官方SDK里自带了一个交叉编译器，通常叫aarch64-microduck-linux-gnu-gcc，对应的sysroot在SDK/sysroots/aarch64-microduck-linux目录下。

我推荐在开发机上建一个专门的CMake工具链文件，这样每次编译就会非常顺畅：

set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CROSS_COMPILE aarch64-microduck-linux-gnu-) set(CMAKE_C_COMPILER ${CROSS_COMPILE}gcc) set(CMAKE_CXX_COMPILER ${CROSS_COMPILE}g++) set(CMAKE_SYSROOT $ENV{SDK_PATH}/sysroots/aarch64-microduck-linux) set(CMAKE_FIND_ROOT_PATH ${CMAKE_SYSROOT}) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

至于依赖管理，Yocto系统没有apt，板端装软件的方式有三种：直接把编译好的二进制和动态库scp进去；用官方提供的opkg包管理（源里面包不多）；或者打包成静态编译的二进制。我的习惯是静态编译关键业务程序，动态库依赖能少则少，这样固件升级时我只要替换几个文件，不至于被动态库版本问题卡住。

4.2 板端子系统的模块化设计思路

因为这是一个嵌入式Linux系统，我会把产品软件拆成三个进程来管，而不是一个死循环的大杂烩：采集进程、推理进程、业务控制进程。

采集进程负责从摄像头拉流，把画面转成NPU推理需要的输入格式；推理进程负责加载NPU模型并执行推理，同时做后处理解析；业务控制进程收到推理结果后，根据业务逻辑决定是否抓拍、报警、上报，以及控制GPIO。三个模块间用共享内存和命名管道通信，这样任何一个模块出问题都可以独立重启，不会把整个系统带崩。

这种设计的好处是容错度很好。我用Supervisor来守护这三个进程，异常退出自动拉起来，大大提高了系统的长时间运行稳定性。

4.3 摄像头采集与推理主循环实战

采集方案我推荐用V4L2 API直接操作摄像头设备，避免依赖额外的图像库，中间环节越少越稳。核心步骤是：打开设备 -> 设置分辨率和像素格式 -> 申请帧缓冲 -> 启动采集 -> 循环取帧和投回缓冲。

设置参数时注意，HD1910的ISP最大输入分辨率一般是2688x1520，但如果我要跑640x640的模型，应该让摄像头直接输出640x640吗？答案是不建议。摄像头传感器有一个最佳工作分辨率（比如1920x1080），你强行切小分辨率可能导致视野变窄、噪点变大。更合理的做法是摄像头出1920x1080，然后做缩放裁剪（letterbox）到640x640。

推理主循环的结构其实非常简单，和PC端差不多：

while True: frame = camera.read() # 取一帧 input_tensor = preprocess(frame) # letterbox + 归一化 outputs = model.inference(input_tensor) # NPU推理 boxes = postprocess(outputs) # 解码 + NMS if len(boxes) > 0: handle_result(frame, boxes) # 业务逻辑 draw_overlay(frame, boxes) # 画框(可选) camera.show(frame)

这里最容易出问题的是预处理细节必须和训练时保持一致。用YOLO时，letterbox的填充灰度值是114，归一化要除以255，RGB通道顺序不能反。我一再强调这点，是因为见过太多人在板子上推理结果错得离谱，最后发现只是预处理顺序反了。模型部署是“差之毫厘，谬以千里”的典型领域。

4.4 结果输出与外部系统对接：MQTT、HTTP与GPIO联动

推理结果出来了，怎么送出去？这是业务软件的核心价值。我实测下来，按需求场景推荐三种方式：

第一种，接入物联网平台，用MQTT协议上报。轻量、稳定、断线重连机制成熟。Yocto里没有现成的mosquitto客户端库，我交叉编译了Eclipse Paho MQTT C客户端接到项目里。上报格式用JSON，消息体大概是{"device_id":"HD1910-001","timestamp":"2025-03-01T12:00:00Z","detections":[{"class":"person","conf":0.87,"bbox":[120,200,240,480]}]}。后续后端做数据分析非常轻松。

第二种，上报到自研的HTTP服务。适合已有后端系统的场景。用curl命令行显然不够优雅，我在板子里集成了一个轻量的HTTP客户端库（libcurl交叉编译带上ssl支持），关键帧截图通过HTTP POST multipart上传。

第三种，本地联动响应。检测到目标就控制GPIO拉高推杆或者点亮报警灯。GPIO操作通过Linux标准的gpiod接口来做，注意绕过内核里已被占用的端口，操作前先用gpioinfo命令看清楚每个IO当前是输入还是输出。

实际项目中，三个方案往往是组合的：本地GPIO快速响应 + MQTT上报远程平台 + HTTP抓拍截图留存，一个需求完整同时照顾了三方消费方。

4.5 日志、看门狗与性能优化要点

嵌入式软件开发和高并发后台开发不一样，它更接近“一个人管一整条链”。所以日志设计要清晰，性能调优要靠数据，运行稳健要靠看门狗。

日志我强烈推荐结构化JSON格式，方便后续平台采集分析。每条日志清晰打点：时间、模块名、级别、事件、耗时。排查问题时就能按模块过滤，不会在瞎print里迷路。一个MP4从日志里定位到“摄像头偶发断流”花了我半天时间，换了结构化日志后，这种问题的定位时间缩短到了十几分钟。

性能优化要先用数据说话。我用板端的perf stat统计主循环各部分耗时，刚跑通的YOLOv8n全流程是68毫秒，拆解如下：

• 摄像头取帧：5毫秒
• 缩放预处理（1080p -> 640x640）：8毫秒
• NPU推理：45毫秒
• 后处理NMS：7毫秒
• 业务逻辑+开销：3毫秒

NPU推理占大头，这没得优化；最值得抠的是预处理，8毫秒是因为初始版本用了低效的双线性插值循环。我这里换成了用neonintrinsics写了一个高度优化的缩放函数，耗时降到2.5毫秒，整体提速到了62毫秒。如果你对ARM优化感兴趣，这是个非常好的学习方向。

5. 常见问题与排查技巧实录

开发这一个月，我把踩过的问题整理成了一份速查表，每个问题都带排查思路和解决路径。这些内容常规教程不讲，但开发时九成都会遇到。

再补充几个排查时的老经验。查问题先看日志，日志比什么都靠谱。无论是内核日志dmesg还是应用日志，先看它们，不要上来就瞎改代码，那样可能让问题更隐蔽。改完代码记得回归测试。嵌入式改了摄像头配置，经常会连带影响ISP色彩效果，那就要把整个采集推理流程重新跑一遍。备份现场。板子开发阶段环境说崩就崩，我每完成一个功能点就给TF卡做个镜像备份，整个开发周期备份了6次，每次恢复只要几分钟，比重新配环境快太多。

6. 整机联调与压测：跑一个通宵看看稳定性

单模块跑通不算完，边缘设备是要7x24小时在户外或者产线上干活的，稳定性必须靠压测验证。

我建议整机联调按这个顺序来：先冷启动、后反复重启、再长时间带载运行。具体做法是写一个压测脚本，统计每一帧推理的结果和耗时，连续跑12小时以上，记录系统是否发生崩溃、内存是否泄漏、NPU温度是否长时间超过80度。这个数据会直接告诉你整个系统能不能扛住真实工况。

在HD1910上我压测12小时，最终数据是这样：总推理次数约64000次，平均推理耗时47毫秒，最大内存占用868MB（4GB内存绰绰有余），NPU温度最高72度，没出现一次崩溃或死机。对一块被动散热的板子来说，这个数据已达到可交付状态。

压测容易暴露出来的问题主要有三类：内存泄漏、日志文件无限膨胀、看门狗误触发。内存泄漏可以用valgrind在板端分析，或者简单点写个脚本监控/proc/meminfo的趋势；日志膨胀就加日志轮转logrotate；看门狗误触发就检查喂狗线程有没有被长推理卡住，必要时把喂狗挪到独立线程。

整机稳定跑过后，这块板子才算是从“能玩”升级到“能用”。你再拿它做出来的东西，是产品原型，不只是玩具。

7. 最后的经验之谈

在Microduck-HD1910上完整走完模型部署、硬件调试、软件开发一整套流程后，我最大的体会是：边缘AI项目的难度不在于某一个环节有多深，而在于每个环节你都绕不过去。纯搞算法的人会卡在交叉编译和看门狗上，纯搞嵌入式的会卡在模型量化和算子兼容上。只有把三块知识拼成一张完整图景，项目才跑得起来。

还有一件事我想多说一句：别闭门造车，善用工具链自身的生态。Microduck-HD1910官方SDK里其实带了一些示例代码，包括摄像头采集、NPU推理、GPIO控制，很多人不看文档就自己硬写，结果绕了远路还更容易出问题。先跑通官方示例再改，效率翻倍。

如果你正准备上手这块板子，按这篇教程的顺序来，先稳定再功能，先简单模型再复杂业务，遇到问题回到第五节的速查表里找思路。技术这条路没什么捷径，但把前人的坑提前填好，你走起来会快很多。祝顺利。