好暖好温暖的博客

多元函数求极值 | 使用Hessian矩阵

Tue, 09 Jun 2026 00:00:00 GMT

一、题目

$$ f(x,y)=x^4+y^4-(x+y)^2 $$

已知 $(1,1)$ 与 $(-1,-1)$ 是两个驻点，判断它们处函数值是极大还是极小。

二、多元函数极值的一般步骤

对于二元函数 $f(x,y)$，求极值通常分三步：

第一步：求一阶偏导，找驻点

驻点满足：

$$ f'_x=0,\qquad f'_y=0 $$

也就是梯度为零：

$$ \nabla f=(f'_x,f'_y)=(0,0) $$

第二步：求二阶偏导，构造 Hessian 矩阵

二元函数的 Hessian 矩阵为：

$$ H= \begin{pmatrix} f'{xx} & f'{xy}\ f'{yx} & f'{yy} \end{pmatrix} $$

第三步：用二阶判别法判断极值

记

$$ A=f'{xx},\quad B=f'{xy},\quad C=f'_{yy} $$

计算

$$ D=AC-B^2 $$

判断规则如下：

条件	结论
$D>0,\ A>0$	极小值
$D>0,\ A<0$	极大值
$D<0$	鞍点
$D=0$	二阶判别法失效，需要其他方法

三、记忆口诀

二元函数极值判断可以记成：

$$ D=f_{xx}f_{yy}-f_{xy}^2 $$

$D>0,\ f_{xx}>0$：极小值；
$D>0,\ f_{xx}<0$：极大值；
$D<0$：鞍点；
$D=0$：无法判断。

openipc固件编译和烧录

Thu, 28 May 2026 00:00:00 GMT

编译环境需要Ubuntu20.04、Ubuntu22.04或者Debian12，如果不是对应系统的话，可以用docker，参考这个项目：

::gitHub{repo="haoyn231/rk35xx_build_env"}

1. 获取官方SDK

https://github.com/OpenIPC/firmware

2. 编译SSC338Q的openipc固件

# 安装依赖
make deps

# 生成配置文件
make BOARD=ssc338q_lite defconfig

# 编译buildroot linux
make BOARD=ssc338q_lite br-linux

# 全编译，生成固件
make BOARD=ssc338q_lite all

最终生成的固件在 output/images

builder@archlinux:/workspace/firmware$ ls output/images/
openipc.ssc338q-nor-lite.tgz  rootfs.cpio  rootfs.squashfs.ssc338q  rootfs.ssc338q.tar  uImage.ssc338q

3. 烧录固件

对于openipc设备，如果设备能正常启动，那么烧录固件最方便的方式是把固件传输到设备文件系统里，然后用系统自带的工具进行升级。当前设备虽然有以太网卡，但是只有接口，需要外接。所以这里采取用SD卡来传输固件到设备上。查看flash分区表：

root@openipc-ssc338q:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "boot"
mtd1: 00010000 00010000 "env"
mtd2: 00200000 00010000 "kernel"
mtd3: 00800000 00010000 "rootfs"
mtd4: 005b0000 00010000 "rootfs_data"

需要准备一个FAT格式的SD卡

备份旧镜像

备份到SD卡中

# 先创建一个文件夹
mkdir -p /mnt/mmcblk0p1/bak/
dd if=/dev/mtd0 of=/mnt/mmcblk0p1/bak/mtd0_boot.bin
dd if=/dev/mtd1 of=/mnt/mmcblk0p1/bak/mtd1_env.bin
dd if=/dev/mtd2 of=/mnt/mmcblk0p1/bak/mtd2_kernel.bin
dd if=/dev/mtd3 of=/mnt/mmcblk0p1/bak/mtd3_rootfs.bin
dd if=/dev/mtd4 of=/mnt/mmcblk0p1/bak/mtd4_rootfs_data.bin

使用系统自带的 sysupgrade 来烧录固件

cp /mnt/mmcblk0p1/images/openipc.ssc338q-nor-lite.tgz /tmp/
sync

sysupgrade \
  --archive=/tmp/openipc.ssc338q-nor-lite.tgz
  
# 全量更新，包括kernel和rootfs  
sysupgrade --force_ver --wipe_overlay --archive=/tmp/openipc.ssc338q-nor-lite.tgz

使用Vivado进行ZYNQ的PL端开发基础流程

Mon, 18 May 2026 00:00:00 GMT

从创建工程到烧录比特流文件到芯片里，最终固化到非易失性存储器里。这里的比特流文件可以理解为最终生成的结果，类似于编译出的二进制文件。

在写好verilog文件，到生成比特流文件，中间还有很多步骤，包括：

RTL描述与分析
创建激励与仿真测试
设计综合
添加设计约束
设计实现（布局布线）

完成后才能生成比特流文件。整个流程对应Vivado界面左侧的Flow Navigator。

一、示例程序：LED灯闪烁

module led_flash(
    input clk,
    input rst_n,
    output reg led
    );
    reg [25:0] cnt;
    always @ (posedge clk or negedge rst_n)
    begin
        if (!rst_n)
            cnt <=26'd0;
        else if (cnt < 26'd49_999_999)
            cnt <= cnt + 1'b1;
        else
            cnt <= 26'd0;
    end

    always @ (posedge clk or negedge rst_n)
    begin
        if (!rst_n)
            led <= 1'b0;
        else if (cnt == 26'd49_999_999)
            led <= ~led;
        else
            led <= led;
    end
    
endmodule

创建了一个LED灯闪烁的模块，包括时钟线（高电平触发 posedge）、复位信号（低电平触发 negedge）、输出的LED信号和一个26位的计数寄存器。

两个always控制块，一个用作计数器，另一个用于控制LED。

二、RTL描述与分析

对当前HDL工程进行一次检查，检查是否有语法错误，但是无法检查是否有逻辑错误。同时把HDL展开为真正的逻辑结构。

RTL Analysis就是指对理解当前的HDL工程到底是在干什么，它可以生成一个概括性的原理图，但不是真正的电路，只是一个示意图（RTL级抽象电路），我们可以通过查看这个示意图来确定自己编写的Verilog是否符合要求。

如下是示例工程中的led_flash对应的原理图：

可以看到其中的时钟信号、复位信号、LED信号、逻辑门和触发器等等。

三、激励创建与仿真

对于大型的HDL工程，在实际综合前需要创建一个激励，对它进行仿真测试，来查看是否符合预期。它虽然是HDL开发的必要流程，但不是强制性的，对于简单的工程也可以不进行仿真测试，本文暂时略过。

四、设计综合

设计综合 Synthesis 就是将我们的HDL工程转化为门级网表

可以得到工程对应的利用FPGA器件所具有的基本元件LUT搭建的电路图

可以查看不同的LUT对应的逻辑表达式和真值表映射

通过Report Utilization，可以查看逻辑资源的使用情况

五、添加设计约束

在之前的操作里，完成了HDL电路设计、RTL分析和综合，最终生成了FPGA里真实的电路结构，但是它们还只是在FPGA内部，无法与外部交互，不知道时钟信号和复位信号从哪儿来，不知道LED信号对应哪个真实引脚。因此需要进行约束，其中引脚约束就是给信号绑定真实的IO，让它操作真实的引脚的电平，进行输入输出。

在综合后的界面里，点击layout里的IO Planning，打开引脚分配界面，给信号分配真实的引脚

保存后就可以生成约束文件XDC

六、设计实现（布局布线）

在综合得到真实电路图和添加约束后，就可以通过电路图和约束文件在FPGA里实现这个设计，即把之前的设计实现在FPGA器件里。

完成设计后，可以在Device中看到FPGA中生成的电路，也可以看到连接关系

七、生成比特流文件

实现设计后就可以生成比特流文件

Generate Bitstream即可

八、烧录与固化

通过Flow打开Hardware Manager，连接设备，烧录比特流即可

对于程序固化来说，如果是纯FPGA芯片，可以通过Vivado之间把bin烧录到开发板的Flash中，但是对于ZYNQ，PL端没有引出非易失性存储器的控制引脚，需要使用SDK通过PS端来完成程序固化，暂时不做展开。

QEMU学习（一）启动buildroot的virt板

Thu, 30 Apr 2026 00:00:00 GMT

Virt板是QEMU官方提供的一个专门模拟ARM/RISC-V指令集的通用设备，Buildroot里维护了很多QEMU Virt的配置，可以直接编译并启动：

https://github.com/buildroot/buildroot/tree/master/configs

走一遍流程，用QEMU启动qemu_aarch64_virt_defconfig

一、获取源码并编译

git clone https://github.com/buildroot/buildroot.git

cd buildroot

# 生成对应的.config文件
make qemu_aarch64_virt_defconfig

# 编译生成kernel和rootfs
make -j$(nproc)

使用buildroot的默认配置，它会自动下载或构建交叉编译工具链，下载linux kernel源码并编译

编译后的结果在output/images中

❯ ls
Image  rootfs.ext2  rootfs.ext4  start-qemu.sh

二、用QEMU启动Linux系统

buildroot在编译后会提供一个直接启动QEMU的脚本，其中具体操作QEMU的部分是：

qemu-system-aarch64 \
  -M virt \
  -cpu cortex-a53 \
  -nographic \
  -smp 1 \
  -kernel Image \
  -append "rootwait root=/dev/vda console=ttyAMA0" \
  -netdev user,id=eth0 \
  -device virtio-net-device,netdev=eth0 \
  -drive file=rootfs.ext4,if=none,format=raw,id=hd0 \
  -device virtio-blk-device,drive=hd0

模拟cortex-a53的QEMU官方提供的ARM通用虚拟开发板，单核CPU, 无图形化界面，kernel的Image就在脚本所在目录。

其中值得注意的是：

传递内核参数

-append "rootwait root=/dev/vda console=ttyAMA0"

创建网络与添加虚拟网卡

利用了宿主机的虚拟磁盘来承载rootfs.ext4，然后挂载这个虚拟磁盘/dev/vda来作为rootfs，rootwait表示等待虚拟磁盘出现后再启动

rootfs.ext4 (宿主机文件)
↓
QEMU 当成虚拟硬盘
↓
虚拟硬盘通过 VirtIO 暴露给 guest Linux
↓
Linux 识别成 /dev/vda
↓
内核根据 root=/dev/vda 挂载为 /

三、启动过程

❯ ./start-qemu.sh
Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Linux version 6.18.7 (hao@archlinux) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 2026.02-701-ga9942e8793) 14.3.0, GNU ld (GNU Binutils) 2.45.1) #1 SMP Thu Apr 30 16:33:49 CST 2026
random: crng init done
Machine model: linux,dummy-virt
efi: UEFI not found.
OF: reserved mem: Reserved memory: No reserved-memory node in the DT
Zone ranges:
  DMA      [mem 0x0000000040000000-0x0000000047ffffff]
  DMA32    empty
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000040000000-0x0000000047ffffff]
Initmem setup node 0 [mem 0x0000000040000000-0x0000000047ffffff]
psci: probing for conduit method from DT.
psci: PSCIv1.1 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
psci: Trusted OS migration not required
psci: SMC Calling Convention v1.0
percpu: Embedded 20 pages/cpu s43864 r8192 d29864 u81920
Detected VIPT I-cache on CPU0
CPU features: detected: ARM erratum 845719
alternatives: applying boot alternatives
Kernel command line: rootwait root=/dev/vda console=ttyAMA0
printk: log buffer data + meta data: 131072 + 458752 = 589824 bytes
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
software IO TLB: SWIOTLB bounce buffer size adjusted to 0MB
software IO TLB: area num 1.
software IO TLB: mapped [mem 0x0000000047f1e000-0x0000000047f5e000] (0MB)
Built 1 zonelists, mobility grouping on.  Total pages: 32768
mem auto-init: stack:all(zero), heap alloc:off, heap free:off
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
rcu: Hierarchical RCU implementation.
rcu:    RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=1.
rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
Root IRQ handler: gic_handle_irq
GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
rcu: srcu_init: Setting srcu_struct sizes based on contention.
arch_timer: cp15 timer running at 62.50MHz (virt).
clocksource: arch_sys_counter: mask: 0x1ffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
sched_clock: 57 bits at 63MHz, resolution 16ns, wraps every 4398046511096ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
cacheinfo: Unable to detect cache hierarchy for CPU 0
rcu: Hierarchical SRCU implementation.
rcu:    Max phase no-delay instances is 1000.
EFI services will not be available.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 1 CPU
SMP: Total of 1 processors activated.
CPU: All CPU(s) started at EL1
CPU features: detected: 32-bit EL0 Support
CPU features: detected: CRC32 instructions
CPU features: detected: PMUv3
alternatives: applying system-wide alternatives
Memory: 112176K/131072K available (8640K kernel code, 894K rwdata, 2100K rodata, 1152K init, 510K bss, 17476K reserved, 0K cma-reserved)
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
posixtimers hash table entries: 512 (order: 1, 8192 bytes, linear)
futex hash table entries: 256 (16384 bytes on 1 NUMA nodes, total 16 KiB, linear).
29392 pages in range for non-PLT usage
520912 pages in range for PLT usage
DMI not present or invalid.
NET: Registered PF_NETLINK/PF_ROUTE protocol family
DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
thermal_sys: Registered thermal governor 'step_wise'
cpuidle: using governor menu
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
ASID allocator initialised with 65536 entries
Serial: AMBA PL011 UART driver
9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 13, base_baud = 0) is a PL011 rev1
printk: console [ttyAMA0] enabled
ACPI: Interpreter disabled.
iommu: Default domain type: Translated
iommu: DMA domain TLB invalidation policy: strict mode
SCSI subsystem initialized
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
vgaarb: loaded
clocksource: Switched to clocksource arch_sys_counter
pnp: PnP ACPI: disabled
NET: Registered PF_INET protocol family
IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
tcp_listen_portaddr_hash hash table entries: 256 (order: 0, 4096 bytes, linear)
Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
TCP established hash table entries: 1024 (order: 1, 8192 bytes, linear)
TCP bind hash table entries: 1024 (order: 3, 32768 bytes, linear)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 2, 16384 bytes, linear)
UDP-Lite hash table entries: 256 (order: 2, 16384 bytes, linear)
NET: Registered PF_UNIX/PF_LOCAL protocol family
PCI: CLS 0 bytes, default 64
workingset: timestamp_bits=46 max_order=15 bucket_order=0
fuse: init (API version 7.45)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
io scheduler mq-deadline registered
io scheduler kyber registered
pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000
pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000
pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000
pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits
pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff]
pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff]
pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000 conventional PCI endpoint
pci_bus 0000:00: resource 4 [io  0x0000-0xffff]
pci_bus 0000:00: resource 5 [mem 0x10000000-0x3efeffff]
pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff]
virtio_blk virtio0: 1/0/0 default/read/poll queues
virtio_blk virtio0: [vda] 122880 512-byte logical blocks (62.9 MB/60.0 MiB)
rtc-pl031 9010000.pl031: registered as rtc0
rtc-pl031 9010000.pl031: setting system clock to 2026-04-30T08:36:05 UTC (1777538165)
hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 (0,8000003f) counters available
NET: Registered PF_INET6 protocol family
Segment Routing with IPv6
In-situ OAM (IOAM) with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered PF_PACKET protocol family
NET: Registered PF_KEY protocol family
NET: Registered PF_VSOCK protocol family
registered taskstats version 1
clk: Disabling unused clocks
PM: genpd: Disabling unused power domains
check access for rdinit=/init failed: -2, ignoring
EXT4-fs (vda): orphan cleanup on readonly fs
EXT4-fs (vda): mounted filesystem c394bba6-5965-4a70-a0a4-17e04562b2fb ro with ordered data mode. Quota mode: disabled.
VFS: Mounted root (ext4 filesystem) readonly on device 254:0.
devtmpfs: mounted
Freeing unused kernel memory: 1152K
Run /sbin/init as init process
EXT4-fs (vda): re-mounted c394bba6-5965-4a70-a0a4-17e04562b2fb r/w.
Saving 256 bits of creditable seed for next boot
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Starting network: udhcpc: started, v1.37.0
udhcpc: broadcasting discover
udhcpc: broadcasting select for 10.0.2.15, server 10.0.2.2
udhcpc: lease of 10.0.2.15 obtained from 10.0.2.2, lease time 86400
deleting routers
adding dns 10.0.2.3
OK
Starting crond: OK

Welcome to Buildroot
buildroot login: root
# ls
# pwd
/root
# ls /
bin           lib           media         root          tmp
crond.reboot  lib64         mnt           run           usr
dev           linuxrc       opt           sbin          var
etc           lost+found    proc          sys

退出QEMU：先按ctrl + a,再按x

RKNN 部署与不同 SOC 性能分析

Thu, 26 Feb 2026 00:00:00 GMT

一、概述

记录 RKNN 的部署流程，测试 YOLOv5 模型在不同硬件平台上的性能表现，分析适用场景。

需要三个仓库：

yolov5

一个极其流行的单阶段目标检测算法实现库。它是模型的来源。在这里获取原始的权重文件（.pt），并利用其中的 export.py 脚本，配合 --rknpu 参数，导出一个专门为瑞芯微 NPU 结构优化过的中间格式（.onnx）。
rknn-toolkit2

瑞芯微为旗下 NPU 芯片提供的软件开发套件（SDK）。它是转换的核心工具。它提供 C 或 Python 接口，负责把 .onnx 模型转换成板子能跑的 .rknn 格式。此外，它还承担了模型量化（将浮点数转为 int8）和精度评估的重要任务。
rknn_model_zoo

瑞芯微官方提供的各种主流算法（如 YOLO、MobileNet 等）的部署示例集合。测试工程模板。它提供了经过优化的 C++ 源码（如 rknn_yolov5_demo）和交叉编译脚本。最终在板子上运行的那个“测速程序”，就是从这个仓库里编译出来的。

两个python虚拟环境

yolov5 环境

安装了原生 PyTorch 和 YOLOv5 所需的高版本依赖。负责模型导出。在这个环境下，运行 python export.py，把 .pt 变成 .onnx。一旦拿到 .onnx，这个环境的任务就完成了。
RKNN-toolkit2 环境

安装了特定版本的 onnx和瑞芯微私有的 rknn-toolkit2 软件包。负责模型量化与转换。在这个环境下，运行转换脚本，把上一步得到的 .onnx 喂进去，经过 int8 量化，最后得到出 .rknn 文件。

二、环境搭建

克隆上述三个仓库到~/projects/rknn/

RKNN-toolkit2 环境搭建

conda create -n RKNN-Toolkit2 python=3.9
conda activate RKNN-Toolkit2

# 克隆工具链
git clone https://github.com/airockchip/rknn-toolkit2.git
cd rknn-toolkit2

# 安装依赖（注意根据 Python 版本选择对应的 requirements 文件）
pip install -r rknn-toolkit2/packages/x86_64/requirements_cp39-2.3.2.txt -i https://pypi.tuna.tsinghua.edu.cn/simple/

# 安装 RKNN-Toolkit2 软件包
pip install rknn-toolkit2/packages/x86_64/rknn_toolkit2-2.3.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

Yolov5 环境搭建

# 克隆仓库
git clone https://github.com/airockchip/yolov5.git

cd yolov5

# 创建虚拟环境
conda create -n yolov5 python=3.9
# 进入虚拟环境并安装依赖库
conda activate yolov5
pip install -r requirements.txt

三、转换模型：ONNX to RKNN

获取导出 ONNX 文件

（yolov5 conda 环境下）

cd yolov5
python export.py --rknpu --weight yolov5s.pt

得到 yolov5s.pt、yolov5s.onnx和RK_anchors.txt

获取 RKNN 文件

（在RKNN-toolkit2 conda 环境下）

cd rknn_model_zoo/examples/yolov5/python

# 指定 onnx 模型的位置和 target（rv1106）
python3 convert.py ~/projects/rknn/yolov5/yolov5s.onnx rv1106

转换为RKNN文件examples/yolov5/model/yolov5.rknn

四、编译测试程序

在 ~/projects/rknn/rknn_model_zoo/examples/yolov5/cpp

# 导入编译工具链路径
export GCC_COMPILER=/home/hao/projects/luckfox-pico/tools/linux/toolchain/arm-rockchip830-linux-uclibcgnueabihf/bin/arm-rockchip830-linux-uclibcgnueabihf

./build-linux.sh -t rv1106 -a armv7l -d yolov5

编译并完成安装，将rknn_model_zoo/install/rv1106_linux_armv7l/rknn_yolov5_demo通过 scp 协议传输到开发板上，执行程序

./rknn_yolov5_demo model/yolov5.rknn model/bus.jpg

（原版代码只会执行一次，修改了demo的源码，让它连续执行10次并获取精确的 NPU 推理时常，计算结果后打印出来，修改后的源码在 https://github.com/haoyn231/rknn_model_zoo/tree/yolov5_benchmark/examples/yolov5/cpp）

