像RDK，RK这种带BPU，NPU的INT算力处理单元的开发板，一般要部署模型都要先进行从float32量化成int8或者int16。本文整理一遍其他教程方便记录。


参考的文章：

[github官方文档：YOLOv11 Detect](https://github.com/D-Robotics/rdk_model_zoo/blob/main/demos/detect/YOLO11/YOLO11-Detect_YUV420SP/README_cn.md#yolov11-detect)

[CSDN博客：rdkx5部署yolov11](https://blog.csdn.net/A12220618/article/details/148211347)

[RDK论坛帖子：RDKx5板载yolov11我也是成功了！](https://forum.d-robotics.cc/t/topic/28178)

[RDK论坛帖子：YOLOv11，地瓜RDK X5开发板，TROS端到端140FPS！](https://forum.d-robotics.cc/t/topic/28039)

这里主要记录差异点：
这一部分其实可以直接修改pip下载的ultralytics包的源码而不用卸载ultralytics整个包并且拉取ultralytics的git仓库源码：
假设你的Python虚拟环境路径为`~/yolov11-env/`
那么在
`~/yolov11-env/lib/python3.11/site-packages/ultralytics/nn/modules` 路径下就能找到head.py，注意不同版本的ultralytics 里面的Detect类的forward方法所在的位置不一样。


![image.png](/static/img/5593b7bc2ee979ad8d98d74b04736131.image.webp)

其他的内容就按照参考文章来
对于[github官方文档：YOLOv11 Detect](https://github.com/D-Robotics/rdk_model_zoo/blob/main/demos/detect/YOLO11/YOLO11-Detect_YUV420SP/README_cn.md#yolov11-detect)和
[RDK论坛帖子：RDKx5板载yolov11我也是成功了！](https://forum.d-robotics.cc/t/topic/28178)里面提及的`移除bbox信息3个输出头的反量化节点`如果不是追求极致推理速度可以跳过，后处理的时候注意一下一下这个几个反量化节点就可以了。怎么区别是bbox还是class，可以根据`hb_model_modifier.log`：
 ```
 通道数 64：通常是 YOLO 的 bbox head（3 anchor * (x,y,w,h) = 12 per anchor → e.g., 34class）

通道数 xx：是你的分类数量（如 COCO 数据集 80 类）

cv2 分支：通常为 bbox（box regression）

cv3 分支：通常为 class（class confidence）
 ```
 
 比如我的模型分类数是4，有这样的hb_model_modifier.log文件，找到中间的地方，看到`value_info`附近：
 ```
 2025-07-05 08:47:30,819 file: hb_model_modifier.py func: hb_model_modifier line No: 404 --------value_info----------
2025-07-05 08:47:30,819 file: hb_model_modifier.py func: hb_model_modifier line No: 406 name: "/model.23/cv2.1/cv2.1.2/Conv_output_0_quantized"
type {
  elem_type: INT32
  dim: 1
  dim: 40
  dim: 40
  dim: 64
}

2025-07-05 08:47:30,819 file: hb_model_modifier.py func: hb_model_modifier line No: 406 name: "/model.23/cv3.1/cv3.1.2/Conv_output_0_quantized"
type {
  elem_type: INT32
  dim: 1
  dim: 40
  dim: 40
  dim: 4
}

2025-07-05 08:47:30,819 file: hb_model_modifier.py func: hb_model_modifier line No: 406 name: "/model.23/cv2.2/cv2.2.2/Conv_output_0_quantized"
type {
  elem_type: INT32
  dim: 1
  dim: 20
  dim: 20
  dim: 64
}

2025-07-05 08:47:30,820 file: hb_model_modifier.py func: hb_model_modifier line No: 406 name: "/model.23/cv3.0/cv3.0.2/Conv_output_0_quantized"
type {
  elem_type: INT32
  dim: 1
  dim: 80
  dim: 80
  dim: 4
}

2025-07-05 08:47:30,820 file: hb_model_modifier.py func: hb_model_modifier line No: 406 name: "/model.23/cv2.0/cv2.0.2/Conv_output_0_quantized"
type {
  elem_type: INT32
  dim: 1
  dim: 80
  dim: 80
  dim: 64
}

2025-07-05 08:47:30,820 file: hb_model_modifier.py func: hb_model_modifier line No: 406 name: "/model.23/cv3.2/cv3.2.2/Conv_output_0_quantized"
type {
  elem_type: INT32
  dim: 1
  dim: 20
  dim: 20
  dim: 4
}
 ```
 
 那么反量化的节点就是除了`dim: 4`以外的三个

RDK X5如何部署yolov11

在交叉编译 Linux 工程（如 busybox、某些文件系统工具或支持 ACL 的应用）时，常会遇到如下报错：

```bash
fatal error: sys/acl.h: No such file or directory
```

这是因为交叉编译工具链的 sysroot 中缺少 ACL 库的头文件或库文件。本文记录一种解决方案。




## 方法一：离线安装


### 步骤一：在 Ubuntu 包搜索网站中查找对应包

打开 [https://packages.ubuntu.com/](https://packages.ubuntu.com/)    在搜索框里输入：

```
libacl
```

很快能查到与 ACL 相关的两个关键包：

* **libacl1**：运行时动态库
* **libacl1-dev**：开发用头文件与静态库

开发需要的是 `libacl1-dev`，因为里面包含：

```
/usr/include/sys/acl.h
/usr/include/acl/libacl.h
```

---

### 步骤二：定位目标架构的交叉编译包

如果是 ARM、aarch64、riscv64 等交叉编译，可以去：

```
http://ports.ubuntu.com/ubuntu-ports/pool/main/a/acl/
```

查找对应架构的 `.deb` 包。

例如，为 aarch64 下载：

```
libacl1-dev_2.2.53-10_arm64.deb
```

---

### 步骤三：解压 `.deb` 到临时目录



```bash
mkdir -p /tmp/libacl_dev
dpkg-deb -x libacl1-dev_2.2.53-10_arm64.deb /tmp/libacl_dev
```

或者用 `ar` 命令：

```bash
mkdir -p /tmp/libacl_dev
ar x libacl1-dev_2.2.53-10_arm64.deb
tar -xf data.tar.xz -C /tmp/libacl_dev
```

不出意外能在 `/tmp/libacl_dev` 里看到：

```
/tmp/libacl_dev/usr/include/sys/acl.h
/tmp/libacl_dev/usr/include/acl/libacl.h
/tmp/libacl_dev/usr/lib/aarch64-linux-gnu/libacl.a
...
```

---

### 步骤四：复制头文件和库到交叉工具链

我的工具链 sysroot 路径为：

```
/opt/toolchains/aarch64-linux-gnu/
```

将头文件和库复制进去：

```bash
cp -r /tmp/libacl_dev/usr/include/* /opt/toolchains/aarch64-linux-gnu/include/
cp -r /tmp/libacl_dev/usr/lib/aarch64-linux-gnu/* /opt/toolchains/aarch64-linux-gnu/lib/
```
 

然后重新编译
 

---

<span style="color:red; font-size: 1.17em; font-weight:bold;">注意：此方法潜在弊端</span>


虽然这种方法能解决 `<sys/acl.h>` 缺失的问题，但存在以下 **风险和弊端**：

**版本不匹配**

* 从 Ubuntu 提取的头文件和库，与目标 Linux 系统版本、glibc、libc 版本可能不一致。编译时可能没问题，运行时却出错。

**依赖链不完整**

* ACL 库依赖其他库（比如 libattr）。只复制 libacl 可能不够。

 **污染工具链环境**

* 手动 cp 文件到工具链，可能导致后续升级或维护困难。

---

## 方法二：更安全、推荐的解决方案

下面是更稳妥的做法：

### 1. 用多架构包管理器 (Multi-Arch)

若在 x86\_64 主机上交叉编译 ARM，可通过 `apt` 安装 arm64 包：

```bash
dpkg --add-architecture arm64
apt update
apt install libacl1-dev:arm64
```

然后从 `/usr/arm-linux-gnueabihf/include/` 等路径中获取文件。

---

### 2. 用 sysroot 镜像

如果有目标系统的 rootfs，直接用 rootfs 作为 sysroot：

```bash
--sysroot=/path/to/rootfs
```

这样所有头文件和库都与目标系统一致。

---

### 3. 用 Yocto 或 Buildroot

针对嵌入式，Yocto、Buildroot 都能自动生成全套交叉环境：

* sysroot 自动匹配
* 不易出现版本错配问题

编译过程中<sys/acl.h>找不到的解决方案

在Web开发中，Vue 通过 `$emit()` 和 `$on()`实现组件间通信，而 Qt 通过 信号和槽（Signal & Slot） 机制实现解耦的对象通信。与此同时，QML + QSS 和 HTML + CSS 也存在类似的结构，分别用于 UI 构建和样式管理。本文将探讨 Qt 和 Vue 在 事件通信 和 UI 设计 方面的异同点。

在探讨Qt与Vue的异曲同工之处，先回顾一下Qt的信号和槽、QML、QSS。
# Qt的信号和槽、QML、QSS
## Qt的信号和槽机制是什么？
 
Qt的信号（Signal）和槽（Slot）是一种 **观察者模式** 的实现，主要用于对象之间的 **解耦通信**。当某个对象的状态发生变化时，可以发射（emit）信号，所有连接到该信号的槽函数都会自动调用，类似于事件回调机制。

#### **1. 语法**
Qt 使用 `QObject` 提供信号和槽机制：
```cpp
class MyClass : public QObject {
    Q_OBJECT
public:
    MyClass(QObject* parent = nullptr) : QObject(parent) {}

signals:
    void mySignal(int value);  // 信号

public slots:
    void mySlot(int value) {   // 槽
        qDebug() << "Received value:" << value;
    }
};
```
连接信号和槽：
```cpp
MyClass obj1, obj2;
QObject::connect(&obj1, &MyClass::mySignal, &obj2, &MyClass::mySlot);
obj1.mySignal(42);  // 发射信号，obj2 的 mySlot() 被调用
```

---

### **2. Qt信号和槽的底层实现**
Qt 的信号槽依赖于 **元对象系统（Meta-Object System, MOC）**，其核心机制包括：
#### **（1）MOC 预处理**
Qt **不会**使用 C++ 直接提供的函数指针或标准回调，而是使用 MOC 预处理 `Q_OBJECT` 宏，生成 **信号槽映射表**。编译时，MOC 工具会解析 `.h` 文件，生成一个 `.moc` 代码文件，其中包含：
- 信号槽的 **注册** 信息
- 事件派发逻辑
- 反射调用函数（基于 `QMetaObject`）

#### **（2）信号本质**
信号是 **类的成员函数**，但不需要实现体。MOC 生成的 `.moc` 文件中，会为每个信号创建 `QMetaObject::activate()` 调用，用于触发信号。

```cpp
void MyClass::mySignal(int value) {
    void *args[] = { &value };
    QMetaObject::activate(this, &MyClass::staticMetaObject, 0, args);
}
```

#### **（3）槽的调用**
MOC 解析 `connect()` 语句，并在 `QMetaObject` 内部维护 **信号槽连接表**，当信号触发时：
- 通过 `QMetaObject::activate()` 解析连接表
- **直接调用** 目标对象的槽函数（如果是 Direct 连接）
- **投递到事件队列**（如果是 Queued 连接）

---

### **3. 信号和槽的连接方式**
Qt 支持四种连接方式：
| 连接方式 | 说明 |
|---------|------|
| `Qt::AutoConnection` | 默认方式，自动选择 Direct 或 Queued |
| `Qt::DirectConnection` | 直接调用槽（类似普通函数调用）|
| `Qt::QueuedConnection` | 通过事件队列异步调用槽 |
| `Qt::BlockingQueuedConnection` | 同步调用槽，阻塞当前线程 |

示例：
```cpp
QObject::connect(&obj1, &MyClass::mySignal, &obj2, &MyClass::mySlot, Qt::QueuedConnection);
```

---

### **4. 什么时候用信号和槽？**
信号和槽适用于以下情况：
1. **对象之间的通信**  
   - 例如 GUI 组件之间的交互（按钮点击、窗口更新等）
2. **解耦模块间的依赖**  
   - 不需要知道对方的具体类型，只需通过信号通知
3. **跨线程通信**  
   - 使用 `Qt::QueuedConnection` 进行线程间消息传递
4. **动态事件响应**  
   - 例如插件系统，动态添加槽函数进行事件处理

---

### **5. 何时不用信号和槽？**
- **性能关键代码**  
  信号和槽有一定 **运行时开销**（如 `QMetaObject` 查表、事件队列处理），如果需要极致性能，可以考虑直接使用函数调用或回调函数。
  
- **简单的函数调用**  
  如果是 **同一类内部的调用**，或者**两个对象绑定紧密**，可以直接调用成员函数，而不必使用信号和槽。

---

### **6. 总结**
- **信号和槽用于解耦通信**，提供了类似 **观察者模式** 的机制。
- **基于 MOC 预处理**，通过 `QMetaObject::activate()` 进行信号分发。
- **支持跨线程通信**，可使用 `Qt::QueuedConnection` 在不同线程间投递消息。
- **适用于 GUI 事件、模块解耦、动态交互**，但在性能敏感场景需谨慎使用。



## QML的作用
### **QML 是什么？**

QML（Qt Modeling Language）是一种 **声明式 UI 语言**，用于 **构建 Qt Quick 界面**。它的语法类似 JSON，支持 **动画、数据绑定、JavaScript 逻辑**，并能与 C++ 交互。

  **QML 示例**：

```qml
Rectangle {
    width: 200; height: 100
    color: "red"
}
```

  **数据绑定**：

```qml
Rectangle {
    width: parent.width / 2
}
```

  **动画**：

```qml
Rectangle {
    width: 100; height: 100
    color: "blue"

    NumberAnimation on width {
        from: 100; to: 300
        duration: 1000
    }
}
```

 **C++ 交互**（绑定对象）：

```cpp
QQmlApplicationEngine engine;
engine.load(QUrl("qrc:/main.qml"));
```

------

### **QML 依赖什么解析？**

QML 依赖 **Qt QML 模块（QQmlEngine）** 进行解析，包括：

✅ **1. 解析阶段**（`QQmlEngine`）

- **QML 代码 → AST（抽象语法树）**
- 解析 `.qml` 文件，转换为对象结构

✅ **2. 对象创建阶段**（`QQmlComponent`）

- 解析后的 AST 转换为 **QObject 对象树**
- 组件实例化，进行属性绑定

✅ **3. 绑定 & 渲染阶段**

- **QML 绑定引擎** 计算属性（`width: parent.width / 2`）
- **Qt Quick（QQuick）** 负责 UI 渲染（Scene Graph）

**QML 解析核心 API**：

```cpp
QQmlApplicationEngine engine;
engine.load(QUrl("qrc:/main.qml"));
```

**手动解析 QML 文件**：

```cpp
QQmlEngine engine;
QQmlComponent component(&engine, QUrl("qrc:/main.qml"));
QObject *object = component.create();
```

------

### **总结**

- **QML 是 Qt Quick 的声明式 UI 语言**，用于构建界面。
- **QML 依赖 `QQmlEngine` 解析**，转换成 **QObject 对象**，再由 **Qt Quick 渲染**。
- **解析过程**：QML 代码 → AST → 对象创建 → 绑定 → Qt Quick 渲染。
- **支持 JavaScript 逻辑 & C++ 交互**，更适合现代 UI。














## QSS的作用



### **1. QSS 是什么？**

QSS（Qt Style Sheets）是 Qt 提供的 **样式表机制**，用于 **美化 QWidget 界面**，但 **不适用于 QML**。

✅ **作用**：

- 统一 Qt **窗口、控件（QWidget、QPushButton 等）** 的样式
- 支持 **选择器、伪类、属性设置**
- **动态修改样式**，支持 **代码或 QSS 文件加载**

  **QSS 示例**：

```css
QPushButton {
    background-color: blue;
    color: white;
    border-radius: 5px;
}
QPushButton:hover {
    background-color: lightblue;
}
```

 **QSS 加载方式**（C++ 代码）：

```cpp
QFile file("style.qss");
file.open(QFile::ReadOnly);
QString style = file.readAll();
qApp->setStyleSheet(style);
```

------

### **2. QSS 解析原理**

Qt 解析 QSS 的过程包括：

1. **QSS 语法解析**（Lexical Parsing）
   - Qt 内部 **解析 QSS 语法**，构建 **CSS 规则树**（类似 AST）。
   - 解析 **选择器、属性、值**（如 `QPushButton { color: red; }`）。
2. **匹配控件**（Widget Matching）
   - Qt 遍历 **所有 QWidget**，匹配 **QSS 选择器**。
   - 例如：
     - `QPushButton {}` → 作用于所有 QPushButton
     - `QPushButton#myButton {}` → 仅作用于 `objectName="myButton"` 的按钮
     - `QPushButton:hover {}` → 仅在鼠标悬停时生效
3. **应用样式**（Style Application）
   - Qt **动态修改控件的属性（颜色、字体、边框）**，并 **重绘 UI**。
   - 但 QSS **不能修改 QWidget 布局**，仅适用于样式调整。

  **QSS 解析核心 API**：

```cpp
qApp->setStyleSheet(qssContent);
```

------

### **3. QSS 解析的局限性**

❌ **仅支持 QWidget，不支持 QML**（QML 直接用 `color: "red"`）
 ❌ **无法修改窗口布局**（只影响控件外观）
 ❌ **性能较低**（大量 QSS 可能影响 UI 响应速度）

------

### **4. 适用场景**

✅ **传统桌面应用（QWidget）** → 需要统一样式
 ✅ **不涉及动画的静态 UI** → QSS 简单易用
 ❌ **Qt Quick（QML）项目** → 直接用 `color`、`border` 定义样式

------

### **5. 总结**

- **QSS 是 QWidget 的样式表，但不支持 QML**。
- **Qt 解析 QSS 语法，匹配控件，再应用样式**。
- **适用于 QWidget 界面美化，但性能一般，复杂 UI 用 QML更佳**。



---


# **Qt vs Vue：从底层机制看信号槽、组件通信与 UI 渲染**

## **1. 信号槽 vs 事件通信：底层实现分析**
Qt 的 **信号和槽（Signal & Slot）** 机制和 Vue 的 **事件通信（Event Bus）** 机制虽然都基于 **观察者模式（Observer Pattern）**，但它们的底层实现方式完全不同。

 

### **1.1 Qt 信号和槽的底层实现**
Qt 使用 **元对象系统（Meta-Object System, MOC）** 处理信号和槽的映射关系。主要流程如下：

1. **MOC 编译阶段**
   - Qt 在编译时，MOC 工具会解析 `Q_OBJECT` 宏，生成 `.moc` 文件。
   - 这个文件包含了 **信号槽映射表（QMetaObject）** 和 **事件分发函数**。

2. **注册信号槽**
   - `QObject::connect(sender, SIGNAL(sig()), receiver, SLOT(slot()))` 会将信号-槽关系存入 `QMetaObject`。
   - Qt 运行时维护一个 **哈希表**，存储对象与信号槽的映射。

3. **发射信号**
   - `emit signal()` 触发后，Qt 通过 `QMetaObject::activate()` 查找所有连接的槽，并调用它们。

#### **示例**
```cpp
class Sender : public QObject {
    Q_OBJECT
signals:
    void mySignal(int value);
};

class Receiver : public QObject {
    Q_OBJECT
public slots:
    void mySlot(int value) {
        qDebug() << "Received:" << value;
    }
};

Sender sender;
Receiver receiver;
QObject::connect(&sender, &Sender::mySignal, &receiver, &Receiver::mySlot);
sender.mySignal(42); // 触发信号，槽函数被调用
```

#### **底层机制**
```cpp
void QMetaObject::activate(QObject *sender, int signal_index, void **argv)
{
    // 遍历所有已注册的槽函数，并逐一调用
    for (Slot *slot : signalToSlots[sender][signal_index]) {
        slot->invoke(argv);
    }
}
```

##### **优缺点**
✅ **完全解耦**，对象之间无需互相认识  
✅ **支持跨线程通信**（`Qt::QueuedConnection`）  
❌ **运行时反射机制有开销**（`QMetaObject::invoke()` 使用动态查找）  
❌ **必须使用 `Q_OBJECT`，不支持模板类**  

 

### **1.2 Vue 事件通信的底层实现**
Vue 的事件机制本质上是 **发布-订阅模式（Pub-Sub）**，由一个全局 `Event Bus` 维护所有事件的监听者。

#### **事件触发流程**
1. `this.$emit(eventName, data)` 触发事件，Vue 会在 `this._events[eventName]` 查找所有注册的回调函数。
2. 遍历所有监听者 `this._events[eventName]`，依次执行回调。

#### **示例**
```vue
// 子组件
<template>
  <button @click="sendData">发送数据</button>
</template>

<script>
export default {
  methods: {
    sendData() {
      this.$emit("dataChanged", 42);
    }
  }
}
</script>
```

```vue
// 父组件
<template>
  <ChildComponent @dataChanged="onDataChanged"/>
</template>

<script>
export default {
  methods: {
    onDataChanged(value) {
      console.log("收到子组件的数据:", value);
    }
  }
}
</script>
```

#### **底层实现**
```js
Vue.prototype.$emit = function (event, ...args) {
    const listeners = this._events[event] || [];
    listeners.forEach(listener => listener.apply(this, args));
};
```

##### **优缺点**
✅ **轻量级，运行时开销小**（基于 JS 的对象映射）  
✅ **支持动态注册事件**（无需预定义）  
❌ **父子组件紧耦合**（必须通过 `$parent` 或 `$children` 获取组件实例）  
❌ **不支持跨线程通信**  

 

## **2. UI 渲染架构对比**

Qt 和 Vue 的 UI 渲染方式完全不同，Qt 采用 **Scene Graph + OpenGL**，Vue 依赖 **DOM + Virtual DOM**。


### **2.1 Qt Scene Graph 渲染**
Qt 采用 **场景图（Scene Graph）** 进行 GPU 加速渲染，渲染过程如下：
1. **构建 QML 组件树**，每个 `Item` 对应一个 `QSGNode`。
2. **更新场景图**，在 `update()` 触发时，将 `QSGNode` 传递到 **渲染线程**。
3. **OpenGL 绘制**，`QSGRenderer` 将节点转换为 OpenGL 指令，最终渲染到屏幕。

#### **代码示例**
```qml
Rectangle {
    width: 200; height: 100
    color: "lightgray"

    Button {
        text: "Click Me"
        anchors.centerIn: parent
        font.pixelSize: 16
    }
}
```

#### **底层机制**
```cpp
void QQuickWindow::renderSceneGraph() {
    for (QSGNode *node : sceneGraphNodes) {
        node->renderGL();
    }
}
```

##### **优缺点**
✅ **GPU 加速，适合高性能 UI**  
✅ **跨平台，适用于桌面和嵌入式**  
❌ **C++ 代码复杂度高**  

 

### **2.2 Vue Virtual DOM 渲染**
Vue 采用 **Virtual DOM** 进行高效的 UI 更新，渲染流程如下：
1. **解析 `template` 生成 `VNode` 虚拟节点树**。
2. **VNode Diff 计算最小更新路径**。
3. **通过 `document.createElement()` 更新真实 DOM**。

#### **示例**
```vue
<template>
  <div class="box">Hello Vue</div>
</template>
```

#### **底层机制**
```js
function renderVNode(vnode) {
    if (vnode.type === "text") {
        return document.createTextNode(vnode.value);
    }
    const el = document.createElement(vnode.tag);
    vnode.children.forEach(child => el.appendChild(renderVNode(child)));
    return el;
}
```

##### **优缺点**
✅ **轻量级，适合 Web 页面**  
✅ **支持服务端渲染（SSR）**  
❌ **依赖 DOM，性能不如 Qt Scene Graph**  

 

 

## **3. 总结**
1. **Qt 信号槽 vs Vue 事件**
   - Qt 采用 `QMetaObject` 维护信号-槽映射，适合跨线程通信，但运行时开销大。
   - Vue 事件基于 `Event Bus`，轻量级但仅适用于前端组件通信。

2. **Qt Scene Graph vs Vue Virtual DOM**
   - Qt 采用 **GPU 加速**，适用于高性能 UI。
   - Vue 依赖 **Virtual DOM**，适合 Web 应用。

3. **如何选择？**
   - **桌面应用 / 嵌入式** → **Qt**（更高效）
   - **Web 前端 / H5** → **Vue**（更轻量）

Qt与Web的异曲同工之处？

记录一下去重脚本

脚本一：去除哈希后缀
```shell
#!/bin/zsh

echo "========== 开始检测重复文件 =========="

# 定义匹配哈希值和编号的正则表达式
hash_pattern='-[a-f0-9]{8,}$'  # 例如：-d0a43534a7a7
number_pattern='（[0-9]+）$'     # 例如：（1）

typeset -A files  # 定义 Zsh 关联数组

# 遍历当前目录下的所有 mp3 文件
while IFS= read -r file; do
    base_name="${file%.mp3}"  # 去掉 .mp3 扩展名
    clean_name=$(echo "$base_name" | sed -E "s/$hash_pattern//; s/$number_pattern//")

    # 确保 files[$clean_name] 是数组
    if [[ -n "${files[$clean_name]}" ]]; then
        files[$clean_name]+="|$file"  # 用 | 连接文件路径，避免路径分割问题
    else
        files[$clean_name]="$file"
    fi
done < <(find . -type f -name "*.mp3" -print0 | xargs -0 -I{} echo {})

# 遍历每个去重后的文件名组
for key in "${(@k)files}"; do
    file_list=("${(@s:|:)files[$key]}")  # 用 | 分割文件路径，转换为数组

    if [[ ${#file_list[@]} -gt 1 ]]; then
        echo ">>> 检测到重复文件：$key"
        for f in "${file_list[@]}"; do
            echo "    - \"$f\""
        done

        # 选出最短文件名作为保留项，并确保 `min_file` 不为空
        min_file=""
        for f in "${file_list[@]}"; do
            if [[ -z "$min_file" || ${#f} -lt ${#min_file} ]]; then
                min_file="$f"
            fi
        done

        echo "    ✅ 保留文件: \"$min_file\""

        # 删除其他文件
        for f in "${file_list[@]}"; do
            if [[ "$f" != "$min_file" ]]; then
                echo "    ❌ 删除: \"$f\""
                rm "$f"
            fi
        done
    fi
done

echo "========== 去重完成！ =========="

```

去除重复的歌曲脚本

Rust生态在嵌入式单片机方面也越来越完善了，所以浅尝用Rust开发来开发STM32。


## 前言


**开发板准备:** STM32F103C8T6




在 macOS 下用 Rust 开发并烧写 STM32，可以按照以下步骤进行操作：

------

### 1. **准备开发环境**

**需要提前安装STM32相关的工具**



#### 安装 Rust 工具链

1. 在终端中安装 Rust：

   ```bash
   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
   ```

2. 添加 ARM Cortex-M 目标架构：

   ```bash
   rustup target add thumbv7em-none-eabihf
   ```
   安装
`brew install probe-rs-tools
`
#### 安装 `cargo-generate` 和 `probe-rs`



   用于生成项目模板：

  ```bash
  cargo install cargo-generate
  ```
安装目标平台：
  ```bash
rustup target add thumbv7m-none-eabi
  ```

用于调试和烧写 STM32（弃用）：

  ```bash
  cargo install probe-rs
  ```

#### 安装 GCC 工具链

STM32 的编译需要交叉编译工具链，安装 ARM 工具链：

```bash
brew install --cask gcc-arm-embedded
```

#### 安装 OpenOCD

烧录程序所需 OpenOCD和stlink：

```bash
brew install open-ocd stlink
```

------

### 2. **创建 Rust 项目**

使用社区提供的模板快速生成项目：

1. 使用 

```
cargo-generate
```

生成项目：

```bash
cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart
```

2. 按照提示输入项目名称，例如 `stm32_rust_demo`。

------

### 3. **配置项目**

#### 修改 `Cargo.toml`

根据 STM32 芯片选择对应的 HAL 库，使用 `stm32f1` 系列：

```toml

[dependencies]
cortex-m = "0.7.6"              # 使用最新版本
cortex-m-rt = "0.7.3"           # 和 HAL 匹配的版本
cortex-m-semihosting = "0.3.3"
panic-halt = "0.2.0"
stm32f1xx-hal = { version = "0.10", features = ["stm32f103", "rt"] }

# Uncomment for the panic example.
# panic-itm = "0.4.1"

# Uncomment for the allocator example.
# alloc-cortex-m = "0.4.0"

[[bin]]
name = "stm32_rust_demo"
test = false
bench = false

[profile.release]
codegen-units = 1 # better optimizations
debug = true # symbols are nice, and they don't increase the size on Flash
lto = true # better optimizations

[target.thumbv7m-none-eabi]
runner = "probe-rs run --chip STM32F103C8T6"
rustflags = [
    "-C", "link-arg=-Tlink.x"
]

[build]
target = "thumbv7m-none-eabi"

```


#### 设置链接脚本

在项目中包含 `memory.x` 文件，配置内存布局。例如，STM32F401 的内存布局如下：

```x
MEMORY
{
    FLASH : ORIGIN = 0x08000000, LENGTH = 64K
    RAM : ORIGIN = 0x20000000, LENGTH = 20K
}
```



------

### 4. **编写代码**

示例代码，点亮 STM32 板上的 LED：

```rust
#![no_std]
#![no_main]

use cortex_m_rt::entry;
use panic_halt as _; // 在发生 panic 时暂停
use stm32f4xx_hal::{
    pac,
    prelude::*,
};

#[entry]
fn main() -> ! {
    let peripherals = pac::Peripherals::take().unwrap();
    let gpioa = peripherals.GPIOA.split();

    // 设置 GPIOA5 为推挽输出模式
    let mut led = gpioa.pa5.into_push_pull_output();

    loop {
        led.set_high(); // 点亮 LED
        cortex_m::asm::delay(8_000_000); // 延迟
        led.set_low();  // 关闭 LED
        cortex_m::asm::delay(8_000_000); // 延迟
    }
}
```

------

### 5. **编译项目**

在项目目录下运行：

```bash
cargo build --release
```

然后不出意外应该能看到target下有一个thumbv7m-none-eabi目录，thumbv7m-none-eabi目录下还有一个release目录，release目录下有一个可执行文件stm32_rust_demo。

------

### 6. **烧写代码**

#### 1.使用 `probe-rs`查看调试器

1. 将调试器连接到 STM32 开发板。

执行以下命令查看是否正常识别：
```
probe-rs list 
```
如果能看到以下结果则说明连接没问题：

```

The following debug probes were found:
[0]: CMSIS_DAP -- 2e3c:f000:8D210C000040112513951D07 (CMSIS-DAP)

```

#### 2.修改OpenOCD配置

修改根目录下的openocd.cfg文件
```
# 设置调试器为cmsis-dap
source [find interface/cmsis-dap.cfg]
# 设置调试器所用接口为SWD
transport select swd
# 定义Flash大小为64K
set FLASH_SIZE 0x20000
# 设置芯片
source [find target/stm32f1x.cfg]
```


#### 3.使用 OpenOCD+GDB 来烧写固件（慢速法，不建议）

慢速法是指需要开启两个终端，通过arm-none-eabi-gdb来烧录，但是有第一次烧录成功，后续均无法烧录。
**1. 启动 OpenOCD：**

在项目的根目录下执行：
从前面的`probe-rs list`得到调试器类型CMSIS_DAP，所以执行

```bash
openocd -f interface/cmsis-dap.cfg -f openocd.cfg 
```

不出意外可以看到：

```
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e3c:0xf000, serial=8D210C000040112513951D07
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: SWO-UART supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.3.6
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x1ba01477
Info : [stm32f1x.cpu] Cortex-M3 r1p1 processor detected
Info : [stm32f1x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections

```

若是调试器为ST-Link，则需要调整openocd.cfg和openOCD命令


**2. 启动终端使用 arm-none-eabi-gdb 来与 OpenOCD 交互：**

```
arm-none-eabi-gdb target/thumbv7m-none-eabi/release/stm32_rust_demo
```

3. 在gdb模式下，先执行:

```
target extended-remote :3333
```
不出意外可以看到：

```
Remote debugging using :3333
0x08000dea in ?? ()

```


**4. 在gdb模式下，再执行烧录命令:**


```
load
```
不出意外可以看到：

```
Loading section .vector_table, size 0x130 lma 0x8000000
Loading section .text, size 0x134 lma 0x8000130
Loading section .rodata, size 0x2c lma 0x8000264
Start address 0x08000130, load size 656
Transfer rate: 1 KB/sec, 218 bytes/write.

```

**5.重置设备并启动程序：**

```
monitor reset
```

**6.退出gdb模式:**
```
quit
```
需要再次确认，再输入`y`

**7.退出OpenOCD模式:**

快捷键Ctrl+C或者Command+C

**注意**
当前此种方法不能进行第二次烧录，原因未知。

#### 4.使用 OpenOCD 来烧写固件（快速法，推荐）

一键烧录命令：
```
openocd  -f openocd.cfg -c "tcl_port disabled" -c "gdb_port disabled" -c "program ./target/thumbv7m-none-eabi/release/stm32_rust_demo" -c reset -c shutdown

```