运行结果：

[root@luckfox rknn_yolov5_demo]# ./rknn_yolov5_demo model/yolov5.rknn model/bus.jpg
load lable ./model/coco_80_labels_list.txt
model input num: 1, output num: 3
input tensors:
  index=0, name=images, n_dims=4, dims=[1, 640, 640, 3], n_elems=1228800, size=1228800, fmt=NHWC, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922
output tensors:
  index=0, name=output0, n_dims=4, dims=[1, 255, 80, 80], n_elems=1632000, size=1632000, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922
  index=1, name=367, n_dims=4, dims=[1, 255, 40, 40], n_elems=408000, size=408000, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922
  index=2, name=369, n_dims=4, dims=[1, 255, 20, 20], n_elems=102000, size=102000, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922
input_attrs[0].size_with_stride=1228800
model is NHWC input fmt
model input height=640, width=640, channel=3
origin size=640x640 crop size=640x640
input image: 640 x 640, subsampling: 4:2:0, colorspace: YCbCr, orientation: 1
scale=1.000000 dst_box=(0 0 639 639) allow_slight_change=1 _left_offset=0 _top_offset=0 padding_w=0 padding_h=0
rga_api version 1.10.1_[0]
rknn_run
========================================
NPU Inference time:
First run time: 85.209 ms
Average time of 10 runs: 86.624 ms
Estimated FPS: 11.54
========================================
person @ (209 242 283 516) 0.828
person @ (474 230 561 522) 0.798
person @ (114 235 207 543) 0.796
bus @ (93 133 549 462) 0.787
person @ (78 330 122 519) 0.408
write_image path: out.png width=640 height=640 channel=3 data=0xa5a31000

推理结果：

五、结果分析

瑞芯微主流 SoC NPU 性能实测数据汇总表

除了 RV1106G3 的数据为本文章实测外，其他数据由触觉智能的文章提供。

测试条件：YOLOv5s-640-640 模型，INT8 量化，640*640 分辨率测试图片。

芯片型号	核心硬件参数	首次运行耗时 (ms)	连续10次平均耗时 (ms)	帧率估算 (FPS)
RV1106G3	单核 A7 + 1.0 TOPS NPU	85.209	86.624	11.54
RK3562	四核 A53 + 1.0 TOPS NPU	66.165	51.885	19.3
RV1126B	四核 A53 + 3.0 TOPS NPU	26.897	26.0425	38.4
RK3576	4核A72 + 4核A53 + 6.0 TOPS NPU	55.395	23.7342	42.1
RK3588	4核A76 + 4核A55 + 6.0 TOPS NPU	30.887	21.2581	47.0

实验结果分析与硬件适配性评估

通过对瑞芯微（Rockchip）系列 SoC 的推理性能实测发现，其 NPU 推理效率遵循 RK3588 > RK3576 > RV1126B > RK3562 > RV1106G3 的梯度分布，其中具备 6 TOPS 算力的 RK3588 与 RK3576 以超过 40 FPS 的表现领跑高实时性场景；作为对比，主打超低功耗与成本优势的 RV1106G3（单核 A7 + 1.0 TOPS NPU）在处理 640*640 大分辨率模型时实现了 11.54 FPS 的实测帧率，且展现出极佳的时延确定性，其首次运行与平均耗时波动显著低于多核架构芯片，使其在智能门铃、低功耗 IPC 等对响应稳定性要求较高、且成本敏感的垂直场景中，展现出比四核 A53 架构的 RK3562 更为突出的性价比优势。

参考链接

https://mp.weixin.qq.com/s/8cPELPb-4YGDo0fZ_o--Aw
https://wiki.luckfox.com/zh/Luckfox-Pico-Ultra/RKNN

视频文案：一个视频讲清楚嵌入式Linux交叉编译

Thu, 19 Feb 2026 00:00:00 GMT

（上面视频的文案）

大家新年好！最近突发奇想，决定写一篇关于嵌入式 Linux 交叉编译的内容。

之所以想聊这个，是因为我发现很多刚入门的同学经常在群里问：编译出来的文件怎么烧录到开发板？动态库链接怎么老是报错？今天就把我这些年的经验总结分享给大家，希望能帮大家避坑。

1. 搞清楚谁是 Host，谁是 Target

在聊编译之前，需要先弄明白两个最基本的概念：Host（主机） 和 Target（目标机） 。

Host（编译平台）：指你干活的机器。比如学单片机时，Host 通常是 X86 架构的 Windows；而在嵌入式 Linux 开发中，我们的 Host 一般是 X86 架构的 Linux 系统。
Target（运行平台）：指程序最终运行的地方。
- STM32：属于 ARM Cortex-M 架构（32 位 ARM）。
- 泰山派 (RK3566)：四核 Cortex-A55，属于 ARM64 或 aarch64 架构。
- ESP32：有 Xtensa 架构，也有 RISC-V 架构。

所以，找编译链的时候，不能只看 Target，还得看 Host 能不能运行这个工具链。

2. Target 还要区分 ABI：Bare Metal 和 Linux

打开 ARM 官网的工具链下载页面，你会发现种类繁多。这里有两个关键点：

操作系统区别

裸机 (Bare Metal)：比如编译 STM32 或运行 RTOS 的程序，要选 arm-none-eabi 。EABI 指的是嵌入式应用二进制接口。
Linux 目标机：编译像 RK3566 这种跑 Linux 的设备，要选 aarch64-linux-gnu 。

硬件浮点 (Hard Float)

对于 ARMv7 架构（比如三核 A7 的 RK3506），还要注意有没有硬件浮点支持 。

gnueabihf：表示支持硬件浮点（Hard Float）。
gnueabi：则没有这个后缀（软件浮点）。

（注：ARMv8/AArch64 之后默认都实现了硬件浮点，所以通常不再专门区分）。

3. Linux的核心动态库：Libc 库

在 Linux 上运行的几乎所有用户态程序，都会动态链接 Libc（C 库） 。它是对系统调用的封装，是你程序和内核沟通的桥梁。

Glibc：GNU Linux 上的标准实现。
Musl：一种更轻量、非常适合静态链接的实现。如果你追求程序的兼容性，不想管目标设备上的 Libc 版本是多少，用 Musl 把 C 库直接静态编译进程序里是个好选择。

注意：做单片机开发的同学可能没这个概念，因为单片机程序是全静态编译后直接烧录闪存的，没有操作系统的动态链接概念。

4. 交叉编译动态链接：Sysroot

这是最让新人头疼的地方。你的程序不只链接 C 库，还可能链接音频库（如 ALSA）、视频编解码库等。这些库都在开发板上（/usr/lib 目录下），你的主机（Host）里没有，编译时去哪里找？

这时候就需要 Sysroot 。

Sysroot 的作用：它相当于在你的主机上“伪造”了一个目标机的根目录。它同步了目标机的 /lib、/usr/include、/usr/lib 等目录。

如何获取 Sysroot？

Buildroot 方案：如果你用 Buildroot SDK，它编译完后会在 output/target 下生成一个备份，这就是现成的 Sysroot 。

任何由自己编译的 rootfs，都是相同的原理
主流发行版（Ubuntu/Debian）：它们通过 apt 管理软件，主机里没有现成的备份。

技巧：你可以用 rsync 工具，把开发板上的 /usr/lib 和 /usr/include 增量同步到主机的一个目录里，然后编译时指定这个目录为 Sysroot 。

5. 总结

无论是 C/C++ 还是 Rust，交叉编译的核心逻辑是一样的：

设置好交叉工具链（GCC/LLVM）的路径。
指定正确的 Sysroot 路径，让编译器能找到目标平台的头文件和动态库。

异步编程学习（03）同步与异步，Promise与Future

Sun, 15 Feb 2026 00:00:00 GMT

上一个文章通过线程、IO 模型、轮询三个角度解释了阻塞与非阻塞，但是：阻塞/非阻塞关注的是“过程”（线程状态），而同步/异步关注的是“消息通知机制”（结果交付）。

很多时候我们实现了“非阻塞”，却依然在“同步”地轮询。为了实现真正高效的系统，我们需要引入 Promise/Future 模型，让异步任务拥有同步的语义。

这里需要再强调一下：

同步 ≠ 阻塞
异步 ≠ 非阻塞

一、何为同步与异步

同步

调用者发起请求后，在没有得到结果之前，该调用就不返回。

调用必须等待结果

#include <iostream>
#include <thread>
#include <chrono>

int slow_square(int x) {
    std::this_thread::sleep_for(std::chrono::seconds(2));
    return x * x;
}

int main() {
    std::cout << "开始计算\n";

    // 同步调用
    int result = slow_square(5);

    std::cout << "结果: " << result << "\n";
}

异步

调用者发起请求后，调用直接返回，不需要立刻得到结果。结果通常通过回调（Callback）、事件或信号来通知调用者。

调用后立即返回，主线程不等待，结果通过回调通知

#include <iostream>
#include <thread>

void slow_square_async(int x, void(*callback)(int)) {
    std::thread([x, callback]() {
        std::this_thread::sleep_for(std::chrono::seconds(2));
        callback(x * x);
    }).detach();
}

void on_done(int result) {
    std::cout << "结果: " << result << "\n";
}

int main() {
    std::cout << "开始计算\n";

    slow_square_async(5, on_done);

    std::cout << "主线程继续运行\n";

    std::this_thread::sleep_for(std::chrono::seconds(3));
}

二、由回调函数到 Promise / Future

1. 基于回调函数的异步代码

上面的异步实现是通过回调完成的，但回调有几个问题：

控制流分散
错误处理麻烦
多个异步组合困难

例如，在一个后端服务中，我们需要：

异步读取用户信息
再根据用户信息读取订单
最后打印结果

#include <iostream>
#include <thread>
#include <chrono>

void get_user_async(void(*callback)(int)) {
    std::thread([callback]() {
        std::this_thread::sleep_for(std::chrono::seconds(1));
        callback(42);  // user_id
    }).detach();
}

void get_order_async(int user_id, void(*callback)(int)) {
    std::thread([user_id, callback]() {
        std::this_thread::sleep_for(std::chrono::seconds(1));
        callback(user_id * 10);  // order_id
    }).detach();
}

void on_order(int order_id) {
    std::cout << "订单ID: " << order_id << "\n";
}

void on_user(int user_id) {
    get_order_async(user_id, on_order);
}

int main() {
    get_user_async(on_user);
    std::this_thread::sleep_for(std::chrono::seconds(3));
}

在真实服务中，“读取用户信息”和“读取订单”通常意味着：

网络请求
数据库查询
RPC 调用

这些操作大部分时间都在等待 IO。如果采用同步阻塞方式处理，高频请求场景下，线程将大量时间浪费在等待上，系统吞吐量会严重下降。因此，异步执行往往是必须的。

然而，上述回调写法带来了明显问题：

业务逻辑被拆散到多个函数中
控制流不再是线性结构
错误必须逐层传递
一旦再增加一个步骤，就会继续嵌套

更严重的是：

代码的执行顺序已经不等于代码的书写顺序。

开发者阅读代码时，必须在多个回调之间来回跳转，才能还原真实的执行路径。这种现象被称为“回调地狱（Callback Hell）”。

核心问题

回调的本质问题不在于“异步”，而在于：

异步逻辑无法被表达为一个“值”。

我们无法写出类似这样的代码：

auto user = get_user_async();
auto order = get_order_async(user);
std::cout << order;

因为异步调用不会返回结果，而是通过回调“推送”结果。

那么，是否存在一种方式：既保持异步执行，又能像同步代码一样获取结果，同时避免把逻辑写进回调函数中？

为了解决这个问题，C++11 引入了 Promise/Future 模型。

2. Promise/Future 模型

Future 是什么？

Future = “未来会得到的结果”

它本质上是一个：现在没有值，但将来一定会有值的对象

Promise 是什么？

Promise = “承诺未来会给你一个值”

Promise 负责“生产结果”
Future 负责“消费结果”

它们是配对的。

Promise / Future 基本用法

#include <iostream>
#include <future>
#include <thread>

int main() {
    std::promise<int> prom;
    std::future<int> fut = prom.get_future(); // 配对

  	// 在另一个线程中设置 Promise
    std::thread t([&prom]() {
        std::this_thread::sleep_for(std::chrono::seconds(2));
        prom.set_value(25);
    });

    std::cout << "等待结果...\n";

  	// 在主线程中，从 Promise 获取 Future
    int result = fut.get();  // 会阻塞

    std::cout << "结果: " << result << "\n";

    t.join();
}

线程是异步执行的
但 future.get() 是同步等待
Future 让“异步执行”看起来像“同步取值”

Future 让异步任务拥有了“同步语义”

上述用户和订单的例子，可以改成这样：

#include <iostream>
#include <future>
#include <thread>
#include <chrono>

int main() {
    using namespace std::chrono_literals;

    std::cout << "开始\n";

    // 异步获取用户
  	// 这里的auto，返回的实际上就是 std::future<int> 类型
    auto user_future = std::async(std::launch::async, [] {
        std::this_thread::sleep_for(1s);
        std::cout << "获取用户完成\n";
        return 42;
    });

    // 像同步一样“取值”
    int user_id = user_future.get();

    // 异步获取订单
    auto order_future = std::async(std::launch::async, [user_id] {
        std::this_thread::sleep_for(1s);
        std::cout << "获取订单完成\n";
        return user_id * 10;
    });

    int order_id = order_future.get();

    std::cout << "订单ID: " << order_id << "\n";
}

虽然获取用户和获取订单都是异步操作，但是语义上是同步的。

std::async是 C++ 标准库引入的异步处理函数，在 GCC 和 Clang 的实现中，std::async 会明确创建一个新的线程用于执行异步操作，在 MSVC 的实现中，它则会创建一个新的线程，或者利用 Windows 系统维护的线程池。

std::async实际上是对std::promise的一种包装，底层上，它们都共享一个共享状态（Shared State）。std::promise 需要你手动去 set_value，如：

std::thread t([&prom]() {
    std::this_thread::sleep_for(std::chrono::seconds(2));
    prom.set_value(25);
});

而 std::async 则自动帮完成了“启动线程 -> 执行函数 -> 将返回值填入共享状态”的整个流水线。

很明显，当前的std::async并不适合高性能、高并发的操作，更适合作为简单的异步工具。在高并发场景中，开发者通常更倾向于使用自定义线程池，结合 std::promise 或 std::packaged_task 来实现可控的并发管理。

3. 异步不等于非阻塞

在上面的例子中

int user_id = user_future.get();
int order_id = order_future.get();

这两个操作是同步地获取结果，如果异步任务尚未完成，.get() 会阻塞当前线程直到结果就绪。这其实就是异步阻塞的一种（异步执行 + 同步等待）。

如果刚创建 future 就执行.get()，则会让异步代码退化为同步代码。

当然，对于 C++ 的 Promise/Future 模型，还有很多细节，比如 std::async 的执行策略、线程的生命周期管理、获取 future 的时机等等，但是这里不再深入，仅仅是引入这个模型来讨论同步异步。

真正理想的方案是既能用“同步风格”表达异步逻辑，又不会阻塞线程资源，很遗憾 C++ 标准库的 Promise/Future 模型不提供这个功能，真正实现异步非阻塞，还需要引入更高层级的抽象，使用第三方库，例如 boost::future，以及，最重要的协程。

举这个例子是为了表明：Future 并没有消灭阻塞，它只是把“等待”从回调结构，变成了“显式取值”。最大的意义在于：让异步任务有了同步语义。至于是否阻塞，则取决于调用方是否选择等待。

异步编程学习（02）阻塞非阻塞——线程、IO 与轮询

Sun, 15 Feb 2026 00:00:00 GMT

同步与异步，阻塞与非阻塞，真是异步编程中最难理解、最容易混淆的两对概念。

这个文章算是对该知乎回答的一个读书笔记

怎样理解阻塞非阻塞与同步异步的区别？ - 学刑法的程序员的回答 - 知乎 https://www.zhihu.com/question/19732473/answer/241673170

这里有一个很容易误解的点：

同步 = 阻塞

异步 = 非阻塞

chatGPT 这样告诉我：

概念	关注点
同步 / 异步	结果的交付方式
阻塞 / 非阻塞	线程是否被挂起

涉及的东西实在太多，就分开来写好了。

我把对阻塞与非阻塞的讨论分为线程状态语义与IO模型语义，因为我发现在讨论中经常会把它们搞混。

一、线程状态语义下的阻塞与非阻塞

线程状态语义就是指操作系统调度方面的语义，在 Linux 这种分时抢占式操作系统中，除了时间片轮转导致的线程调度，还包括线程被调度器挂起，进入阻塞状态，不再参与时间片调度，直到该线程被唤醒。

典型线程状态流转

核心问题只有：线程有没有进入waiting状态

1. 线程状态语义下的阻塞

阻塞 = 线程被内核挂起（sleep）

例子：

std::this_thread::sleep_for(3s);		 // 主动进入sleep
read(fd, buf, size);   							// 默认阻塞的读取操作，阻塞 IO
pthread_mutex_lock();								// 互斥锁

共同点：

线程被调度器移出 run queue
CPU 去执行别的线程
当前线程不占 CPU

一般阻塞操作都涉及系统调用，涉及用户态向内核态的切换，例如

read()读取文件，
sleep() 主动让出 CPU 使用权

2. 线程状态语义下的非阻塞

非阻塞 = 线程始终 runnable

例子：

while(1);      											// 死循环
heavy_compute(); 										// 耗时的计算任务
read(fd, ...)  											// O_NONBLOCK 且立即返回，非阻塞 IO

即使卡住：

线程仍在 running
没有进入 waiting

值得注意的是，当线程处于非阻塞状态时，只意味着线程会持续参与调度器的时间片轮转，但不意味着执行流不会被打断。

二、 IO 模型语义下的阻塞与非阻塞

IO 模型有很多，但是这里只讨论阻塞与非阻塞

作者：学刑法的程序员链接：https://www.zhihu.com/question/19732473/answer/241673170 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

I/O System Call 的阻塞/非阻塞，同步/异步

这里再重新审视 阻塞/非阻塞 IO 这个概念，其实阻塞和非阻塞描述的是进程的一个操作是否会使得进程转变为“等待”的状态，但是为什么我们总是把它和 IO 连在一起讨论呢？

原因是，阻塞这个词是与系统调用 System Call 紧紧联系在一起的，因为要让一个进程进入等待（waiting）的状态, 要么是它主动调用 wait() 或 sleep() 等挂起自己的操作，另一种就是它调用 System Call, 而 System Call 因为涉及到了 I/O 操作，不能立即完成，于是内核就会先将该进程置为等待状态，调度其他进程的运行，等到它所请求的 I/O 操作完成了以后，再将其状态更改回 ready 。

操作系统内核在执行 System Call 时， CPU 需要与 IO 设备完成一系列物理通信上的交互，其实再一次会涉及到阻塞和非阻塞的问题，例如，操作系统发起了一个读硬盘的请求后，其实是向硬盘设备通过总线发出了一个请求，它即可以阻塞式地等待IO 设备的返回结果，也可以非阻塞式的继续其他的操作。在现代计算机中，这些物理通信操作基本都是异步完成的，即发出请求后，等待 I/O 设备的中断信号后，再来读取相应的设备缓冲区。但是，大部分操作系统默认为用户级应用程序提供的都是阻塞式的系统调用（blocking systemcall）接口，因为阻塞式的调用，使得应用级代码的编写更容易（代码的执行顺序和编写顺序是一致的）。

1. 阻塞 IO

线程调用 System Call，涉及 IO 操作，不能立即返回，于是内核就会先将该线程置为等待状态，等到它所请求的 IO 操作完成了以后，再将其状态更改回 ready。

内核帮你等

这里的 IO 操作就是阻塞 IO

例如

#include <iostream>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <cstring>

int main() {
    int server_fd = socket(AF_INET, SOCK_STREAM, 0);

    sockaddr_in addr{};
    addr.sin_family = AF_INET;
    addr.sin_port = htons(8888);
    addr.sin_addr.s_addr = INADDR_ANY;

    bind(server_fd, (sockaddr*)&addr, sizeof(addr));
    listen(server_fd, 1);

    int client_fd = accept(server_fd, nullptr, nullptr);

    char buf[1024];

    std::cout << "等待数据...\n";

    // ⭐ 阻塞 IO
    int n = read(client_fd, buf, sizeof(buf));

    std::cout << "收到: " << std::string(buf, n) << "\n";

    close(client_fd);
    close(server_fd);
}

2. 非阻塞 IO

进程调用 System Call，涉及 IO 操作，如果当前数据尚未就绪，内核不会将该进程置为等待状态，而是立即返回一个错误码（如 EAGAIN / EWOULDBLOCK），进程仍然保持 ready 状态，由用户决定稍后再次发起请求。

内核不帮你等，自己决定怎么等

这里的 IO 操作就是非阻塞 IO

#include <iostream>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <cstring>

int main() {
    int server_fd = socket(AF_INET, SOCK_STREAM, 0);

    sockaddr_in addr{};
    addr.sin_family = AF_INET;
    addr.sin_port = htons(8888);
    addr.sin_addr.s_addr = INADDR_ANY;

    bind(server_fd, (sockaddr*)&addr, sizeof(addr));
    listen(server_fd, 1);

    int client_fd = accept(server_fd, nullptr, nullptr);

    // ⭐ 设置为非阻塞
    fcntl(client_fd, F_SETFL, O_NONBLOCK);

    char buf[1024];

    std::cout << "尝试读取数据...\n";

    int n = read(client_fd, buf, sizeof(buf));

    if (n < 0) {
        std::cout << "数据未就绪，立即返回\n";
    } else {
        std::cout << "收到: " << std::string(buf, n) << "\n";
    }

    close(client_fd);
    close(server_fd);
}

对于非阻塞 IO，获取数据结果有很多方式，暂时按下不表，只需知道：非阻塞 IO 本身并不负责“自动交付”结果，它只负责在资源未就绪时“拒绝挂起线程”。

三、容易混淆的点：口语中的阻塞与操作系统中的阻塞

阻塞这个词在口语里代表不动了，而在底层开发里代表线程状态的切换。如果在主线程里写了一个死循环 while(1);，程序会彻底卡死，但这在内核看来，它是最“活跃”的非阻塞任务。

我们可以简单的把操作分为阻塞操作与非阻塞操作：

阻塞操作：使当前线程被挂起的操作

阻塞的 System Call，发生用户态向内核态的转换
sleep() 主动进入 waiting，时间到后自动唤醒

非阻塞操作：持续占用 CPU 的操作

高负载计算任务
while(1) 死循环

以上非阻塞操作，尽管它们在口语里使得当前线程不动了，但是它们是非阻塞的。

四、轮询（Polling）会阻塞操作线程吗？

1. 用户态忙轮询（busy polling）

while (true) {
    if (data_ready()) {
        break;
    }
}

特点：

线程始终 running
CPU 被吃满
没有进入 waiting

线程语义：非阻塞

IO 模型语义：没有模型，只是暴力检查

一般称之为：忙等（busy wait）。

2. Linux 的 `poll()` 系统调用

poll() 系统调用既可以是阻塞的，也可以是非阻塞的。对于 poll() 系统调用，涉及多路 IO 复用，这里只是简单介绍一下，暂不深入。

阻塞的 poll()
```
poll(fds, nfds, 5000);   // 等 5 秒
poll(fds, nfds, -1);     // 无限等
```
这种情况：
- 当前线程进入内核
- 若没有事件，线程被挂起（waiting）
- 等待事件或超时唤醒
线程状态语义：阻塞

IO 模型语义：IO 多路复用（非阻塞 IO 模型的一种）
非阻塞的 poll()

立即返回轮循
```
poll(fds, nfds, 0);
```
这种情况：
- 内核：检查是否有事件，没有就直接返回
- 线程始终 runnable。
线程语义：非阻塞

IO模型语义：仍然是 IO 多路复用

异步编程学习（01）裸机中的同步异步

Sat, 14 Feb 2026 00:00:00 GMT

最早让我对这些异步编程产生兴趣的是 Rust 的 Tokio 异步运行时和 Embassy 框架，其中 Embassy 框架在单片机里引入了无栈协程，这对于传统 RTOS 和基于回调的事件驱动来说无疑是革命性的，让我对其产生了浓厚兴趣。

异步编程需要的前置概念实在太多，牵扯到

阻塞IO/非阻塞IO
同步/异步
select/poll
epoll
io_uring
协程

以及很多Linux系统编程和操作系统的概念，作为一个电子工程的学生，我还是决定先从最早熟悉的单片机裸机开始，一步步梳理一下我对异步编程的理解。

一、裸机框架中的同步

单片机裸机，可以视为一个单线程的应用，在 main 函数开始执行后，总体是一个同步逻辑：

// 伪代码
void main(void) {
    // 1. 系统初始化（时钟、GPIO、外设等）
    clock_init();           // 初始化系统时钟
    gpio_init();            // 初始化 GPIO 管脚
    uart_init(115200);      // 初始化串口通信
    timer_init();           // 初始化定时器
    dma_init();             // 初始化 DMA 控制器

    // 2. 启用全局中断
    enable_global_interrupt();

    // 3. 主循环：不断执行业务逻辑
    while (1) {
        // 执行具体的业务逻辑
        // 处理传感器数据、通信、计算等
        do_business_logic();

    }
}

在最基础的裸机代码中，一切都是顺序执行的（Synchronous）。当我们需要处理一个 IO 密集型任务（如等待传感器数据、DMA 搬运、串口发送）时，最简单的逻辑就是轮询（Polling）。

以 DMA 数据传输为例，裸机中确认 DMA 传输是否完成，可以通过轮循的方式：

CPU 发起 DMA 传输请求后，进入一个死循环，不断查询状态寄存器。

// 伪代码
void dma_transfer_polling(uint32_t src, uint32_t dst, uint32_t len) {
    // 1. 配置硬件：源地址、目的地址、长度
    DMA_REG->SAR = src;
    DMA_REG->DAR = dst;
    DMA_REG->CNT = len;

    // 2. 启动 DMA
    DMA_REG->CR |= DMA_CR_EN;

    // 3. [阻塞点]：死循环检查标志位
    // CPU 100% 耗在此处，无法响应其他任务（除非是高优先级中断）
    while (!(DMA_REG->SR & DMA_SR_TCIF)) {
        // CPU 只是在不断读取总线上的寄存器状态
        __NOP(); 
    }

    // 4. 清除标志位，关闭 DMA
    DMA_REG->SR &= ~DMA_SR_TCIF;
    DMA_REG->CR &= ~DMA_CR_EN;
}

这里的操作就是同步的，由于裸机框架中，没有操作系统的任务调度，CPU 只能卡在这里，直到 DMA 传输完成，函数才会返回，才能继续执行后续代码。

这里的 CPU 实际上是一个忙等状态，不断对 DMA 状态寄存器进行轮询（Poll）。

二、裸机框架中的异步

中断（Interrupt）是裸机框架中唯一的、真正的异步机制。 它允许 CPU 在发起硬件请求后，立即返回去执行 while(1) 循环中的其他逻辑，直到硬件完成任务，并通过中断服务函数（ISR），来让 CPU 执行后续逻辑。

CPU 完成 DMA 配置后，就去负责其他事情，当 DMA 传输完成后，通过硬件中断，CPU 进入中断服务函数，来完成相关操作：

// 伪代码
// 全局状态标志（需加 volatile 防止编译器过度优化）
volatile bool g_dma_done = false;

void dma_transfer_irq(uint32_t src, uint32_t dst, uint32_t len) {
    // 1. 配置并开启 DMA 中断使能 (TCIE)
    DMA_REG->CR |= DMA_CR_TCIE; 
    
    // 2. 设置地址与长度并启动
    DMA_REG->SAR = src;
    DMA_REG->DAR = dst;
    DMA_REG->CNT = len;
    DMA_REG->CR |= DMA_CR_EN;

    // 3. [非阻塞]：直接返回，CPU 可以去跑 main 循环里的其他逻辑
    return;
}

// 硬件自动调用的中断服务程序 (ISR)
void DMA_IRQHandler(void) {
    if (DMA_REG->SR & DMA_SR_TCIF) {
        // 处理业务逻辑（例如设置标志位或调用回调函数）
        g_dma_done = true;
        
        // 关键：清除中断标志，否则会死循环进入中断
        DMA_REG->SR &= ~DMA_SR_TCIF;
        DMA_REG->CR &= ~DMA_CR_EN;
    }
}

在调用dma_transfer_irq后，函数立即返回，去执行while(1)循环后面的任务，当 DMA 传输完成后，通过中断强制切换 CPU 来运行 ISR，在里面执行业务逻辑。

但其实一般不会在 ISR 中执行耗时的业务逻辑，一般是设置标志位，在while(1)中读取改标志位，如果已经被设置，则执行耗时的业务逻辑。ISR 应该是快速退出的。

编程日记（01）过早抽象也是万恶之源！

Fri, 13 Feb 2026 00:00:00 GMT

程序员圈子最著名的观点，莫过于“过早优化是万恶之源”，在踩了无数坑之后，我认为：过早抽象也是万恶之源！

一、C++ 领域的过度设计 / 过早抽象

所谓“过早抽象”，可以认为是过度设计的另一个称呼，但是最早我对过度设计有误解。作为一个C/C++开发者，我曾以为过度设计，就是 Java 那种过度依赖设计模式，无论干什么都先来一套工厂模式、观察者模式，导致业务逻辑冗余。但是，我发现过度设计在 C++ 领域，一个更形象的说法是过度抽象。

C++ 和 Rust 这种高级语言的精髓是零成本抽象，尤其在嵌入式 C++ 这种高度 C 和 C++ 混写的领域，开发者需要用 C++ 提供的功能封装原始的 C 接口，不仅要做的对 C 接口的兼容，还用利用 C++ 的高级特性来引入 RAII、生命周期、所有权等内存安全的理念，来使得基于 C SDK 开发的项目更具有可读性和可维护性。

但是，这种 C 和 C++ 混写的领域恰恰是改革深水区：一个芯片的某个领域的 C SDK（例如 RK 的 Rockit），是原厂工程师不断调试和封装的结果，内部封装了复杂的内存管理、硬件管理，抑或是隐式逻辑，它会有自己的一套逻辑，例如某个函数封装了对寄存器的配置，或者利用回调函数来实现数据的转移。而作为这个 C SDK 的二次开发者，我们很难说能完全理解这个 SDK，更不用说比原厂工程师还懂，这种情况下，使用 C API 反而是更明智的选择。

二、试图用语言特性去掩盖业务知识的匮乏

我这个半吊子 C++ 开发者，总是妄图用所谓“现代 C++ 的高级特性”来封装原始 C API，例如：

用 C++17 的 std::variant 来封装 Rockit 的媒体帧，以下是当时我和Gemimi的对话

事实上：当时我根本没有多少对这个媒体帧的理解！

最终的结果是：这个模型在接触到 VI、VPSS、VENC 之间的硬件绑定或者软件处理模型时失效了，复杂度上升，而我也无力维护，最终不了了之。

简言之，就是我试图用语言的高度，去掩盖对业务深度理解的匮乏。

三、AI 时代的认知负债

“过早抽象”本质上是一种认知负债——在还没赚到足够的“领域知识”时，就提前支取了“架构设计”。

我曾经产生过一种幻觉，在现在的AI时代，我只要问问 AI，就能掌握 C++ 的种种高级特性，并且运用于工程中，但是问题就出在这儿：我用的 Agent，默认我和它都是 C++/Rust 的高级开发者，它的语料库里充斥着

设计模式
零成本抽象
ownership
trait system
variant / enum

AI 可以对各种特性可以有鞭辟入里的讲解，但唯独缺少了贴合实际的实战，最终的结果就是诱导我进行过度抽象，可以说是双向奔赴。

在 AI 时代，无论是代码还是写作，高级特性、华丽的语言开始变得廉价，但是对某个领域的深入理解仍然昂贵，我想，这也是人工智能与作家、艺术家、工程师的本质区别。

C++、Rust那种零成本抽象，某种程度上是高级开发者的工具，它有巨大的认知开销，需要开发者对业务逻辑非常熟悉，才能用语言特性来写出高性能的代码。

而对于我这种半吊子初学者，更应该遵守的是

20/80 原则：

Make it work（先跑通功能）。
Make it right（对代码进行抽象）。
Make it fast（对代码进行性能优化）。

抽象应该是业务逻辑驱动的，而不是直觉驱动的，性能优化应该是数据驱动的，而不是直觉驱动的。

四、什么时候才应该进行抽象

抽象的本质是压缩重复信息，在 Make it work 的过程中，注意那些需要多次重复的操作，它们才是需要进行抽象的地方，如果没有重复，或者用的很少，就不应该去进行抽象。

还是回到那个观点：想要把语言的高级特性、设计模式运用熟练，需要开发者对业务逻辑有深刻的理解，我作为一个成长在 AI 时代的开发者，最不缺的就是高级特性和设计模式，缺的是对业务逻辑的理解。

毕设日志（四）NPU 推理与硬件资源分配

Thu, 12 Feb 2026 00:00:00 GMT

经过漫长的摸索和 Debug，我意识到在 RV1106G3 这个单核 A7 + 256MB DDR3 的嵌入式设备上，再精妙的设计也要向现实妥协：之前设想的异构并行逻辑，受限于 DDR3 的带宽，导致 NPU 获取图像超时，产生运行时报错。只能退而求其次，先用最原始的串行逻辑，就算显示帧率感人，CPU 占用高，但先把基础功能实现了，再谈性能优化。

Luckfox 的 RKMPI 例程中提供了 YOLOv5 和 Retainface 两种示例，虽然都是 NPU 推理，但是硬件资源分配和视频流处理的逻辑大不相同，其中，YOLOv5 推理对性能要求是比 Retainface 高很多的。

::github{repo="LuckfoxTECH/luckfox_pico_rkmpi_example"}

一、三种硬件资源（VI、VPSS、VENC）分配方式

为了完成采集图像给 NPU 推理，把推理结果标注到视频流上，编码后进行流媒体分发这个基本流程，在硬件资源分配上，一共有三种方式：

1. VI 通道分流

VI 通道分为 ch0 和 ch1，一路输出 NV12 给 VENC 编码，一路输出 NV12 经由格式转换和缩放后给NPU推理使用。硬件流水线，效率最高，CPU 压力小，但是多硬件模块并行访问内存，内存带宽压力最大。运行 Retainface 这个轻量级模型还行。

在使用 VI 通道分流时，就算没有加入 NPU 推理，也会有 VI 通道采集报错，在使用 VPSS 通道分流的基础上，完成了 IPC 的基础功能，后续就没有再考虑过 VI 通道分流。

Retainface 例程使用的是 VI 通道分流

2. VPSS 通道分流

VI 通道只保留一个，VPSS 通道分为两个，一个给 VENC 编码，一个缩放到模型需要的大小（例如 YOLOv5 模型需要的是 640x640 ），再经由格式转换后给 NPU 推理。

使用 VPSS 通道分流时，VPSS 通道和图像处理（RGA 或者 opencv-mobile）能输出正确的图像，但仍有NPU 获取图像超时。

3. 不分流，串行逻辑

VI 通道和 VPSS 通道只保留一个，不使用硬件绑定（自动流水线），而是软件手动进行流转。先格式转换 + 缩放，NPU 推理后进行标注，再进行编码和流媒体分发。CPU 压力最大，效率（帧率）最低，但是内存带宽压力小。

YOLOv5 使用的是串行逻辑

二、AIPC 软件设计

::gitHub{repo="haoyn231/aipc"}

理想情况下，是使用 VI 通道分流，或者 VPSS 通道分流，尽可能利用 RV1106 的硬件处理单元，降低 CPU 压力，但是这条路让我踩了无数坑，不是 VI 采集失败就是 NPU 推理失败，基本都是硬件处理单元压力过大、内存带宽压力过大导致的，只能退而求其次。

对于我毕设准备实现的 YOLOv5 和 Retainface 两个模型来说，它们对硬件资源和内存的需求各不相同，当前我通过一刀切的方式实现了“跑起来”这个基础需求：

纯 IPC 模式：不进行硬件分流，最大化利用硬件资源进行采集和编解码，实现 1080p 推流
AI 推理模式：不进行硬件分流，串行逻辑，在个位数帧率下实现了 YOLOv5 推理 + 标注 + 推流

应该是设计一个冷切换的硬件资源分配策略（初始化系统时调用，切换模型时，对硬件资源进行重新配置），以满足不同模型对硬件资源的需求，也方便后续拓展和性能调优。

毕设日志（三）编码视频流的多路分发处理与优化分析

Thu, 05 Feb 2026 00:00:00 GMT

截止tag: v0.4.0，实现了：

1080p@15hz 下多路并发

RTSP 推流
录制 mp4
WebSocket 实时预览

个位数内存占用，无内存泄露，但是问题是：开启了过多的线程。

1080p@15hz 是实际测试，设计参数是1080p@30hz，后面再优化性能

::github{repo="haoyn231/aipc"}

我的设计原则是：优先 Make it work，再说 Make it fast 和 better 的事。在上述三个路径同时运行时，通过 Top 查看性能占用，RV1106 的单核 A7 占用会飙到 40%，内存占用倒不是很多，总占用才 35MB 左右（系统占用 29MB ），总内存有 256MB 呢（实际可用内存 144MB ）。

但问题是，之前使用 http 信令的 WebRTC 用于 Web 界面预览，在同时执行 RTSP 推流和 mp4 录制时，SOC 芯片明显发热。于是我决定把 Web 界面预览的操作用WebSocket 来简单实现，后期再说 WebRTC 的事。

在使用 WebSocket 进行 Web 界面预览时，运行效果良好，延时也低，但是运行几十秒后系统就会卡死，通过 Top 监控，不是 CPU 占用过高或者内存泄露的问题，暂不清楚。

后面发现是忘了插天线，导致网络压力大时ssh连接断开，我误以为系统卡死，难绷

于是决定先对当前并发逻辑进行优化，从优先实现功能的多线程架构改为用 ASIO（epoll）来优化网络 IO 任务，降低 CPU 占用，为后面引入 RKNN 推理打基础（虽然NPU推理大概率吃内存而不是CPU，但是先搞了再说）。

一、多线程架构：分发器+多消费者

目前实现的多线程架构，算是一步步 Vibe Coding 出来的，没有及时 Code Review，复杂度已经上升到一种程度了：再不进行 Code Review 和重构，作为提示词咏唱魔法师的我已经完全看不懂了，更别说维护。

因此在日志的这部分，将对这个架构进行一次解析，之后就用 ASIO 进行重构，力求提升可读性，降低复杂度。

对于 VENC 编码流的处理（RTSP、WebRTC、文件保存、WebSocket网页预览），采用分发器 + 多消费者模式：

一个获取线程：从 VENC 获取编码流

多个消费者线程：RTSP、WebRTC、文件保存、WebSocket网页预览各自独立的消费者

设计理念：

零拷贝：所有消费者共享同一内存块（通过 shared_ptr 引用计数）

解耦：任一消费者处理慢不影响其他消费者

扩展性好：新增功能只需注册新消费者

1. 视频流的获取路径

在main函数中，开启流分发

# src/main.cpp 
// 启动流分发
stream_manager_start();

启动分发器

# src/thread_stream.cpp
// class StreamDispatcher  
void Start() {
    if (running_) return;
    running_ = true;

    // 先启动消费者分发线程（确保它们准备好接收数据）
    for (auto& c : consumers_) {
        c.thread = std::thread(&StreamDispatcher::DispatchLoop, this, &c);
        LOG_DEBUG("Started dispatch thread for consumer: {}", c.name);
    }

    // 短暂延迟，确保消费者线程就绪
    std::this_thread::sleep_for(std::chrono::milliseconds(50));

    // 最后启动获取线程
    fetch_thread_ = std::thread(&StreamDispatcher::FetchLoop, this);

    LOG_INFO("StreamDispatcher started with {} consumers", consumers_.size());
}

整个编码视频流的生产者线程

# src/thread_stream.cpp
// class StreamDispatcher 
/**
 * @brief 获取循环 - 从 VENC 获取编码流并分发到各队列
 * 
 * 使用零拷贝共享：多个消费者共享同一个 VENC buffer
 * shared_ptr 引用计数管理，最后一个使用者释放时调用 ReleaseStream
 */
void FetchLoop() {
    LOG_DEBUG("Fetch loop started for VENC channel {}", venc_chn_id_);

    uint64_t frameCount = 0;
    uint64_t errorCount = 0;

    while (running_) {
        // 从 VENC 获取编码流（零拷贝，shared_ptr 管理生命周期）
        auto stream = acquire_encoded_stream(venc_chn_id_, 1000);  // 1秒超时

        if (!stream) {
            errorCount++;
            if (errorCount % 5 == 1) {  // 每5次错误打印一次
                LOG_WARN("Failed to get stream from VENC channel {} (error #{})", 
                         venc_chn_id_, errorCount);
            }
            continue;
        }

        frameCount++;
        errorCount = 0;  // 重置错误计数

        // 打印帧信息
        if (frameCount <= 5 || frameCount % 30 == 0) {
            LOG_DEBUG("Got frame #{}, size={} bytes", 
                     frameCount, stream->pstPack ? stream->pstPack->u32Len : 0);
        }

        // 分发给所有消费者（零拷贝，只是增加引用计数）
        for (auto& c : consumers_) {
            c.queue->push(stream);  // shared_ptr 拷贝，引用计数 +1
        }

        // stream 在这里离开作用域后，引用计数 -1
        // 当所有消费者都处理完毕后，最后一个释放时会调用 ReleaseStream
    }

    LOG_DEBUG("Fetch loop exited, total frames: {}", frameCount);
}

其中，auto stream = acquire_encoded_stream(venc_chn_id_, 1000);获取的是std::shared_ptr封装的编码流EncodedStreamPtr，确保多消费者场景下的正确生命周期管理，具体参考：毕设日志（二）Luckfox-RKMPI示例的资源管理分析

2. 生产者向消费者的数据传输：队列

生产者线程向消费者线程传递编码数据流EncodedStreamPtr，通过一个特殊的队列，每个消费者都维护一个队列

# src/common/media_buffer.h
// ============================================================================
// 线程安全的媒体队列 - 用于模块间数据分发
// ============================================================================

/**
 * @brief 线程安全的媒体缓冲队列
 * 
 * 用于 VENC -> RTSP/WebRTC 的数据分发
 * 支持有界队列，超出容量时自动丢弃最旧的帧（背压处理）
 * 
 * @tparam T 媒体数据类型（VideoFramePtr 或 EncodedStreamPtr）
 */
template <typename T>
class MediaQueue {
public:
  		// 具体实现见：https://github.com/haoyn231/aipc/blob/main/src/common/media_buffer.h
}

消费者线程从它们单独维护的队列中获取编码数据帧EncodedStreamPtr

3. 消费者的注册、线程启动和数据流转

注册

消费者线程将自己的流消费者回调函数注册到 StreamDispatcher （生产者）

StreamManager（在 src/thread_stream.cpp）它负责初始化各个业务模块（RTSP、File等）。

以消费者 RTSP 为例：

# src/thread_stream.cpp
StreamManager::StreamManager(const StreamConfig& config)
    : config_(config) {
    
    LOG_INFO("Creating StreamManager...");
    
    // 创建 RTSP 线程（如果启用）
    if (config_.enable_rtsp) {
        rtsp_thread_ = std::make_unique<RtspThread>(config_.rtsp_config);
        
        if (rtsp_thread_->IsValid()) {
            // 注册 RTSP 消费者到流分发器
            rkvideo_register_stream_consumer(
                "rtsp",
                &RtspThread::StreamConsumer,
                rtsp_thread_.get(),
                3  // 队列大小
            );
            LOG_INFO("RTSP consumer registered");
        } else {
            LOG_ERROR("Failed to create RTSP thread");
            rtsp_thread_.reset();
        }
    }
    
    // 创建文件保存线程（如果启用）
		// ......
    
    // 创建 WebRTC 线程（如果启用）
		// ......
    
    // 创建 WebSocket 预览服务器（如果启用）
		// ......
    
    LOG_INFO("StreamManager created");
}

这里传递了一个关键的东西：回调函数指针 (&RtspThread::StreamConsumer)。这相当于 RTSP 模块说：“以后有视频帧了，请调用这个函数给我。”

StreamDispatcher（实例为g_dispatcher）收到注册请求后，在其内部列表 consumers_ 中增加一项。

# src/rkvideo/rkvideo.cpp
int rkvideo_init() {
  
  	// ......
		// 创建流分发器
    g_dispatcher = std::make_unique<StreamDispatcher>(0);
    
    // 注册已登记的消费者
    {
        std::lock_guard<std::mutex> lock(g_consumerMutex);
        for (const auto& reg : g_pendingConsumers) {
            g_dispatcher->RegisterConsumer(reg.name, 
                [reg](EncodedStreamPtr stream) {
                    if (reg.callback) {
                        reg.callback(stream, reg.userData);
                    }
                }, 
                reg.queueSize);
        }
        g_pendingConsumers.clear();
    }
  	return 0;
  
  	// ......
}

它同时为这个消费者创建了一个专属队列 (EncodedStreamQueue)。

# src/rkvideo/stream_dispatcher.h
/**
 * @brief 注册流消费者
 * 
 * @param name 消费者名称（用于日志）
 * @param consumer 消费者回调函数
 * @param queue_size 消费者队列大小（背压控制）
 */
void RegisterConsumer(const std::string& name, StreamConsumer consumer, size_t queue_size = 3) {
  	
  	// 在增加消费者的同时，创建了一个专属队列
    consumers_.push_back({name, consumer, std::make_unique<EncodedStreamQueue>(queue_size)});
    LOG_INFO("Registered stream consumer: {}", name);
}

启动线程

为每个消费者创建线程，并创建获取数据流的线程（生产者）

# src/rkvideo/stream_dispatcher.h

// Class StreamDispatcher
/**
 * @brief 启动分发器
 * 
 * 启动后会创建：
 * 1. 多个分发线程：为每个消费者分发数据（先启动，确保准备就绪）
 * 2. 一个获取线程：从 VENC 获取编码流
 */
void Start() {
    if (running_) return;
    running_ = true;
		
  	// 依次启动所有消费者，每个都创建一个线程
    for (auto& c : consumers_) {
        c.thread = std::thread(&StreamDispatcher::DispatchLoop, this, &c);
        LOG_DEBUG("Started dispatch thread for consumer: {}", c.name);
    }

    // 短暂延迟，确保消费者线程就绪
    std::this_thread::sleep_for(std::chrono::milliseconds(50));

    // 最后启动获取线程
    fetch_thread_ = std::thread(&StreamDispatcher::FetchLoop, this);

    LOG_INFO("StreamDispatcher started with {} consumers", consumers_.size());
}

运行（数据流转）

生产者 (FetchLoop 线程)
- 从 VENC 拿到 EncodedStreamPtr (shared_ptr)。
- 它遍历所有消费者，把同一份指针 push 到它们各自的队列中。
缓冲 (MediaQueue)

每个消费者都有自己独立的队列。RTSP 处理慢了，只会堆积 RTSP 的队列，不会影响文件录制的队列。所谓解耦。

消费者 (DispatchLoop 线程)

注意：RTSP 的回调函数不是在 RTSP 自己的网络线程里执行的，而是在这个专门的“分发线程”里执行的。

唤醒：当队列有数据，DispatchLoop 被唤醒。
执行回调：

# src/rkvideo/stream_dispatcher.h 
/**
 * @brief 分发循环 - 从队列取出数据并调用消费者回调
 */
void DispatchLoop(ConsumerInfo* consumer) {
    LOG_DEBUG("Dispatch loop started for consumer: {}", consumer->name);

    uint64_t processedCount = 0;
    while (running_) {
        EncodedStreamPtr stream;
        // 尝试从队列中pop出数据
        if (consumer->queue->pop(stream, 1000)) {  // 1秒超时
            if (stream && consumer->callback) {
                processedCount++;
                if (processedCount <= 5 || processedCount % 30 == 0) {
                    LOG_DEBUG("Consumer {} processing frame #{}, ref_count={}", 
                             consumer->name, processedCount, stream.use_count());
                }
                consumer->callback(stream); // <--- 这里调用了 RtspThread::StreamConsumer
            }
        }
    }

    LOG_DEBUG("Dispatch loop exited for consumer: {}, processed {} frames", 
             consumer->name, processedCount);
}

最终发送：代码跳转到 src/rtsp/thread_rtsp.cpp 的 StreamConsumer，最终调用 SendVideoFrame 把数据塞给网络库（Live555或其他）。

# src/rtsp/rk_rtsp.cpp
bool RtspServer::SendVideoFrame(const EncodedStreamPtr& stream) {
  if (!initialized_ || !stream || !stream->pstPack) {
      LOG_WARN("SendVideoFrame: invalid state or stream");
      return false;
  }

  // 从 MPI buffer 获取虚拟地址
  void* data = RK_MPI_MB_Handle2VirAddr(stream->pstPack->pMbBlk);
  if (!data) {
      LOG_ERROR("Failed to get virtual address from MB handle");
      stats_.errors++;
      return false;
  }

  LOG_TRACE("SendVideoFrame: len={}, pts={}", stream->pstPack->u32Len, stream->pstPack->u64PTS);

  return SendVideoData(
      static_cast<const uint8_t*>(data),
      stream->pstPack->u32Len,
      stream->pstPack->u64PTS
  );
}

4. 总结

当前的架构可以理解为：“1个生产者 + N个搬运工线程 + N个队列”

这是疏于Code Review的Vibe Coding产物，力求快速实现功能，它目前的问题是：

消费者注册与对应回调函数注册繁琐
消费者线程生命周期管理复杂：需要进行running_判断和手动join()，容易造成死锁，难以维护
单核CPU上多线程上下文切换代价大

单看流程图就头大了

二、引入 ASIO 后的事件驱动模型

系统现在采用“1个获取线程 + 1个主 IO 线程 + 1个文件线程”的精简模式，详情见tag: v0.5.0

其中：

获取线程与多线程模型相同
主 IO 线程通过 ASIO 事件驱动模型调度 RTSP、WebSocket、WebRTC 等网络 IO 任务
文件线程负责 mp4 视频录制

原模型中“N个队列”的数据传输模式也修改了：

主IO线程的多个任务直接通过 Lambda 闭包封装一份编码数据帧的引用，不用通过队列传递
文件线程通过队列获取

1. 视频流的获取路径

该模型下视频流的获取路径和多线程模型基本相同

# src/rkvideo/stream_dispatcher.h
// class StreamDispatcher
/**
 * @brief 启动分发器
 * 
 * 启动后会创建：
 * 1. 一个 Fetch 线程：从 VENC 获取编码流并直接分发
 * 2. Queued 类型消费者的独立处理线程
 */
void Start() {
    if (running_) return;
    running_ = true;

    // 启动 Queued 类型消费者的处理线程
    for (auto& c : consumers_) {
        if (c.type == ConsumerType::Queued && c.queue) {
            c.thread = std::thread(&StreamDispatcher::QueuedConsumerLoop, this, &c);
            LOG_DEBUG("Started queued consumer thread for: {}", c.name);
        }
    }

    // 短暂延迟，确保 Queued 消费者线程就绪
    if (HasQueuedConsumers()) {
        std::this_thread::sleep_for(std::chrono::milliseconds(50));
    }

    // 启动 Fetch 线程
    fetch_thread_ = std::thread(&StreamDispatcher::FetchLoop, this);

    LOG_INFO("StreamDispatcher started with {} consumers (optimized for single-core)", 
             consumers_.size());
}

2. 消费者的注册：AsyncIO 类型和 Queued 类型

消费者类型与结构体

# src/rkvideo/stream_dispatcher.h
/**
 * @brief 消费者类型
 */
enum class ConsumerType {
    Direct,     ///< 直接在 Fetch 线程中执行（仅用于极快的操作）
    AsyncIO,    ///< 通过 asio::post 投递到 IO 线程执行（网络发送）
    Queued      ///< 通过队列投递到独立线程（文件写入等阻塞操作）
};

// class StreamDispatcher
struct ConsumerInfo {
    std::string name;
    StreamConsumer callback; 											// 回调函数
    ConsumerType type = ConsumerType::AsyncIO;		// 默认为 AsyncIO 类型
    std::unique_ptr<EncodedStreamQueue> queue;  	// 仅 Queued 类型使用
    std::thread thread;                          	// 仅 Queued 类型使用
};

消费者注册仍由流分发器负责

# src/rkvideo/stream_dispatcher.h
// class StreamDispatcher
/**
 * @brief 注册流消费者
 * 
 * @param name 消费者名称（用于日志）
 * @param consumer 消费者回调函数
 * @param type 消费者类型，决定回调的执行方式
 * @param queue_size 队列大小（仅对 Queued 类型有效）
 */
void RegisterConsumer(const std::string& name, StreamConsumer consumer, 
                      ConsumerType type = ConsumerType::AsyncIO,
                      size_t queue_size = 3) {
    ConsumerInfo info;
    info.name = name;
    info.callback = consumer;
    info.type = type;

    // 只有 Queued 类型需要队列和线程
    if (type == ConsumerType::Queued) {
        info.queue = std::make_unique<EncodedStreamQueue>(queue_size);
    }

    consumers_.push_back(std::move(info));
    LOG_INFO("Registered stream consumer: {} (type={})", name, 
             type == ConsumerType::Direct ? "Direct" :
             type == ConsumerType::AsyncIO ? "AsyncIO" : "Queued");
}

3. 数据流转

该函数由生产者线程调用

对于 Direct 类型：直接在生产者线程中调用消费者回调
对于 AsyncIO 类型：将消费者回调通过 lambda 投递到IO线程到主IO循环中执行
对于 Queued 类型：放入队列，由专属线程处理

# src/rkvideo/stream_dispatcher.h
/**
 * @brief 分发帧给所有消费者
 * 
 * 根据消费者类型选择不同的分发策略：
 * - Direct: 直接在当前线程调用
 * - AsyncIO: 通过 asio::post 投递到 IO 线程
 * - Queued: 放入消费者专属队列
 */
void DispatchToConsumers(EncodedStreamPtr stream) {
    for (auto& c : consumers_) {
        if (!c.callback) continue;

        switch (c.type) {
            case ConsumerType::Direct:
                // 直接在 Fetch 线程中执行（仅用于极快的操作）
                c.callback(stream);
                break;

            case ConsumerType::AsyncIO:
                // 投递到 IO 线程执行（网络发送）
                // 捕获 stream 的拷贝，增加引用计数
                PostToIo([callback = c.callback, stream]() {
                    callback(stream);
                });
                break;

            case ConsumerType::Queued:
                // 放入队列，由专属线程处理（文件写入）
                if (c.queue) {
                    c.queue->push(stream);
                }
                break;
        }
    }
}

PostToIo最终调用

# src/common/asio_context.h
// class IoContext
/**
 * @brief 投递任务到 IO 线程执行
 * 
 * 线程安全，可从任意线程调用
 * 
 * @param handler 要执行的任务
 */
template<typename Handler>
void Post(Handler&& handler) {
    asio::post(io_context_, std::forward<Handler>(handler));
}

4. 任务闭包化：使用 Lambda 捕获与 ASIO 异步调度

对于 AsyncIO 类型消费者任务的处理，是使用 Lambda 表达式将“数据”与“行为”打包成一个异步任务（Closure），直接投递至主 IO 线程的事件循环中

# src/rkvideo/stream_dispatcher.h 
case ConsumerType::AsyncIO:
    // 将 stream 拷贝一份捕获到 lambda 中
		// 并非数据深拷贝，而是 shared_ptr 引用计数自动 +1
    PostToIo([callback = c.callback, stream]() {
        callback(stream); // 任务执行时，引用计数保证了 buffer 依然有效
    });
    break;

这种设计解决了原多线程编程中的生命周期问题和竞争问题：

生命周期问题：

生产者视角：FetchLoop 只需要完成任务投递，随后 stream 离开局部作用域，引用计数减 1。
消费者视角：只要主 IO 线程中的任务尚未执行完毕，Lambda 闭包就一直持有该 stream 的副本，引用计数不为 0，底层硬件 Buffer 就绝不会被 VENC 驱动释放。
无需手动维护：一旦 callback 执行结束，Lambda 闭包销毁，引用计数降至 0，此时 ReleaseStream 会被自动触发，将 Buffer 归还硬件。

消除上下文切换与竞争：

在原有的“搬运工”模型中，RTSP 或 WebSocket 模块在发送数据前，往往需要先获取锁来从自己的队列中提取帧。而在 ASIO 模型下：

线程一致性：所有的网络发送逻辑（RTSP 发送、WS 推送）全部运行在 Main IO Thread 这一同一个线程中。
无锁设计：由于任务是顺序执行的，网络模块内部的发送缓冲区不再需要互斥锁来保护，消除了 CPU 在多个 Dispatch 线程间进行内核级切换的开销。

5. 总结

相比原多线程模型，流程图精简了不少，也提升了性能（砍了好几个不必要的线程）。

毕设日志（二）Luckfox RKMPI示例的资源管理分析

Sat, 31 Jan 2026 00:00:00 GMT

分析 luckfox_pico_rtsp_retinaface_osd例程

::github{repo="LuckfoxTECH/luckfox_pico_rkmpi_example"}

一、VENC编码和RTSP推流线程

1. 编码和推流线程分析

在 RKMPI 架构中，VI（视频输入）到 VENC（视频编码）的数据流转通常是硬件自动完成的，实现零拷贝。我们的任务是从 VENC 获取编码后的 H.264/H.265 数据包并交付给推流协议（如 RTSP）。

static void *GetMediaBuffer(void *arg) {
	(void)arg;
	printf("========%s========\n", __func__);
	void *pData = RK_NULL;
	int s32Ret;

	VENC_STREAM_S stFrame;
	stFrame.pstPack = (VENC_PACK_S *)malloc(sizeof(VENC_PACK_S));

	while (1) {
    
    // 获取编码后的H.264包
		s32Ret = RK_MPI_VENC_GetStream(0, &stFrame, -1);
		if (s32Ret == RK_SUCCESS) {
			if (g_rtsplive && g_rtsp_session) {
				pData = RK_MPI_MB_Handle2VirAddr(stFrame.pstPack->pMbBlk);
				rtsp_tx_video(g_rtsp_session, (uint8_t *)pData, stFrame.pstPack->u32Len,
				              stFrame.pstPack->u64PTS);
				rtsp_do_event(g_rtsplive);
			}

      // 资源释放，释放编码后的包
			s32Ret = RK_MPI_VENC_ReleaseStream(0, &stFrame);
			if (s32Ret != RK_SUCCESS) {
				RK_LOGE("RK_MPI_VENC_ReleaseStream fail %x", s32Ret);
			}
		}
    
    // 暂停10ms
		usleep(10 * 1000);
	}
	printf("\n======exit %s=======\n", __func__);
  
  // 线程结束时释放stFrame
	free(stFrame.pstPack);
	return NULL;
}

2. `VENC_STREAM_S`编码数据帧分析

其中，主要的帧格式是VENC_STREAM_S，可以看到它封装了 VENC 支持的编码格式

/* Defines the features of an stream */
typedef struct rkVENC_STREAM_S {
    VENC_PACK_S ATTRIBUTE* pstPack;            /* R; stream pack attribute*/
    RK_U32      ATTRIBUTE u32PackCount;        /* R; the pack number of one frame stream*/
    RK_U32      u32Seq;                        /* R; the list number of stream*/

    union {
        VENC_STREAM_INFO_H264_S   stH264Info;                        /* R; the stream info of h264*/
        VENC_STREAM_INFO_JPEG_S   stJpegInfo;                        /* R; the stream info of jpeg*/
        VENC_STREAM_INFO_H265_S   stH265Info;                        /* R; the stream info of h265*/
        VENC_STREAM_INFO_PRORES_S stProresInfo;                      /* R; the stream info of prores*/
    };

    union {
        VENC_STREAM_ADVANCE_INFO_H264_S   stAdvanceH264Info;         /* R; the stream info of h264*/
        VENC_STREAM_ADVANCE_INFO_JPEG_S   stAdvanceJpegInfo;         /* R; the stream info of jpeg*/
        VENC_STREAM_ADVANCE_INFO_H265_S   stAdvanceH265Info;         /* R; the stream info of h265*/
        VENC_STREAM_ADVANCE_INFO_PRORES_S stAdvanceProresInfo;       /* R; the stream info of prores*/
    };
} VENC_STREAM_S;

二、NPU推理线程

1. NPU推理线程分析

利用RK_MPI_VI_GetChnFrame从 VI 通道获取原始数据帧，再利用 opencv-mobile 进行格式转换和缩放，最后用 RGN，在 VENC 编码前将 OSD 合入视频帧

格式转换：将 NV12 转换为 BGR
缩放：将图像适配模型输入的 640×640 尺寸

static void *RetinaProcessBuffer(void *arg) {
  
  // ... 变量初始化 ...
  
  // 这是rkmpi中最核心最原始的数据帧，用它来承接从VI通道中获取的原始图像
	VIDEO_FRAME_INFO_S stViFrame;

	while(1)
	{
    // 手动抓取，主动向VI的通道1（专门用于推理的）请求一帧数据
		s32Ret = RK_MPI_VI_GetChnFrame(0, 1, &stViFrame, -1);
    
    // 之后利用opencv-mobile，对数据帧进行格式转换和缩放
		if(s32Ret == RK_SUCCESS)
		{
      // 获取虚拟地址
			void *vi_data = RK_MPI_MB_Handle2VirAddr(stViFrame.stVFrame.pMbBlk);
			if(vi_data != RK_NULL)
			{
        // 使用cv::Mat对原始数据帧进行封装，并进行格式转换和缩放处理
				cv::Mat yuv420sp(disp_height + disp_height / 2, disp_width, CV_8UC1, vi_data);
				cv::Mat bgr(disp_height, disp_width, CV_8UC3);			
				cv::Mat model_bgr(model_height, model_width, CV_8UC3);			

				cv::cvtColor(yuv420sp, bgr, cv::COLOR_YUV420sp2BGR);

				cv::resize(bgr, model_bgr, cv::Size(model_width ,model_height), 0, 0, cv::INTER_LINEAR);	
        
        // memcpy到RKNN输入
				memcpy(rknn_app_ctx.input_mems[0]->virt_addr, model_bgr.data, model_width * model_height * 3);
        
        // 阻塞，该函数计算结束才会返回
        // od_results为推理结果
				inference_retinaface_model(&rknn_app_ctx, &od_results);

        // 利用rgn，将osd覆盖到venc的输入数据上，实现标注
				// ... RGN 处理逻辑 ...
				}		
			}
      // 释放帧资源
			s32Ret = RK_MPI_VI_ReleaseChnFrame(0, 1, &stViFrame);
		}
    // 暂停500ms
		usleep(500000);		
		// ... 清理 RGN 资源 ...
	}			
	return NULL;
}

2. `VIDEO_FRAME_INFO_S`原始数据帧分析

该线程操作的数据帧：VIDEO_FRAME_INFO_S

typedef struct rkVIDEO_FRAME_S {
    MB_BLK              pMbBlk; // 底层内存块句柄，该结构体本质上是对它的一层封装
    RK_U32              u32Width;
    RK_U32              u32Height;
    RK_U32              u32VirWidth;
    RK_U32              u32VirHeight;
    VIDEO_FIELD_E       enField;
    PIXEL_FORMAT_E      enPixelFormat;
    VIDEO_FORMAT_E      enVideoFormat;
    COMPRESS_MODE_E     enCompressMode;
    DYNAMIC_RANGE_E     enDynamicRange;
    COLOR_GAMUT_E       enColorGamut;

    RK_VOID            *pVirAddr[RK_MAX_COLOR_COMPONENT]; //虚拟地址

    RK_U32              u32TimeRef;
    RK_U64              u64PTS;

    RK_U64              u64PrivateData;
    RK_U32              u32FrameFlag;     /* FRAME_FLAG_E, can be OR operation. */
} VIDEO_FRAME_S;

typedef struct rkVIDEO_FRAME_INFO_S {
    VIDEO_FRAME_S stVFrame;
} VIDEO_FRAME_INFO_S;

三、毕设软件设计思路

也就是说，对于我毕业设计这个需求，我需要处理两种格式，一是 VENC 编码后的 H.264 视频流，二是从 VI 通道直接获取的原始数据帧。rkmpi 实际上已经做了一定程度的封装了，我应该在它封装的基础上进行管理，而不是拆开它们再自己封装。

1. 使用`std::share_ptr`和自定义删除器来封装数据帧

原始帧和编码流虽然接口不同，但是它们的使用都符合这么一个逻辑：每一次循环开始时，先获取，进行处理，再释放。对于线性场景，比如 VENC 编码后，交由 RTSP 进行推流，那么可以在循环中执行上述逻辑。

但是对于我毕设的需求来说，编码流会可能会同时用于 RTSP、WebRTC 推流和本地保存，那么上述逻辑就会变得复杂且难以处理。此时适合使用std::shared_ptr结合自定义删除器来进行处理，不同场景共享引用计数，只有当所有引用都结束后，再结束它的生命周期，进行析构（释放资源）。

以下是对编码流的处理，原始帧类似

/**
 * @brief 编码后的视频流智能指针 (VENC 输出)
 * 
 * 用于推流路径，H.264/H.265 编码后的数据包
 * 释放时自动调用 RK_MPI_VENC_ReleaseStream
 */
using EncodedStreamPtr = std::shared_ptr<VENC_STREAM_S>;

/**
 * @brief 从 VENC 通道获取编码流并包装为智能指针
 * 
 * @param chn_id VENC 通道 ID
 * @param timeout_ms 超时时间（毫秒），-1 表示阻塞等待
 * @return EncodedStreamPtr 成功返回流指针，失败返回 nullptr
 * 
 * @note 返回的智能指针在所有引用释放后会自动调用 RK_MPI_VENC_ReleaseStream
 * @note 内部会分配 VENC_PACK_S，也会在释放时一并清理
 */
inline EncodedStreamPtr acquire_encoded_stream(RK_S32 chn_id, RK_S32 timeout_ms = -1) {
    auto stream = new VENC_STREAM_S();
    stream->pstPack = new VENC_PACK_S();
    
    RK_S32 ret = RK_MPI_VENC_GetStream(chn_id, stream, timeout_ms);
    if (ret != RK_SUCCESS) {
        delete stream->pstPack;
        delete stream;
        return nullptr;
    }
    
    // 创建带自定义删除器的 shared_ptr
    return EncodedStreamPtr(stream, [chn_id](VENC_STREAM_S* p) {
        if (p) {
            RK_MPI_VENC_ReleaseStream(chn_id, p);
            delete p->pstPack;
            delete p;
        }
    });
}

零拷贝传递：不同场景实际上拿到的是同一个内存块地址，不会有内存拷贝。

多路共享：即使 RTSP 线程因为网络抖动卡住了，WebRTC 处理完后引用计数减 1，等到 RTSP 也处理完，引用计数归零，MPI 资源自动释放。

缺点就是：VENC的缓冲池是有限的，如果 RTSP 和 WebRTC 任何一方长时间持有指针不释放，会导致 VENC 模块因为拿不到空闲 Buffer 而阻塞或丢帧。后续应该引入丢帧机制或超时强制释放。如果某个消费者（如本地保存）处理太慢，应该主动reset()掉该路指针，宁可丢帧也不要阻塞采集前端。

2. 针对 AI 推理的原始帧处理 (VI → RKNN)

对于推理线程使用的原始数据帧，它的路径和所有权比较明确，毕竟同时只会有一个 AI 推理的线程存在。

使用GDB调试嵌入式设备

Fri, 30 Jan 2026 00:00:00 GMT

本文主要介绍在嵌入式 Linux 设备中使用 GDB 进行程序调试的方法。对于单片机开发，虽然可以使用 IDE 集成的调试功能，或通过 pyocd、openocd 配合 DAPLink 等硬件调试探针，但其核心原理与 GDB 调试是一致的。

环境准备

在进行调试前，需确保开发环境（如 Buildroot）已安装必要的调试组件。

1. 安装组件

通过 menuconfig 在根文件系统中启用以下工具：

gdb: 运行在开发板上的完整调试器。
gdbserver: 运行在开发板上的轻量化调试代理（推荐用于交叉调试）。

验证安装：

[root@luckfox root]# gdb --version
GNU gdb (GDB) 10.2
[root@luckfox root]# gdbserver --version
GNU gdbserver (GDB) 10.2

2. 编译配置

为了生成调试符号表并确保代码执行顺序与源码一致，必须在编译时开启 -g 参数并尽量禁用优化 -O0。

# 例如使用CMake进行构建时，设置参数
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0 -g")

常用调试途径对比

途径	实现方式	适用场景
GDB 命令行	直接在板端通过 GDB 运行程序或分析 Core Dump	快速定位崩溃点、打印堆栈、资源受限无法连接主机时
单步调试	通过 `gdbserver` 连接主机（如 VSCode）远程调试	逻辑分析、对照源码逐行排查、复杂业务流程调试

一、 GDB 命令行调试

1. 场景一：实时捕获（Live Debug）

针对可以稳定复现的程序崩溃（Segmentation fault）。

启动调试：
```
gdb ./your_app
```
常用交互命令：

命令	说明
`set args --config ./test.conf`	设置程序启动参数
`run` (r)	开始运行程序
`bt` (backtrace)	打印当前简略调用堆栈
`bt full`	打印堆栈及每一层函数的局部变量值
`thread apply all bt`	查看所有线程的堆栈（用于分析多线程死锁或崩溃）

2. 场景二：Core Dump 核心转储

用于处理偶发性崩溃，通过事后“尸检”定位问题。

启用生成：

ulimit -c unlimited  # 设置 core 文件大小不受限制

设置路径（可选）：

# 将 core 文件统一存放到 /tmp，并按进程名、PID 和时间命名
echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern

加载分析：

# 必须同时提供可执行文件和 core 文件
gdb ./your_app core

3. 场景三：深入崩溃点

操作	命令示例	功能描述
切换帧	`frame 2`	切换到堆栈中的指定层级（如切换回应用代码层）
查看源码	`list`	显示当前断点或崩溃点附近的源码
检查变量	`print *my_ptr`	打印变量值或解引用指针
检查状态	`info locals` / `info args`	打印当前函数的所有局部变量或输入参数
汇编调试	`disassemble`	在无源码时查看当前函数的汇编代码

二、远程单步调试

在嵌入式开发中，通常在板端运行 gdbserver（节省空间），在 Host 端（PC）使用带符号表的程序和源码进行可视化调试。

1. 板端操作

启动 gdbserver 并监听调试端口（如 1234）：

gdbserver :1234 ./my_app

2. Host 端配置 (VSCode)

需安装 C/C++ (cpptools) 扩展。创建 .vscode/launch.json：

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Luckfox Remote Debug",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/my_app", // 必须是带调试符号的可执行文件
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "/opt/luckfox-sdk/tools/linux/toolchain/.../arm-linux-gnueabihf-gdb", // 交叉编译器的 GDB 路径
            "miDebuggerServerAddress": "192.168.1.123:1234", // 板端 IP 和端口
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set Sysroot for Cross-Debugging",
                    "text": "set sysroot ${workspaceFolder}/buildroot/output/staging", // 关键：指定交叉编译系统库路径
                    "ignoreFailures": false
                }
            ]
        }
    ]
}

配置完成后，在 VSCode 中按 F5 即可进入图形化单步调试界面。

毕设日志（一） Luckfox RK_MPI示例视频流与AI推理链路分析

Fri, 30 Jan 2026 00:00:00 GMT

主要分析 luckfox_pico_rtsp_retinaface_osd例程，探讨其如何实现摄像头采集、NPU 推理、硬件编码及 RTSP 推流的完整链路。

::github{repo="LuckfoxTECH/luckfox_pico_rkmpi_example"}

1. 视频流链路概览

该程序在硬件层面上构建了两条并行的核心路径，通过 RK_MPI（Rockchip Media Process Interface）协调不同硬件模块（VI、VENC、NPU、RGN）的交互。

路径名称	数据流向	核心功能
推流路径	VI Chn0 → VENC → RTSP	负责视频采集、硬件 H.264 编码及网络传输
推理路径	VI Chn1 → CPU/NPU → RGN	负责获取原始帧、图像预处理、AI 推理及结果绘制

2. VI 模块初始化与格式选择

程序初始化了两个 VI 通道，分别进行推流与AI推理。

	// vi init
	vi_dev_init();
	vi_chn_init(0, width, height);
	vi_chn_init(1, width, height);

2.1 通道分配

通道 0：负责推流，直接绑定至编码器。
通道 1：负责 AI 推理，供用户态程序主动获取帧数据。

2.2 像素格式与配置

两个通道均设置为 RK_FMT_YUV420SP（即 NV12 格式）。采用 VI_V4L2_MEMORY_TYPE_DMABUF 以减少内存拷贝开销。

int vi_chn_init(int channelId, int width, int height) {
  int ret;
  int buf_cnt = 4;
  // VI init
  VI_CHN_ATTR_S vi_chn_attr;
  memset(&vi_chn_attr, 0, sizeof(vi_chn_attr));
  vi_chn_attr.stIspOpt.u32BufCount = buf_cnt;
  vi_chn_attr.stIspOpt.enMemoryType = VI_V4L2_MEMORY_TYPE_DMABUF; 
  vi_chn_attr.stSize.u32Width = width;
  vi_chn_attr.stSize.u32Height = height;
  vi_chn_attr.enPixelFormat = RK_FMT_YUV420SP;
  vi_chn_attr.enCompressMode = COMPRESS_MODE_NONE; 
  vi_chn_attr.u32Depth = 2; 
  ret = RK_MPI_VI_SetChnAttr(0, channelId, &vi_chn_attr);
  ret |= RK_MPI_VI_EnableChn(0, channelId);
  if (ret) {
    printf("ERROR: create VI error! ret=%d\n", ret);
    return ret;
  }
  return ret;
}

3. 推流通路 (VI Chn0 → VENC → RTSP)

推流路径实现了纯硬件链路，数据在底层驱动中通过 SYS_Bind 自动流转。

3.1 硬件绑定逻辑

通过 RK_MPI_SYS_Bind 将 VI 模块与 VENC 模块在内核层关联，避免了将原始 YUV 数据频繁拷贝到用户空间。

// bind vi to venc  
stSrcChn.enModId = RK_ID_VI;
stSrcChn.s32DevId = 0;
stSrcChn.s32ChnId = 0;
    
stvencChn.enModId = RK_ID_VENC;
stvencChn.s32DevId = 0;
stvencChn.s32ChnId = 0;

s32Ret = RK_MPI_SYS_Bind(&stSrcChn, &stvencChn);

3.2 编码与传输

硬件编码：VENC 接收到 NV12 数据，根据 RK_VIDEO_ID_AVC 配置进行 H.264 硬件压缩。
流获取：GetMediaBuffer 线程通过 RK_MPI_VENC_GetStream(0, &stFrame, -1) 阻塞式获取码流。
推流：调用 rtsp_tx_video 将 H.264 数据包发送至客户端。

4. AI 推理路径 (VI Chn1 → NPU)

推理路径涉及用户态的图像处理与 NPU 调度。

4.1 图像获取与预处理

获取数据：RetinaProcessBuffer 线程通过 RK_MPI_VI_GetChnFrame 从通道 1 获取 NV12 帧。
格式转换：利用 opencv-mobile 将 NV12 转换为 BGR。
尺寸缩放：调用 cv::resize 将图像适配模型输入的 $640 \times 640$ 尺寸。

4.2 NPU 任务调度

inference_retinaface_model 函数执行同步推理：CPU 调用后进入等待状态，直到 NPU 硬件完成计算并返回 od_results 结果。

5. OSD 叠加机制

OSD（On-Screen Display）并未修改原始图像内存，而是通过 RGN（Region）模块 实现。

原理：AI 推理得到的坐标结果被转化为 RGN 画布操作。
硬件合成：RGN 模块将线框作为叠加层，在进入 VENC 编码前由硬件自动合入视频帧。这保证了 RTSP 流中自带检测框。

6. 模块同步机制

监控对象	实现机制	关键函数/参数
VENC 编码完成	阻塞等待 (Blocking)	`RK_MPI_VENC_GetStream` 的 `s32MilliSec` 参数设为 `-1`
NPU 推理完成	同步调用 (Synchronous)	`inference_retinaface_model` 直至计算结束才返回
VI 数据就绪	循环轮询/阻塞	在推理线程中主动请求帧数据 `RK_MPI_VI_GetChnFrame`

这些阻塞其实可以接受，毕竟本来就是在对应单独线程中的操作，而不是同一个线程中的同步操作。这个线程阻塞了就是阻塞了，也没有优化的必要。

7. 关于毕业设计软件部分

在此基础上实现：WebRTC推流，显示在一个经过设计的网页里，通过该网页，可以动态调整模型类型（例如从yolov5切换为retainface）。

7.1 WebRTC

复用 venc 的码流即可，引入第三方WebRTC库，准备选择libdatachannel。

::github{repo="paullouisageneau/libdatachannel"}

7.2 AI模型动态切换

注意到luckfox提供的例程中，对于不同的AI模型，虽然推理、处理和绘制的逻辑有很大不同，但是都有几个实现这些功能的线程，也就是说，可以直接用线程隔离，而不是去做复杂的接口设计和动态切换。

这里牵扯到一个问题，就是RKNN模型的加载问题，如果只是简单的线程切换的话，所有RKNN模型在启动阶段就要加载进内存中，对于RV1106来说，这些内存占用不能忽视。

为此需要实现一个热加载逻辑，不仅仅要维护不同AI模型线程的切换，还有做到资源的管理，实现“先卸载、再加载”。

Arch Linux通过Distrobox运行Vivado

Mon, 26 Jan 2026 00:00:00 GMT

对于Arch Linux运行Vivado开发Zynq来说，一般会考虑KVM虚拟机安装对应版本的Ubuntu，但是抛开内存和性能损耗不谈，单单是USB设备挂载、NFS挂载等后续问题，就够麻烦了，而且老版本Ubuntu的GUI结合KVM难绷的图形性能（尤其是N卡，无法做到显卡直通和3D加速），对于使用Vivado这样的图形化界面来说非常难受。

这里选择使用 Distrobox 进行环境配置。它通过与宿主机共享内核和命名空间，让 Ubuntu 不再是隔离的虚拟系统，而是以“透明环境”的形式融入 Arch Linux。这种架构使 Vivado 可以直接调用宿主机的 NVIDIA 驱动进行硬件加速渲染，避免了 KVM 虚拟机中常见的界面卡顿和操作迟滞。同时，容器共享 /dev 设备节点和网络栈，使 JTAG 下载、Zynq 调试及 NFS 等网络服务无需额外配置即可使用，整体体验接近原生 Ubuntu LTS，大幅降低了环境折腾成本。

相比之下，Docker 更偏向应用级容器，默认权限受限，对 GUI 程序和硬件访问并不友好。在 Vivado 这类重度依赖图形界面与外设的开发场景下，Docker 往往需要额外处理显示转发、设备映射和权限问题，配置复杂且稳定性不足，更适合作为自动化构建或批处理工具，而非日常交互式开发环境。

使用环境：Arch Linux、KED桌面、Wayland、Nvidia独立显卡

既然Wayland和n卡都能跑通，其他环境只会更方便

一、通过Distrobox安装Ubuntu20.04

安装和配置Distrobox

代理相关的不再赘述

优先选择podman

sudo pacman -S podman distrobox

创建和启动容器，并初始化

distrobox create -n fpga-dev --image ubuntu:20.04

# 进入容器
distrobox enter fpga-dev

distrobox容器会继承宿主机的shell设置（比如oh-my-zsh）和/dev，可谓相当方便

进入ubuntu容器后，安装需要的软件

# 更新源并安装 Vivado 必需的依赖和常用工具
sudo apt update
sudo apt install -y libtinfo5 libncurses5 libx11-6 libxrender1 libxtst6 libxi6 libglib2.0-0 build-essential bc locales git vim wget curl libxft2 libfontconfig1 libdbus-1-3

# 修正 Ubuntu 的 dash 问题（Petalinux 强依赖 bash）
sudo dpkg-reconfigure dash # 弹窗选择 No

二、下载和安装Vivado2020

下载网址，下载时注意关闭代理，不然四五十GB挺肉疼的

解压与安装

tar -xzf Xilinx_Unified_2020.2.tar.gz

cd Xilinx_Unified_2020.2_1118_1232 

# 注意是在宿主机桌面distrobox的ubuntu终端里执行，不能是ssh的终端里
sudo ./xsetup

根据引导一步步安装

选择Vitis

对于zynq7010/7020的话就是选Zynq-7000，我这里顺带安装一下Artix-7，未来可能会用

三、启动Vivado

实测直接启动后会白屏，搜索得知需要添加一个环境变量

Linux下安装Vivado打开后空白屏的解决方案

# 可以添加到宿主机的~/.bashrc或者~/.zshrc里
export _JAVA_AWT_WM_NONREPARENTING=1

# 根据安装时的具体位置
source /tools/Xilinx/Vivado/2020.2/settings64.sh

# 启动Vivado的图形化界面
vivado

结果如图：

在 Wayland (KDE Plasma) 环境下配置 Sunshine

Sat, 24 Jan 2026 00:00:00 GMT

在KDE Plasma (Wayland) 以及 NVIDIA 独立显卡环境下配置 Sunshine 服务。

::github{repo="LizardByte/Sunshine"}

环境

操作系统: Arch Linux
桌面环境: KDE Plasma (Wayland)
显卡: NVIDIA 独立显卡（需确保已安装 nvidia 驱动）

一、安装 Sunshine

使用 AUR 助手安装 Sunshine 软件包（其他系统去GitHub仓库release下载对应安装包）：

# 使用 yay 安装
yay -S sunshine

二、配置权限与输入环境

为了让 Sunshine 能够捕获输入设备并正常工作，需要配置 uinput 权限。

1. 创建 udev 规则

创建规则文件以允许 input 组访问 uinput 设备：

# 创建规则文件
echo 'KERNEL=="uinput", GROUP="input", MODE="0660", OPTIONS+="static_node=uinput"' | sudo tee /etc/udev/rules.d/60-sunshine.rules

# 确保当前用户在 input 用户组中
sudo usermod -aG input $USER

2. 设置捕获权限

Sunshine 需要 cap_sys_admin 权限来执行特定的屏幕抓取操作：

sudo setcap cap_sys_admin+ep $(readlink -f $(which sunshine))

三、检查环境依赖

在 Wayland 环境下，Sunshine 依赖 xdg-desktop-portal 来实现屏幕捕获。

检查项	命令	说明
Portal 插件	`pacman -Qs xdg-desktop-portal-kde`	确保安装了针对 KDE 的 Portal 接口实现
KMS 状态	`nvidia-smi`	确保加载了Nvidia显卡驱动

四、初始启动与配置

首次手动启动:

在 KDE 桌面会话内的终端（如 Konsole）中输入 sunshine 启动。注意：请勿通过远程 SSH 终端执行此操作，否则可能无法正确关联到当前的图形会话。
访问 Web UI:

打开浏览器访问 https://localhost:47990。
完成向导:

根据页面提示设置用户名、密码并完成基础编码器配置（建议选择 NVENC）。

五、配置 Sunshine 为守护进程

使用 User 模式 的 Systemd 服务可以确保 Sunshine 在用户登录后自动访问图形和音频服务。

1. 服务管理命令

AUR 提供的软件包通常已内置服务文件。

操作类型	命令
启动服务	`systemctl --user start sunshine`
设置开机自启	`systemctl --user enable sunshine`
查看实时日志	`journalctl --user -u sunshine -f`
停止服务	`systemctl --user stop sunshine`

2. 注意事项

安全性: 用户模式服务比系统级服务更安全，且能更好地处理环境变量。
日志排查: 如果无法连接，请使用 journalctl 命令检查是否有关于 vaapi 或 cuda 的报错。

C++学习笔记：std::unique_ptr自定义删除器

Mon, 15 Dec 2025 00:00:00 GMT

一、直接在`std::unique_ptr`中调用自定义删除器

代码：

#include <iostream>
#include <memory>

// 这里有一个c-style的资源，清理它需要手动
// 这个XPacket是外部提供的，不好进行重构（添加构造和析构函数）
struct XPacket {
    unsigned char* data = nullptr; //一个需要手动释放的堆内存指针
    int size = 0;
};

// 专门创建一个PacketDelete类来进行XPacket的清理
class PacketDelete {
public:
    // 重载了()
    void operator() (XPacket* p) const {
        std::cout << "call PacketDelete()" << std::endl;
        // 在这里释放XPacket的资源，或者调用资源清理的接口
        std::free(p->data);
        delete p;
    }
};

int main() {
    // 自定义空间删除方法，希望智能指针离开作用域后调用指定的资源清理方法
  	// 而不是单纯的结束XPacket的生命周期（它是一个c-style结构体，没有专门的析构函数进行资源清理）
    std::unique_ptr<XPacket, PacketDelete> p1 (new XPacket);

   
    // std::unique_ptr<XPacket, PacketDelete> p3 (new XPacket);
    // p3.get_deleter()(p2.get());
  
  	// std::make_unique()不支持自定义删除器，只能用std::unique_ptr<>来创建
    // auto p2 = std::make_unique<XPacket, PacketDelete>();
    return 0;
}

解析

1、`PacketDelete`类的函数调用运算符

class PacketDelete {
public:
    // 重载了()
    void operator() (XPacket* p) const {
        std::cout << "call PacketDelete()" << std::endl;
        delete p->data;
        delete p;
    }
};

这是一个函数调用运算符 (Function Call Operator)，俗称 仿函数 (Functor)。它使得 PacketDelete 类的对象可以像函数一样被调用。

2、`std::unique_ptr`调用自定义删除器

std::unique_ptr<XPacket, PacketDelete> p1 (new XPacket);

当 p1 智能指针离开作用域时，它会执行以下步骤：

获取它持有的 XPacket* 裸指针。
获取它的删除器对象（类型为 PacketDelete）。
调用删除器对象的 operator()，并将裸指针作为参数传入：p2.get_deleter()(p2.get())。

二、引入 Lambda 表达式作为删除器

代码：

#include <iostream>
#include <memory>

struct XPacket {
    unsigned char* data = nullptr;
    int size = 0;
};

int main() {
		auto lambda_deleter = [](XPacket* p) {
        std::cout << "call Lambda Deleter()" << std::endl;
        std::free(p->data);
        delete p;
    };

    // 使用decltype推断lambda的类型，作为模板参数
    std::unique_ptr<XPacket, decltype(lambda_deleter)> p2 (new XPacket, lambda_deleter);
    return 0;
}

解析

一、与类类型删除器 (`PacketDelete`)的区别

类类型删除器 (PacketDelete)

std::unique_ptr<XPacket, PacketDelete> p1 (new XPacket); // 只需要传入指针

X11转发

Sun, 30 Nov 2025 00:00:00 GMT

X11 Forwarding 配置 (Ubuntu -> macOS)

本文档记录了如何通过 SSH 将 Ubuntu（X Client）上的图形界面应用转发至 macOS（X Server）上显示。主要适用于容器环境或远程 SSH 连接场景。

核心概念

在 X Window System 架构中，角色定义如下：

角色	操作系统	职责
X Client	Ubuntu	运行应用程序（计算端）
X Server	macOS	提供显示服务和输入设备（显示端）

1. Server 端配置 (macOS)

macOS 没有原生 X Server，需安装 XQuartz 作为替代。

1.1 安装 XQuartz

brew install --cask xquartz

注意：安装完成后，必须 注销并重新登录 或 重启电脑，以使 $DISPLAY 环境变量生效。

1.2 配置权限

启动 XQuartz。
进入 偏好设置 (Preferences) -> 安全性 (Security)。
勾选 "Allow connections from network clients" (允许来自网络客户端的连接)。

2. Client 端配置 (Ubuntu)

2.1 安装必要组件

安装 X11 认证工具、SSH 服务及必要的渲染库：

sudo apt update
sudo apt install xauth openssh-server
sudo apt install libxrender1 libxtst6 libxi6

2.2 修改 SSH 配置

编辑 /etc/ssh/sshd_config 文件，确保以下配置项未被注释且设置为正确的值：

X11Forwarding yes
X11DisplayOffset 10

2.3 重启 SSH 服务

sudo systemctl restart ssh

3. 建立连接与验证

3.1 发起 SSH 连接

使用带有 X11 转发参数的命令连接到 Ubuntu：

# 格式: ssh -Y -C user@ip
ssh -Y -C user@192.168.137.121

参数说明：

参数	含义	作用
`-Y`	Trusted X11 Forwarding	启用受信任的 X11 转发（解决部分权限问题）
`-C`	Compression	开启数据压缩，优化传输性能

3.2 验证测试

连接成功后，在 SSH 终端中启动图形界面应用（如 xeyes）进行测试：

xeyes

预期结果： macOS 端的 XQuartz 会自动被唤起，并在桌面上显示一双跟随鼠标移动的眼睛，即表示 X11 转发配置成功。

Frp内网穿透到云服务器

Fri, 28 Nov 2025 00:00:00 GMT

把本地服务器的端口映射到公网服务器，通过公网服务器ip地址+端口来访问内网

具体为：

其中192.168.31.29为本地服务器内网ip

公网服务器（Frp服务端）

下载amd64/Linux的frp

wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_linux_amd64.tar.gz

解压

tar -zxvf frp_0.65.0_linux_amd64.tar.gz

把frpc复制到/usr/local/bin

cd frp_0.65.0_linux_amd64/

sudo cp frps /usr/local/bin/

设置配置文件

sudo mkdir -p /etc/frp

sudo vim /etc/frp/frps.toml

填入以下内容

auth.token和webServer.password要配置的足够安全，不然有安全隐患。

# /etc/frp/frps.toml

# frp 服务端监听的控制端口，用于和客户端建立连接
bindPort = 7000

# 鉴权机制 
auth.method = "token"
auth.token = "password" 

# FRP Dashboard 面板，方便监控连接数和流量
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "password"

创建和配置/etc/systemd/system/frps.service

# /etc/systemd/system/frps.service

[Unit]
Description=Frp Server Service
After=network.target

[Service]
Type=simple
User=root
Restart=on-failure
RestartSec=5s
# 注意配置文件的路径
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml

[Install]
WantedBy=multi-user.target

启动和检查状态

sudo systemctl enable --now frps

systemctl status frps

云服务器放行端口：

公网防火墙 (安全组)：在服务器的控制台的安全组 中放行以下端口：

7000 (FRP 通信)
8000 (映射后的 WS)
8002 (映射后的 Web)
8003 (映射后的 Vision)

以及确保云服务器中的对应端口没有被占用

可以通过服务器ip和7500端口进入控制面板

内网服务器（Frp客户端）

同样的下载和解压Frp，把frpc复制到/usr/local/bin

sudo cp frpc /usr/local/bin/

创建配置文件

sudo mkdir -p /etc/frp

sudo vim /etc/frp/frpc.toml

# /etc/frp/frpc.toml

# 公网服务器 IP
serverAddr = "x.x.x.x"
serverPort = 7000

# 鉴权 Token (必须与服务端 frps.toml 一致)
auth.method = "token"
auth.token = "password"

# --- 隧道 1: WebSocket API ---
[[proxies]]
name = "xiaozhi-ws-8000"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8000
remotePort = 8000
transport.useEncryption = true
transport.useCompression = true

# --- 隧道 2: Web 管理 & OTA ---
[[proxies]]
name = "xiaozhi-web-8002"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8002
remotePort = 8002
transport.useEncryption = true
transport.useCompression = true

# --- 隧道 3: 视觉分析接口 ---
[[proxies]]
name = "xiaozhi-vision-8003"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8003
remotePort = 8003
transport.useEncryption = true
transport.useCompression = true

对应内网服务器的8000、8002、8003端口

临时测试

frpc -c frpc.toml

参考云服务器配置，设置为systemd守护进程并启动运行

创建和配置/etc/systemd/system/frpc.service

# /etc/systemd/system/frpc.service

[Unit]
Description=Frp Client Service
After=network.target

[Service]
Type=simple
User=root
Restart=on-failure
RestartSec=5s
# 注意配置文件的路径
ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.toml

[Install]
WantedBy=multi-user.target

启动和检查状态

sudo systemctl enable --now frpc

systemctl status frpc

理论上实现的效果

假设公网服务器ip地址为xxx.xxx.xxx.xxx，浏览器输入http://xxx.xxx.xxx.xxx:8002即可进入AI对话服务端的web界面，其他以此类推。

后面再在公网服务器上部署 Nginx ，把形如http://xxx.com/xiaozhi/ota/到地址指向指定端口。

rkdeveloptool

Fri, 21 Nov 2025 00:00:00 GMT

rk开源的烧录工具，可以用于烧录整个img镜像，例如armbian的镜像

::github{repo="rockchip-linux/rkdeveloptool"}

建议自行编译最新版本的，注意配置udev规则99-rockchip.rules（GitHub仓库里下载）

前提：设备进入maskrom模式

sudo rkdeveloptool ld

列出进入maskrom模式的设备

一、初始化Loader

初始化DRAM，刷入类似miniloader.bin的文件

包含了一段 SPL (Secondary Program Loader) 代码，它的主要职责就是初始化内存时序

sudo ./rkdeveloptool db rk35xx_spl_loader.bin

二、刷入镜像

sudo ./rkdeveloptool wl 0 system_image.img

三、重启设备

sudo ./rkdeveloptool rd

Fedora43使用KVM虚拟机安装Ubuntu

Thu, 30 Oct 2025 00:00:00 GMT

Fedora 43 KVM 虚拟机安装 Ubuntu 记录

本文档记录在 Fedora 43 宿主机上使用 KVM 部署 Ubuntu (22.04/18.04) 虚拟机的完整流程，涵盖环境搭建、虚拟机创建、资源共享、网络桥接及快照管理。

1. 环境准备与虚拟化支持

首先需要在宿主机开启虚拟化支持并安装必要的管理工具。

1.1 安装 KVM 相关组件

# 安装虚拟化组包
sudo dnf groupinstall "Virtualization"

# 安装安装工具与查看器
sudo dnf install virt-install virt-viewer

1.2 启动服务

sudo systemctl enable --now libvirtd

2. 构建虚拟机

2.1 准备镜像与目录

建议将 ISO 镜像移动到 libvirt 默认目录以避免权限问题。

# 创建虚拟机镜像存放目录 (可选，默认在 /var/lib/libvirt/images/)
sudo mkdir -p /var/lib/libvirt/images

# 移动 ISO 镜像
sudo mv /home/hao/ubuntu-22.04.5-desktop-amd64.iso /var/lib/libvirt/images/

2.2 执行安装命令

使用 virt-install 创建名为 vivado-lab 的虚拟机，8GB内存，8个处理器逻辑核心，500GB存储空间。按需修改，核心数和内存都可以后期调整

# 预先分配足够的磁盘空间
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/vivado-lab.qcow2 500G

# 确保所有者正确 (libvirt/qemu 进程通常运行在 qemu 用户下)
sudo chown qemu:qemu /var/lib/libvirt/images/vivado-lab.qcow2

# 恢复默认上下文
sudo restorecon -Rv /var/lib/libvirt/images/

# 再次确认关闭 SELinux (临时测试用，排除干扰)
sudo setenforce 0

sudo virt-install \
  --name vivado-lab \
  --memory 8192 \
  --vcpus 8 \
  --cpu host-model \
  --disk path=/var/lib/libvirt/images/vivado-lab.qcow2,bus=virtio,format=qcow2 \
  --cdrom /var/lib/libvirt/images/ubuntu-22.04.5-desktop-amd64.iso \
  --os-variant ubuntu22.04 \
  --network network=default,model=virtio \
  --graphics spice,listen=none,gl.enable=no \
  --video virtio \
  --channel spicevmc \
  --check disk_size=off \
  --noautoconsole

参数说明：

参数	说明
`--cpu host-passthrough`	透传宿主机 CPU 特性，性能最佳
`--graphics spice`	使用 SPICE 图形协议
`--disk ...`	指定磁盘路径、大小、总线类型 (virtio)
`--noautoconsole`	自动后台安装，不直接弹出控制台

2.3 访问与管理

# 通过 virt-viewer 进入虚拟机界面
sudo virt-viewer --attach vivado-lab

# 打开图形化管理器
sudo virt-manager

常用管理命令：

# 关闭虚拟机
sudo virsh shutdown vivado-lab

# 开启虚拟机
sudo virsh start vivado-lab

# 查看所有虚拟机状态
sudo virsh list --all

# 删除虚拟机
sudo virsh undefine vivado-lab --remove-all-storage --delete-snapshots --nvram

3. 配置宿主机与虚拟机共享目录 (VirtioFS)

将宿主机的 /var/lib/libvirt/share 目录挂载到虚拟机的 /mnt/share。

3.1 宿主机目录权限配置

必须正确设置目录的所有者和 SELinux 上下文，否则虚拟机无法访问。

# 1. 创建目录
sudo mkdir -p /var/lib/libvirt/share

# 2. 设置归属 (移交给 qemu 用户)
sudo chown qemu:qemu /var/lib/libvirt/share

# 3. 设置 SELinux 上下文 (放行 virt 访问)
sudo chcon -t virt_image_t /var/lib/libvirt/share

3.2 编辑虚拟机 XML 配置

使用 sudo virsh edit vivado-lab 修改配置文件。

步骤 1：添加 Filesystem 设备

在 <devices> 段落下添加：

<filesystem type='mount' accessmode='passthrough'>
  <driver type='virtiofs'/>
  <source dir='/var/lib/libvirt/share'/>
  <target dir='host_share'/>
</filesystem>

步骤 2：开启共享内存

在 <domain> 段落下（通常在 CPU 配置附近）添加或修改：

<domain type='kvm'>
  ...
  <memoryBacking>
    <source type='memfd'/>
    <access mode='shared'/>
  </memoryBacking>
  ...
</domain>

3.3 虚拟机内部挂载

启动虚拟机后，在内部执行：

sudo mkdir /mnt/host

# 挂载共享目录 (target tag 为 host_share)
sudo mount -t virtiofs host_share /mnt/host

4. 网络配置 (桥接模式)

将宿主机物理网卡桥接到 br0，并让虚拟机连接该网桥，使其获得独立局域网 IP。

4.1 宿主机创建网桥

物理有线网卡名称为 enp6s0f4u1u4。

# 1. 创建网桥从属连接
sudo nmcli con add type bridge-slave ifname enp6s0f4u1u4 master br0

# 2. 删除旧的有线连接 (防止冲突)
sudo nmcli con delete "有线连接 1"

# 3. 激活网桥
sudo nmcli con up br0

4.2 虚拟机网络设置

在 virt-manager 中将虚拟机的网络接口修改为 桥接设备 -> br0，或编辑 XML 将 interface type 改为 bridge。

5. 虚拟机基础服务配置

5.1 配置 APT 镜像源 (清华源)

加速软件安装与更新。

sudo sed -i.bak 's/cn.archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list && \
sudo sed -i 's/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list && \
sudo apt update

5.2 安装 SSH 服务

sudo apt install openssh-server

# 启动并设置开机自启
sudo systemctl enable --now ssh

# 检查状态
sudo systemctl status ssh

6. Tailscale 子网路由配置 (宿主机)

配置宿主机作为 Tailscale 子网路由器，转发 192.168.137.0/24 网段流量。

6.1 开启内核转发

编辑 /etc/sysctl.d/99-tailscale.conf：

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

应用配置：

sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

6.2 广播路由

# 启动 Tailscale 并广播子网
sudo tailscale up --advertise-routes=192.168.137.0/24

验证：外部节点 Ping 虚拟机 IP (e.g., 192.168.137.226) 应正常连通。

7. 虚拟机快照管理

使用 virsh snapshot 系列命令管理系统状态。

7.1 创建快照

创建完整系统快照 (Live Snapshot)

保留当前运行状态 (内存+磁盘)。

sudo virsh snapshot-create-as \
  --domain vivado-lab \
  --name "snap-20251122-base" \
  --description "Base install with network and ssh configured"

创建关机状态快照 (Disk-only)

占用空间小，适合纯磁盘备份。

# 先关闭虚拟机
sudo virsh shutdown vivado-lab

# 创建快照
sudo virsh snapshot-create-as \
  --domain vivado-lab \
  --name "env-ready-2025" \
  --description "Setup with SSH, and Tsinghua Mirror" \
  --disk-only \
  --atomic

7.2 查看与管理快照

# 列出所有快照
sudo virsh snapshot-list --domain vivado-lab

# 查看快照详细信息
sudo virsh snapshot-info --domain vivado-lab --snapshotname "env-ready-2025"

# 恢复到指定快照
sudo virsh snapshot-revert --domain vivado-lab --snapshotname "env-ready-2025"
# 恢复并暂停 (便于检查)
# sudo virsh snapshot-revert --domain vivado-lab --snapshotname "env-ready-2025" --paused

# 删除快照
sudo virsh snapshot-delete --domain vivado-lab --snapshotname "snap-20251122-base"

Conan+CMake基本编译流程

Tue, 21 Oct 2025 00:00:00 GMT

Conan+CMake基本编译流程

本地编译

1. Conan 安装依赖

首先，使用 Conan 安装项目所需的第三方包。Conan 会根据构建类型（Debug/Release）将生成的文件放置在不同的目录中。

默认情况下，Conan 会创建 build/Release/generators 目录来存放生成文件。
```
conan install . --build=missing
```

可以明确指定构建类型，例如 Debug。

conan install . --build=missing -s build_type=Debug

--output-folder 参数可以指定输出目录，但通常不是必需的，因为 Conan 会根据配置自动管理路径。

2. CMake 配置与编译

Conan 在安装依赖后，会自动生成一个 CMake 预设文件 (CMakeUserPresets.json)，其中包含了配置和编译所需的全部信息。因此，推荐直接使用预设来简化操作。

使用 CMake 预设（推荐）

配置 CMake

使用 conan-debug 或 conan-release 预设来配置项目。

# 配置 Debug 版本
cmake --preset conan-debug

# 配置 Release 版本
cmake --preset conan-release

编译

同样使用预设来执行编译。

# 编译 Debug 版本
cmake --build --preset conan-debug

# 编译 Release 版本
cmake --build --preset conan-release

手动配置

如果不使用预设，则需要手动指定工具链文件和构建类型。

配置 CMake

# 配置 Release 版本
cmake -S . -B build/Release -G Ninja \
      -DCMAKE_TOOLCHAIN_FILE=build/Release/generators/conan_toolchain.cmake \
      -DCMAKE_BUILD_TYPE=Release
      
# 配置 Debug 版本
cmake -S . -B build/Debug -G Ninja \
      -DCMAKE_TOOLCHAIN_FILE=build/Debug/generators/conan_toolchain.cmake \
      -DCMAKE_BUILD_TYPE=Debug

编译

# 编译 Release 版本
cmake --build build/Release

# 编译 Debug 版本
cmake --build build/Debug

交叉编译

1. 创建 Profile 文件

首先，需要为目标平台创建一个 Conan Profile 文件。例如，为 aarch64 架构创建一个 profiles/aarch64_profile 文件。

[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.version=15.2
compiler.libcxx=libstdc++11
compiler.cppstd=20

[conf]
# 告诉 Conan 加载我们自定义的 CMake 工具链文件
# 使用 tools.cmake.cmaketoolchain:user_toolchain 来指定
# 注意: ${profile_dir} 是 Conan 变量，但实践中建议使用绝对路径以确保正确识别
tools.cmake.cmaketoolchain:user_toolchain=["/path/to/your/project/cmake/aarch64-toolchain.cmake"]

在对应的 .cmake 工具链文件中，你需要设置交叉编译所需的编译器、系统根目录等环境变量。

2. 执行编译流程

交叉编译的流程与本地编译非常相似，区别在于需要在 conan install 命令中通过 -pr:h 参数指定 Host 平台的 Profile 文件。

Conan 安装依赖

conan install . --build=missing -s build_type=Debug -pr:h profiles/aarch64_profile

配置 CMake

Conan 同样会生成适用于交叉编译的 CMake 预设。
```
cmake --preset conan-debug
cmake --preset conan-release
```

编译

cmake --build --preset conan-debug
cmake --build --preset conan-release

pyocd调用flm格式的下载算法

Sun, 03 Aug 2025 00:00:00 GMT

pyocd 调用 FLM 格式的外部下载算法

记录如何通过 pyocd 调用 Keil 使用的 .FLM 格式外部下载算法，将程序烧录到 STM32H7 系列微控制器的 QSPI Flash 中。

::github{repo="haoyn231/STM32H750XBH6_CMake_Template"}

项目背景

项目	内容
开发板	反客STM32H750XHB6
参考工程	Peakors/STM32H750XBH6_Template
下载算法	`FK750M6_XBH6_V0.FLM` (由开发板资料提供)
测试环境	Fedora 42 (经验可跨平台通用)

前置依赖

确保已安装以下工具链：

pyocd
cmake
ninja 或 make
arm-none-eabi-gcc

编译流程

# 生成 Ninja/Make 构建文件
cmake -S . -B build -G Ninja

# 执行编译
cmake --build build/

原理说明

通过在项目根目录创建 pyocd_user.py 脚本，可以自定义 pyOCD 的连接行为。pyOCD 在启动时会自动检测并加载该文件。

我们在脚本中定义一个 will_connect 函数，该函数会在 pyOCD 连接目标板之前被调用。通过这个函数，我们可以向 pyOCD 的内存地图中添加外部 Flash 的信息（如 QSPI Flash），并指定其使用的 .FLM 下载算法。

这种机制使得 pyOCD 能够在不修改内置目标支持的情况下，扩展对外部存储器的烧录能力。

1. 目录结构

将下载算法文件 FK750M6_XBH6_V0.FLM 存放到项目下的 .config 文件夹中。
在项目根目录创建 pyocd_user.py 文件。

2. pyocd_user.py 脚本

# pyocd_user.py

from pyocd.core.memory_map import FlashRegion
import logging

# --- 定义外部 QSPI Flash 的参数 ---
FLM_FILE = ".config/FK750M6_XBH6_V0.FLM" # 存放下载算法的相对路径
QSPI_FLASH_START = 0x90000000
QSPI_FLASH_SIZE = 32 * 1024 * 1024
QSPI_FLASH_BLOCKSIZE = 0x1000

def will_connect(board):
    """
    这是一个 pyOCD 代理函数，会在连接前被自动调用。
    
    """
    target = board.target
    
    # 定义外部 Flash 区域
    external_flash = FlashRegion(
        name="qspi_flash",
        start=QSPI_FLASH_START,
        length=QSPI_FLASH_SIZE,
        blocksize=QSPI_FLASH_BLOCKSIZE,
        is_boot_memory=False,
        flm=FLM_FILE
    )
    
    # 将其添加到内存地图
    target.memory_map.add_region(external_flash)
    
    logging.info(f"用户脚本：成功添加外部 QSPI Flash 区域 '{external_flash.name}'")

具体定义参考/home/hao/.local/lib/python3.13/site-packages/pyocd/core/memory_map.py（pyocd安装路径）

烧录指令

使用以下指令将编译生成的 .bin 文件烧录到 QSPI Flash 的起始地址 0x90000000。

--target stm32h750xx：指定目标芯片型号。
-O connect_mode=under-reset：设置连接模式为复位下连接。
./build/STM32H750XBH6_Template.bin@0x90000000：指定固件路径和烧录地址。

pyocd flash --target stm32h750xx -O connect_mode=under-reset ./build/STM32H750XBH6_Template.bin@0x90000000

日志参考

1. 简洁版日志

❯ pyocd flash --target stm32h750xx -O connect_mode=under-reset ./build/STM32H750XBH6_Template.bin@0x90000000
0000447 I Loading /home/hao/projects/stm32_projects/STM32H750XBH6/CMake/STM32H750XBH6_Template/build/STM32H750XBH6_Template.bin at 0x90000000 [load_cmd]
[==================================================] 100%
0002722 I Erased 65536 bytes (1 sector), programmed 65536 bytes (8 pages), skipped 0 bytes (0 pages) at 28.14 kB/s [loader]

2. 详细版日志 (-v 参数)

❯ pyocd flash --target stm32h750xx -v -O connect_mode=under-reset ./build/STM32H750XBH6_Template.bin@0x90000000
0000346 I Target type is stm32h750xx [board]
0000349 I 用户脚本：成功添加外部 QSPI Flash 区域 'qspi_flash' [pyocd_user]
0000349 I Asserting reset prior to connect [coresight_target]
0000352 I DP IDR = 0x6ba02477 (v2 rev6) [dap]
0000366 I CR: 0x0070003f [target_STM32H750xx]
0000370 I AHB-AP#0 IDR = 0x84770001 (AHB-AP var0 rev8) [discovery]
0000373 I AHB-AP#1 IDR = 0x84770001 (AHB-AP var0 rev8) [discovery]
0000376 I APB-AP#2 IDR = 0x54770002 (APB-AP var0 rev5) [discovery]
0000379 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00fe000 (designer=020:ST part=450) [rom_table]
0000381 I [0]<e00ff000:ROM class=1 designer=43b:Arm part=4c7> [rom_table]
0000381 I   AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b:Arm part=4c7) [rom_table]
0000383 I   [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0000385 I   [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0000386 I   [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=00e> [rom_table]
0000387 I   [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0000389 I [1]<e0041000:ETM M7 class=9 designer=43b:Arm part=975 devtype=13 archid=4a13 devid=0:0:0> [rom_table]
0000391 I [2]<e0043000:CTI CS-400 class=9 designer=43b:Arm part=906 devtype=14 archid=0000 devid=40800:0:0> [rom_table]
0000393 I APB-AP#2 Class 0x1 ROM table #0 @ 0xe00e0000 (designer=020:ST part=450) [rom_table]
0000396 I [2]<e00e3000:SWO CS-400 class=9 designer=43b:Arm part=914 devtype=11 archid=0000 devid=ea0:0:0> [rom_table]
0000398 I [3]<e00e4000:Trace Funnel CS-400 class=9 designer=43b:Arm part=908 devtype=12 archid=0000 devid=32:0:0> [rom_table]
0000399 I [4]<e00e5000:TSGEN class=15 designer=43b:Arm part=101> [rom_table]
0000400 I [5]<e00f0000:ROM class=1 designer=020:ST part=001> [rom_table]
0000401 I   APB-AP#2 Class 0x1 ROM table #1 @ 0xe00f0000 (designer=020:ST part=001) [rom_table]
0000404 I   [0]<e00f1000:CTI CS-400 class=9 designer=43b:Arm part=906 devtype=14 archid=0000 devid=40800:0:0> [rom_table]
0000406 I   [2]<e00f3000:Trace Funnel CS-400 class=9 designer=43b:Arm part=908 devtype=12 archid=0000 devid=34:0:0> [rom_table]
0000408 I   [3]<e00f4000:ETF class=9 designer=43b:Arm part=961 devtype=32 archid=0000 devid=380:0:0> [rom_table]
0000410 I   [4]<e00f5000:TPIU CS-400 class=9 designer=43b:Arm part=912 devtype=11 archid=0000 devid=a0:0:0> [rom_table]
0000415 I CPU core #0: Cortex-M7 r1p1, v7.0-M architecture [cortex_m]
0000415 I   Extensions: [DSP, FPU, FPU_DP, FPU_V5, MPU] [cortex_m]
0000415 I   FPU present: FPv5-D16-M [cortex_m]
0000416 I 4 hardware watchpoints [dwt]
0000419 I 8 hardware breakpoints, 1 literal comparators [fpb]
0000431 I Deasserting reset post connect [coresight_target]
0000433 I Creating flash algo for region qspi_flash from: /home/hao/projects/stm32_projects/STM32H750XBH6/CMake/STM32H750XBH6_Template/.config/FK750M6_XBH6_V0.FLM [flm_region_builder]
0000448 I Loading /home/hao/projects/stm32_projects/STM32H750XBH6/CMake/STM32H750XBH6_Template/build/STM32H750XBH6_Template.bin at 0x90000000 [load_cmd]
[==================================================] 100%
0002723 I Erased 65536 bytes (1 sector), programmed 65536 bytes (8 pages), skipped 0 bytes (0 pages) at 28.14 kB/s [loader]

实现效果

Bootloader 日志 (运行于片内 Flash)
- 程序启动后，首先运行片内 Flash 中的 Bootloader，通过串口打印启动日志。
- Bootloader 日志截图（乱码系中文编码问题）
主程序日志 (运行于外部 QSPI Flash)
- Bootloader 跳转到 QSPI Flash 中执行主程序，主程序通过 USB 虚拟串口打印运行日志。
- USB 虚拟串口日志截图

串口波特率115200

使用docker编译openwrt

Sat, 02 Aug 2025 00:00:00 GMT

介绍如何利用 Docker 环境编译 OpenWrt 固件，以实现编译环境的隔离和一致性。

前提条件

类别	要求
网络环境	良好的科学上网环境，确保可以顺畅访问 GitHub、OpenWrt 源码等国外资源。
软件工具	在宿主机上预先安装好 `Git` 和 `Docker` (包括 `docker-compose`)。
个人能力	具备基本的 Linux 命令行操作和解决问题的能力。

环境搭建

1. Dockerfile

创建一个 Dockerfile 文件，用于定义编译环境镜像。该镜像基于 Ubuntu 22.04，安装了所有 OpenWrt 官方推荐的编译依赖，并创建了一个名为 builder 的非 root 用户以增强安全性。

# 使用官方推荐的 Ubuntu 22.04 LTS 作为基础镜像
FROM ubuntu:22.04

# 设置环境变量，避免在包安装过程中出现交互式提示
ENV DEBIAN_FRONTEND=noninteractive

# 一次性更新软件源并安装 OpenWrt 编译所需的所有依赖包
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    # 编译工具链
    build-essential \
    clang \
    flex \
    bison \
    g++ \
    gawk \
    gcc-multilib \
    g++-multilib \
    # 文本和版本控制工具
    gettext \
    git \
    subversion \
    # 核心库和开发头文件
    libncurses5-dev \
    libssl-dev \
    zlib1g-dev \
    # Python 相关工具
    python3-distutils \
    python3-docutils \
    python3-pyelftools \
    python3-setuptools \
    # 常用辅助工具
    rsync \
    swig \
    texinfo \
    unzip \
    wget \
    file \
    time \
    # 解决 SSL 证书验证问题的关键包
    ca-certificates \
    # 为非 root 用户提供提权能力的工具
    sudo \
    && \
    # 清理 apt 缓存，减小最终镜像大小
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

# 创建一个名为 'builder' 的非 root 用户，并赋予其免密 sudo 权限
# 这是为了安全起见，避免在容器中直接使用 root 用户进行编译等操作
RUN useradd -m -s /bin/bash builder && \
    adduser builder sudo && \
    echo 'builder ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

# 切换到新创建的非 root 用户
USER builder

# 为 builder 用户设置工作目录
WORKDIR /home/builder

# 设置容器启动时执行的默认命令，即启动一个 bash shell
CMD ["/bin/bash"]

2. docker-compose.yml

创建 docker-compose.yml 文件来管理容器的构建和运行。该配置会自动构建镜像，并设置一个关键的卷挂载，将宿主机的 ./openwrt 目录映射到容器内，使得源码和编译产物能够持久化保存在宿主机上。

version: '3.8'

services:
  openwrt-builder:
    # 使用当前目录下的 Dockerfile 来构建镜像
    build: .
    # 给构建出的镜像命名
    image: openwrt-builder-image
    # 容器的名字
    container_name: openwrt_build_env
    # 覆盖 Dockerfile 中的 CMD，确保我们能进入 bash
    command: /bin/bash
    # 保持容器在前台运行，并分配一个伪终端 (等同于 -it)
    stdin_open: true
    tty: true
    # 网络模式
    network_mode: host
    # 挂载卷
    volumes:
      # 将宿主机的 ./openwrt 目录挂载到容器的 /home/builder/openwrt
      - ./openwrt:/home/builder/openwrt
    # 设置工作目录，进入容器后会自动切换到这个目录
    working_dir: /home/builder/openwrt

3. 推荐目录结构

为了便于管理，建议采用以下目录结构：

~/openwrt_dev/
├── Dockerfile
├── docker-compose.yml
└── openwrt/

其中 openwrt 目录为 OpenWrt 源码。

编译步骤

1. 获取OpenWrt源码

在 ~/openwrt_dev/ 目录下，克隆 OpenWrt 官方源码。

git clone https://git.openwrt.org/openwrt/openwrt.git

2. 构建镜像与启动容器

在 ~/openwrt_dev/ 目录下执行以下命令，Docker Compose 会自动根据 Dockerfile 构建镜像，并根据 docker-compose.yml 的配置启动容器。

# 作者安装的docker比较新，把docker-compose整合到docker工具链中了，使用方式和旧版不太一样
docker compose up --build -d

# 旧版 docker-compose
docker-compose up --build -d

# 查看容器情况
docker ps -a

# 启动或关闭我们的容器
docker start openwrt_build_env
docker stop openwrt_build_env

使用 -d 参数可以在后台启动容器。

3. 进入容器

容器启动后，使用 docker exec 命令进入容器内部的 bash 环境。

docker exec -it openwrt_build_env bash

4. 执行编译

进入容器后，所有操作都在 /home/builder/openwrt 目录下进行。

# 1. 更新并安装 Feeds
./scripts/feeds update -a
./scripts/feeds install -a

# 2. 生成默认配置文件，并进入配置菜单
#    在这里选择你的目标设备型号、软件包等
#    本文章的重点不在于此，不再展开
make menuconfig

# 3. 下载编译所需的依赖包
make download -j$(nproc)

# 4. 开始编译 (使用与CPU核心数相当的线程数以加快速度)
make -j$(nproc) V=s

编译产物

编译成功后，生成的固件及相关文件会位于宿主机的 ~/openwrt_dev/openwrt/bin/targets/ 目录下，具体路径取决于你在 make menuconfig 中选择的目标平台。例如，mediatek/filogic 平台的产物路径如下：

路径: ~/openwrt_dev/openwrt/bin/targets/mediatek/filogic/

使用chroot和qemu调试开发板的rootfs

Mon, 28 Jul 2025 00:00:00 GMT

一、`chroot` 与 qemu 简介

`chroot` (Change Root)

chroot 是 Linux 系统中的一个命令及系统调用，用于将一个进程及其子进程的根目录切换到文件系统中的一个新位置。这使得该进程无法访问或命名新根目录之外的文件。

主要用途：

系统修复：当系统无法启动时，可以使用 Live CD 启动，然后 chroot 到损坏的系统中进行修复。
安全隔离：限制特定进程的文件系统访问权限，创建一个简易的沙箱环境。
交叉编译：在 x86 主机上为 ARM 等不同架构的设备构建和测试软件。
环境测试：在当前系统中模拟另一个 Linux 发行版环境，例如在 Ubuntu 中运行 Debian 环境。

`qemu-user-static`

当在 x86 架构的主机上 chroot 到一个为 ARM 等异构平台构建的根文件系统时，会因为 CPU 指令集不兼容而导致无法执行任何程序。qemu-user-static 通过 binfmt_misc 机制解决了这个问题，它能够透明地解释和执行异构架构的二进制文件，从而在主机上模拟目标硬件环境。

二、操作流程

以用Ubuntu系统调试立创泰山派的Ubuntu22.04 rootfs为例

1. 安装 `qemu-user-static`

首先，在主机系统中安装 qemu-user-static 软件包。

sudo apt update
sudo apt install qemu-user-static

安装完成后，将对应目标架构的 QEMU 静态二进制文件复制到开发板根文件系统的 usr/bin 目录下。例如，对于 ARM 架构：

# 假设 "ubuntu/" 是开发板根文件系统的挂载点
sudo cp /usr/bin/qemu-arm-static ubuntu/usr/bin/
sudo cp /usr/bin/qemu-aarch64-static ubuntu/usr/bin/

为了确保 QEMU 能够自动处理异构架构的二进制文件，需要检查 binfmt_misc 的配置是否已启用。

ls -l /proc/sys/fs/binfmt_misc/
# 检查对应的 qemu-aarch64 解释器是否启用
cat /proc/sys/fs/binfmt_misc/qemu-aarch64

理想情况下，cat 命令的输出应显示 enabled。

默认情况下qemu会自动注册，但是笔者使用的wsl2可能有bug，不会自动注册，这时候需要手动注册：

# rsicv64
sudo sh -c 'echo ":qemu-riscv64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-riscv64-static:F" > /proc/sys/fs/binfmt_misc/register'

# aarch64
sudo sh -c 'echo ":qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-aarch64-static:F" > /proc/sys/fs/binfmt_misc/register'

2. 挂载根文件系统 (rootfs)

为了方便地挂载和卸载 chroot 环境所需的虚拟文件系统，可以创建一个脚本。

创建 mount.sh 脚本：

#!/bin/bash
# mount.sh - Mounts/unmounts essential filesystems for chroot

function mnt() {
    echo "MOUNTING..."
    sudo mount -t proc /proc ${2}proc
    sudo mount -t sysfs /sys ${2}sys
    sudo mount -o bind /dev ${2}dev
    sudo mount -o bind /dev/pts ${2}dev/pts
    echo "Entering chroot environment..."
    sudo chroot ${2}
}

function umnt() {
    echo "UNMOUNTING..."
    sudo umount ${2}proc
    sudo umount ${2}sys
    sudo umount ${2}dev/pts
    sudo umount ${2}dev
}

if [ "$1" == "-m" ] && [ -n "$2" ]; then
    mnt $1 $2
elif [ "$1" == "-u" ] && [ -n "$2" ]; then
    umnt $1 $2
else
    echo "Usage: $0 [-m|-u] <rootfs_path>"
    echo "  -m: Mount and chroot into the rootfs"
    echo "  -u: Unmount the rootfs"
    echo "Example: $0 -m /path/to/rootfs/"
fi

赋予脚本执行权限：

chmod +x mount.sh

也可以使用这个健壮性更好的python脚本

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import os
import sys
import subprocess
import shutil

# --- 用户配置 ---
# 在这里修改为要挂载的根文件系统的绝对路径
ROOTFS_PATH = "/home/hao/k230_sdk/output/k230_canmv_lckfb_defconfig/images/debian13"

# 如果需要跨架构 chroot (例如在 x86 电脑上 chroot ARM 系统),
# 指定 QEMU 静态二进制文件的路径。如果不需要，请留空 ""。
# 通常在 /usr/bin/ 目录下, 例如 qemu-aarch64-static, qemu-arm-static 等。
QEMU_STATIC_BINARY = "/usr/bin/qemu-riscv64-static"
# --- 配置结束 ---


def run_command(command, check=True):
    """执行一个 shell 命令并处理可能发生的错误"""
    print(f"🚀 执行: {' '.join(command)}")
    try:
        subprocess.run(command, check=check)
    except FileNotFoundError:
        print(f"❌ 命令未找到: {command[0]}。请确保该程序已安装并在 PATH 环境变量中。", file=sys.stderr)
        sys.exit(1)
    except subprocess.CalledProcessError as e:
        print(f"❌ 命令执行失败: {' '.join(e.cmd)} (返回码: {e.returncode})", file=sys.stderr)
        if not check:
             print("   (警告: 此命令失败，但程序将继续执行)")
        else:
            sys.exit(1)


def unmount_filesystems():
    """
    按正确顺序卸载所有 chroot 文件系统。
    该函数设计得非常健壮，会检查每个挂载点是否存在且已挂载。
    """
    print("\n🧹 开始安全卸载程序...")
    mount_points = ['dev/pts', 'dev', 'sys', 'proc']

    for mp in mount_points:
        target_path = os.path.join(ROOTFS_PATH, mp)
        if os.path.exists(target_path) and os.path.ismount(target_path):
            run_command(['sudo', 'umount', '-l', target_path], check=False) # 使用 -l (lazy) 更安全

    if QEMU_STATIC_BINARY:
        qemu_dest_path = os.path.join(ROOTFS_PATH, 'usr', 'bin', os.path.basename(QEMU_STATIC_BINARY))
        if os.path.exists(qemu_dest_path):
            print(f"   清理 QEMU 模拟器: {qemu_dest_path}")
            run_command(['sudo', 'rm', qemu_dest_path])

    print("✅ 清理完成。")


def mount_and_chroot():
    """
    挂载所需的文件系统并进入 chroot 环境。
    使用 try...finally 确保无论 chroot 内部发生什么，都会执行卸载。
    """
    try:
        print("🛠️  开始挂载 chroot 所需的文件系统...")
        mounts = [
            ('proc', 'proc', 'proc', None),
            ('sysfs', 'sys', 'sysfs', None),
            ('/dev', 'dev', None, 'bind'),
            ('/dev/pts', 'dev/pts', None, 'bind'),
        ]

        for source, dest_subdir, fstype, options in mounts:
            target_path = os.path.join(ROOTFS_PATH, dest_subdir)
            if not os.path.exists(target_path):
                print(f"   创建缺失的目录: {target_path}")
                run_command(['sudo', 'mkdir', '-p', target_path])

            command = ['sudo', 'mount']
            if fstype: command.extend(['-t', fstype])
            if options == 'bind': command.extend(['-o', 'bind'])
            command.extend([source, target_path])
            run_command(command)

        if QEMU_STATIC_BINARY:
            if not os.path.exists(QEMU_STATIC_BINARY):
                print(f"❌ 错误: QEMU 模拟器 '{QEMU_STATIC_BINARY}' 未在您的主机上找到。", file=sys.stderr)
                print("   如果您正在进行跨架构 chroot，请安装它 (例如: 'sudo apt install qemu-user-static')。", file=sys.stderr)
                return

            ### --- 新增功能：检查 binfmt_misc 是否启用 --- ###
            # 从 QEMU 二进制文件名推断出 binfmt_misc 的处理器名
            # 例如 "qemu-aarch64-static" -> "qemu-aarch64"
            handler_name = os.path.basename(QEMU_STATIC_BINARY).removesuffix('-static')
            binfmt_path = f"/proc/sys/fs/binfmt_misc/{handler_name}"
            
            print(f"   检查 QEMU binfmt_misc 处理器: {binfmt_path}")
            if not os.path.exists(binfmt_path):
                print(f"❌ 错误: QEMU binfmt_misc 处理器未启用 ({binfmt_path} 不存在)。", file=sys.stderr)
                print("   这意味着您的主机内核可能无法直接运行目标架构的二进制文件。", file=sys.stderr)
                print("   请尝试通过重启服务来注册处理器，例如运行:", file=sys.stderr)
                print("     sudo systemctl restart systemd-binfmt.service", file=sys.stderr)
                print("   或者:", file=sys.stderr)
                print("     sudo update-binfmts --enable", file=sys.stderr)
                return # 提前中止，finally 块会负责清理
            
            print("   ✅ QEMU binfmt_misc 处理器已启用。")
            ### --- 新增功能结束 --- ###

            qemu_dest_path = os.path.join(ROOTFS_PATH, 'usr', 'bin', os.path.basename(QEMU_STATIC_BINARY))
            print(f"   复制 QEMU 模拟器到 chroot 环境: {qemu_dest_path}")
            run_command(['sudo', 'cp', QEMU_STATIC_BINARY, qemu_dest_path])

        print("\n✅ 挂载完成。即将进入 chroot 环境...")
        print("   在 chroot 环境中，您可以执行所需命令。")
        print("   完成后，请键入 'exit' 以退出 chroot 并自动卸载所有文件系统。")
        
        run_command(['sudo', 'chroot', ROOTFS_PATH])

    except Exception as e:
        print(f"\n❌ 在挂载或 chroot 过程中发生意外错误: {e}", file=sys.stderr)
    finally:
        print("\n🚪 已退出 chroot 环境或发生错误。")
        unmount_filesystems()


def main():
    """脚本主入口"""
    if os.geteuid() != 0:
        print("❌ 错误: 此脚本需要 root 权限。请使用 'sudo' 运行。", file=sys.stderr)
        sys.exit(1)

    if not os.path.isdir(ROOTFS_PATH):
        print(f"❌ 错误: 配置的根文件系统路径 '{ROOTFS_PATH}' 不是一个有效的目录。", file=sys.stderr)
        sys.exit(1)

    if len(sys.argv) != 2 or sys.argv[1] not in ['-m', '-u']:
        print(f"用法: sudo {sys.argv[0]} [-m|-u]")
        print("  -m: 挂载文件系统并进入 chroot 环境")
        print("  -u: 仅卸载文件系统 (用于手动清理)")
        sys.exit(1)

    action = sys.argv[1]
    if action == '-m':
        mount_and_chroot()
    elif action == '-u':
        unmount_filesystems()

if __name__ == '__main__':
    main()

使用方式

配置：打开 manage_chroot.py 文件，修改顶部的 ROOTFS_PATH 变量，使其指向你的根文件系统目录（例如 /home/user/my_project/rootfs）。如果需要，同时配置 QEMU_STATIC_BINARY。
挂载并进入 Chroot：在终端中运行以下命令。脚本将挂载所有必要的文件系统，然后自动带你进入 chroot 环境。
```
sudo python3 manage_chroot.py -m
```
当你完成在 chroot 环境中的工作后，只需输入 exit 并按回车。脚本会自动检测到退出，并执行所有卸载和清理操作。
仅执行卸载：如果在某些异常情况下，你需要手动执行清理，可以运行以下命令。它会安全地卸载所有相关的挂载点。
```
sudo python3 manage_chroot.py -u
```

3. 进入 `chroot` 环境并进行系统配置

使用上一步创建的脚本挂载并进入开发板的根文件系统。

# 假设开发板根文件系统位于当前目录下的 "ubuntu/"
sudo ./mount.sh -m ubuntu/

成功进入后，将处于开发板的模拟环境中，可以执行系统配置任务。

以下是曾经给泰山派移植ubuntu22.04时的记录，仅供参考

泰山派sdk可用：

::github{repo="CmST0us/tspi-linux-sdk"}

a. 更新软件源及安装必要软件

# 某些系统可能需要赋予/tmp目录写权限
chmod 777 /tmp

apt update
apt install -y sudo vim udev net-tools ethtool udhcpc netplan.io \
               language-pack-en-base iputils-ping openssh-sftp-server \
               ntp usbutils alsa-utils libmtp9 language-pack-zh-han* \
               bluetooth* bluez* blueman* wireless-tools network-manager dialog

# 清理不需要的软件包
apt-get remove --purge libreoffice* -y
apt-get autoremove -y

b. 添加用户及配置权限

# 1. 添加一个新用户（例如 tspi）
adduser tspi

# 2. 将新用户添加到 sudo 组以赋予管理员权限
adduser tspi sudo

# 3. 修改 root 用户的密码
passwd root

c. 优化开机网络等待时间

默认情况下，系统启动时可能会等待网络配置长达5分钟。通过修改 systemd 服务，可以缩短或禁用此等待时间。

编辑服务文件：

vim /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service

修改 ExecStart 行： 将 timeout 参数改为一个较小的值（如 5 秒）或 0（禁用）。

[Service]
ExecStart=/usr/bin/nm-online -s -q --timeout=5

d. 添加分区自动扩容服务（重要）

为了让烧录到 SD 卡或 eMMC 的文件系统在首次启动时自动扩展以使用整个分区空间，可以创建一个系统服务。

(1) 创建 resize2fs.sh 脚本：

vim /etc/init.d/resize2fs.sh

添加以下内容： 该脚本会检查一个标志文件，如果不存在，则执行分区扩容并创建该标志文件，确保扩容只执行一次。

#!/bin/bash -e
# Resize the root filesystem partition, e.g., /dev/mmcblk0p6

PARTITION_TO_RESIZE="/dev/mmcblk0p6"
FLAG_FILE="/usr/local/boot_flag"

if [ ! -e "$FLAG_FILE" ] ; then
  echo "Resizing $PARTITION_TO_RESIZE..."
  resize2fs $PARTITION_TO_RESIZE
  touch "$FLAG_FILE"
  echo "Resize complete."
fi

(2) 赋予脚本执行权限：

chmod +x /etc/init.d/resize2fs.sh

(3) 创建 systemd 服务来执行此脚本：

vim /lib/systemd/system/resize2fs.service

添加服务定义：

[Unit]
Description=Resize root filesystem on first boot
DefaultDependencies=no
After=systemd-remount-fs.service
Before=local-fs.target

[Service]
Type=oneshot
ExecStart=/etc/init.d/resize2fs.sh
StandardOutput=journal
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

(4) 启用该服务：

systemctl enable resize2fs.service

4. 退出并卸载根文件系统

完成所有配置后，退出 chroot 环境。

exit

返回到主机系统后，使用脚本卸载之前挂载的虚拟文件系统（如果用上面提供的python脚本，当退出时会自动卸载，不用手动操作）。

sudo ./mount.sh -u ubuntu/

从嘉立创导入元器件到kicad

Sun, 27 Jul 2025 00:00:00 GMT

一、Windows中miniconda的安装与使用

安装

官方安装指南，以此执行一下三条指令

wget "https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe" -outfile ".\miniconda.exe"
Start-Process -FilePath ".\miniconda.exe" -ArgumentList "/S" -Wait
del .\miniconda.exe

常用命令

列出当前已有虚拟环境 conda env list

创建虚拟环境

conda create -n easyeda python=3.10 # 创建名为easyeda的虚拟环境，指定python版本

# 激活对应虚拟环境
conda activate easyeda

# 离开当前虚拟环境
conda deactivate

二、easyeda2kicad脚本的安装与使用

easyeda2kicad仓库

在对应虚拟环境中执行pip install easyeda2kicad即可安装

基于元器件客编号来导入元器件

找到立创商城里需要的元件的编号，在虚拟环境中把它导入到名为easyeda2kicad的元件库中

easyeda2kicad --full --lcsc_id=C32710423


# 显示创建的元件名与库的地址
[INFO] Created Kicad symbol for ID : C32710423
       Symbol name : LCKFB-LSPI-SKYSTAR-STM32F407VGT6-PRO
       Library path : C:\Users\hao\Documents\Kicad\easyeda2kicad/easyeda2kicad.kicad_sym
[INFO] Created Kicad footprint for ID: C32710423
       Footprint name: COMM-TH_LCKFB-LSPI-SKYSTAR-STM32F407VGT6-PRO
       Footprint path: C:\Users\hao\Documents\Kicad\easyeda2kicad/easyeda2kicad.pretty\COMM-TH_LCKFB-LSPI-SKYSTAR-STM32F407VGT6-PRO.kicad_mod
[WARNING] No 3D model available for this component

导入easyeda对应的符号库和封装库

在kicad开始界面的设置中的符号库与封装库中，分别导入对应文件和路径

在kicad中找到导入的元件

使用pyocd进行mcu的烧录和调试

Wed, 23 Apr 2025 00:00:00 GMT

简介

pyOCD 是一个开源 Python 软件包，用于多种受支持的硬件调试器（DAP-Link、J-Link、ST-Link,CMSIS-DAP v1(HID)、CMSIS-DAP v2(WinUSB)、SEGGER J-Link、ST-LINK v2和ST-LINK v3）下编程和调试Arm Cortex-M微控制器。它是完全跨平台的，并支持Linux，macOS和Windows。它内置支持多达70种流行的MCU。通过使用CMSIS-Pack，几乎支持市场上的所有Cortex-M设备。pyOCD还可以作为GDB Service配合GDB调试芯片。

使用环境：Ubuntu22.04

一、安装pyocd

利用pip进行安装，确保当前环境中python版本大于3.6

安装pip

sudo apt update
sudo apt install python3-pip

更新pip

python3 -m pip install --upgrade --force pip

安装pyocd

python3 -m pip install -U pyocd

安装成功后重启Ubuntu，查看是否安装成功

pyocd -V # 注意是大写V

二、连接烧录设备

列出当前连接上的烧录设备

pyocd list

#   Probe/Board    Unique ID                  Target  
--------------------------------------------------------
  0   STM32 STLink   00380043320000054E575359   n/a

三、添加对MCU的支持

列出当前支持的所有mcu：

pyocd list -t

Name                      Vendor                   Part Number                  Families   Source   
------------------------------------------------------------------------------------------------------
  air001                    AirM2M                   Air001                                  builtin  
  air32f103xb               AirM2M                   Air32F103xB                             builtin  
  air32f103xc               AirM2M                   Air32F103xC                             builtin  
  air32f103xe               AirM2M                   Air32F103xE                             builtin  
  air32f103xg               AirM2M                   Air32F103xG                             builtin  
  air32f103xp               AirM2M                   Air32F103xP                             builtin  
  cc3220sf                  Texas Instruments        CC3220SF                                builtin  
......

查询对指定型号的支持：

pyocd list -t | grep stm32*

stm32f051                 STMicroelectronics       STM32F051     builtin  
stm32f103rc               STMicroelectronics       STM32F103RC   builtin  
  
......

1、查询并添加对某款MCU的支持

更新包索引

pyocd pack update

查找mspm0g3507

pyocd pack -f mspm0g3507

Part         Vendor              Pack                          Version   Installed  
--------------------------------------------------------------------------------------
  MSPM0G3507   Texas Instruments   TexasInstruments.MSPM0G_DFP   1.2.1     False

如果查询到了就可以直接安装

pyocd pack -i mspm0g3507

Downloading packs (press Control-C to cancel):
    TexasInstruments.MSPM0G_DFP.1.2.1
Downloading descriptors (001/001)

此时再执行pyocd pack -f mspm0g3507，Installed 就会变成True，说明已经支持

2、手动添加对某款MCU的支持

有时候pyocd没有初始支持对某款mcu，查询也查询不到，可以手动下载对应的pack包并进行安装

比如默认就找不到stm32f407zgt6：

pyocd pack -i stm32f407zgt6

0000550 W No matching devices. Please make sure the pack index is up to date. [pack_cmd]
Downloading packs (press Control-C to cancel):

可以从Keil官网下载对应的DFP包，在对目标mcu进行操作的时候作为参数来添加进去

pyocd list -t --pack ./Keil.STM32F4xx_DFP.3.0.0.pack

这样就可以列出包中支持的mcu

可以把需要的pack放置到指定目录，在对需要的单片机进行操作时，加入--pack参数

三、擦除和烧录MCU

烧录

pyocd flash --target stm32f407zgtx ./build/demo.hex --pack ~/Keil.STM32F4xx_DFP.3.0.0.pack 

pyocd flash --target mspm0g3507 ./build/empty.hex

如果需要操作的mcu已有支持，不需要加--pack参数

**注意：**烧录的单片机是stm32f407zgt6，但是下载的pack中对应的型号是stm32f407zgtx，可以通过pyocd list -t来查看。

VScode快捷任务

.vscode/tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Flash",
            "type": "process",
            "command": "pyocd",
            "args": [
              "flash",
              "--target",
              "stm32f407zgtx",
              "--pack",
              "~/Keil.STM32F4xx_DFP.3.0.0.pack",
              "./build/demo.hex"
            ],
            "problemMatcher": [],
            "group": {
              "kind": "build",
              "isDefault": true
            },
            "presentation": {
              "reveal": "always",
              "panel": "dedicated",
              "clear": true
            },
            "detail": "Flash demo.hex to STM32 via ST-Link (pyocd)"
          }
    ]
}

四、调试MCU

**注意：**可执行文件使用.elf

调试的时候需要下载VScode插件Cortex Debug

.vscode/launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceFolder}",
            "executable": "./build/demo.elf",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "main",
            "servertype": "pyocd",
            "targetId": "stm32f407zgtx",
            "cmsisPack": "~/Keil.STM32F4xx_DFP.3.0.0.pack"
        }
    ]
}

调试结束后，确定gdb进程关闭，否则下次进入调试会报错

USBIPD的使用

Mon, 17 Feb 2025 00:00:00 GMT

使用USBIPD将USB设备共享给WSL2

在windows的powershell中安装USBIPD，安装后重启powershell
```
winget install usbipd //需要代理
```

找到esp32对应的设备，记住BUSID，如：6-4

usbipd list //列出当前usb设备

6-4    1a86:7522  USB-SERIAL CH340K (COM3)                                      Not shared

绑定BUSID，运行它被共享到WSL2

usbipd bind --busid <BUSID>
# 如：
usbipd bind --busid 6-4

# 取消共享
usbipd unbind --busid 6-4

将USB设备附加到WSL2

usbipd attach --wsl --busid <BUSID>
# 如：
usbipd attach --wsl --busid 6-4

# 取消附加到wsl2上（根据guid）
usbipd unbind --guid 58e8d17f-29ee-41ba-96b0-10cba8173253

运行结果：

# usbipd attach --wsl --busid 6-4
usbipd: info: Using WSL distribution 'Ubuntu' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address 127.0.0.1 to reach the host.

在Ubuntu上运行lsusb，可以看到多出一个沁恒（ch343）QinHeng的设备

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1a86:7522 QinHeng Electronics USB Serial
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

图形化软件

::github{repo="nickbeth/wsl-usb-manager"}

好暖好温暖的博客

多元函数求极值 | 使用Hessian矩阵

一、题目

二、多元函数极值的一般步骤

第一步：求一阶偏导，找驻点

第二步：求二阶偏导，构造 Hessian 矩阵

第三步：用二阶判别法判断极值

三、记忆口诀

openipc固件编译和烧录

1. 获取官方SDK

2. 编译SSC338Q的openipc固件

3. 烧录固件

备份旧镜像

使用系统自带的 sysupgrade 来烧录固件

使用Vivado进行ZYNQ的PL端开发基础流程

一、示例程序：LED灯闪烁

二、RTL描述与分析

三、激励创建与仿真

四、设计综合

五、添加设计约束

六、设计实现（布局布线）

七、生成比特流文件

八、烧录与固化

QEMU学习（一）启动buildroot的virt板

一、获取源码并编译

二、用QEMU启动Linux系统

三、启动过程

RKNN 部署与不同 SOC 性能分析

一、概述

二、环境搭建

三、转换模型：ONNX to RKNN

四、编译测试程序

五、结果分析

瑞芯微主流 SoC NPU 性能实测数据汇总表

实验结果分析与硬件适配性评估

参考链接

视频文案：一个视频讲清楚嵌入式Linux交叉编译

1. 搞清楚谁是 Host，谁是 Target

2. Target 还要区分 ABI：Bare Metal 和 Linux

操作系统区别

硬件浮点 (Hard Float)

3. Linux的核心动态库：Libc 库

4. 交叉编译动态链接：Sysroot

如何获取 Sysroot？

5. 总结

异步编程学习（03）同步与异步，Promise与Future

一、何为同步与异步

同步

异步

二、由回调函数到 Promise / Future

1. 基于回调函数的异步代码

核心问题

2. Promise/Future 模型

3. 异步不等于非阻塞

异步编程学习（02）阻塞非阻塞——线程、IO 与轮询

一、 线程状态语义下的阻塞与非阻塞

1. 线程状态语义下的阻塞

2. 线程状态语义下的非阻塞

二、 IO 模型语义下的阻塞与非阻塞

1. 阻塞 IO

2. 非阻塞 IO

三、 容易混淆的点：口语中的阻塞与操作系统中的阻塞

四、 轮询（Polling）会阻塞操作线程吗？

1. 用户态忙轮询（busy polling）

2. Linux 的 poll() 系统调用

异步编程学习（01）裸机中的同步异步

一、裸机框架中的同步

二、裸机框架中的异步

编程日记（01）过早抽象也是万恶之源！

一、C++ 领域的过度设计 / 过早抽象

二、试图用语言特性去掩盖业务知识的匮乏

三、AI 时代的认知负债

四、什么时候才应该进行抽象

毕设日志（四）NPU 推理与硬件资源分配

一、三种硬件资源（VI、VPSS、VENC）分配方式

1. VI 通道分流

2. VPSS 通道分流

3. 不分流，串行逻辑

二、AIPC 软件设计

毕设日志（三）编码视频流的多路分发处理与优化分析

一、线程状态语义下的阻塞与非阻塞

三、容易混淆的点：口语中的阻塞与操作系统中的阻塞

四、轮询（Polling）会阻塞操作线程吗？

2. Linux 的 `poll()` 系统调用

2. `VENC_STREAM_S`编码数据帧分析

2. `VIDEO_FRAME_INFO_S`原始数据帧分析

1. 使用`std::share_ptr`和自定义删除器来封装数据帧

二、远程单步调试

一、安装 Sunshine

二、配置权限与输入环境

三、检查环境依赖

四、初始启动与配置

五、配置 Sunshine 为守护进程