一套连接，服务开发者与AI工具

## 国产RTOS【北大 XiUOS（矽璓）】｜提供AI SKILLS与调试工具

![](https://developer.qcloudimg.com/http-save/yehe-11997417/2575fb4d52ec474202029f40161f180e.png)

> **作者：** 老码农Ewin  
> **标签：** 嵌入式开发 / CMSIS-DAP / 串口调试 / XiUOS / AI硬件开发   
> **本文主角：** MCPIOT USB 3.0 HUB＋DAP Link＋TTL扩展器

---

## 写在前面

先把这次的接口组合摆出来：**一个设备里，集成3个USB 3.0 HUB扩展口、1个PD充电口、1个DAP Link调试接口，以及1路USB转UART TTL。**

USB外设扩展、PD充电、单片机下载调试和串口通信，集中到同一套设备里。开发时，可以把需要的USB外设接上，再用DAP连接目标板、用TTL查看日志和验证指令，少摆几个独立的小工具，桌面接线也更好整理。

之前聊过USB串口扩展器，也聊过能编程的串口中枢。这次，USB扩展器家族又来了个新成员。

它的组合很直接：**USB 3.0 HUB＋PD充电口＋DAP Link＋UART TTL。**

搞单片机的朋友看到这里，大概会说：

“一个下载器，加一个串口？我桌上就有。”

确实。下载器不稀奇，串口也不稀奇。

但最近用AI辅助写嵌入式代码，我越来越在意一件事：**AI改完程序之后，能不能自己把程序烧进去，再看看板子究竟有没有按要求工作？**

以前经常是这样：

```bash
AI改代码 → 我点编译 → 我点下载 → 我开串口
→ 我复制日志给AI → AI再改 → 我再来一遍
```

代码是AI写的，鼠标是我点的，日志是我搬的。

折腾几轮才发现，自己成了AI和开发板之间的“人工接口”。

这次这个小工具想解决的，就是中间这段来回搬运。

**人可以照常用它烧程序、看串口；AI也可以通过配套技能，直接调用烧录、校验、调试和串口验证工具。**

---

## 一、先说清楚：DAP负责什么，TTL又负责什么？

这两个接口干的是不同的活。

| 接口 | 主要工作 | 开发时最常用的事情 |
| --- | --- | --- |
| CMSIS-DAP | 通过SWD连接目标芯片 | 烧录、校验、复位、断点和寄存器调试 |
| USB-TTL | 连接目标板UART | 看日志、发命令、查状态、验证应用协议 |

可以理解为：**DAP帮你把程序送进去、停下来检查，TTL帮你看看程序运行后说了什么、做了什么。**

接线关系如下：

```bash
电脑 / AI开发工具
        │
       USB
        │
MCPIOT DAP＋TTL扩展器
        ├── SWDIO / SWCLK / NRST ── 目标板调试接口
        └── TX / RX / GND ───────── 目标板UART
```

注意区分两块芯片：扩展器里有自己的主控，外面接的开发板上还有目标主控。正常开发时，DAP调试的是**外面的目标板**。

本文沿用产品交流中的“DAP Link”叫法，具体调试接口采用CMSIS-DAP。不要据此推断它具备拖盘烧录、所有DAPLink扩展功能，或支持任意芯片。目标是否可用，还要看SWD、电平和OpenOCD目标驱动。

---

![](https://developer.qcloudimg.com/http-save/yehe-11997417/9d89a69be79000ec90bcc44d34b25a95.png)

双通道连接：SWD调试与UART应用验证

## 二、第一种玩法：照常干活，给人用

先不谈AI，这个组合本身就适合单片机开发。

开发时最常见的两个动作是什么？

一个是下载程序，一个是打开串口看输出。

以前把调试环境搭起来，经常是这么一套：**一个独立USB Hub，一个ST-Link或DAP Link，再加一个USB转TTL。**

Hub接电脑，下载器和串口扩展器分别接Hub，再各自拉线去目标板。设备一多，桌上就是USB线、SWD线、串口线交叉在一起。换板、收桌子、带去现场，每次都得重新理一遍。

现在把Hub、DAP调试和TTL串口集成在一起，原来分散摆放的几件工具，可以集中连接。外接目标板需要的SWD线、串口线仍然要接，但少了独立设备之间来回串接的USB线，桌面更容易整理。

**对我来说，这种集成最直接的价值，就是把调试台上那堆零散工具收拢起来。**

### 2.1 原来一摊，现在一体：两张图更直观

实拍图片**/ 传统接法：**

![](https://developer.qcloudimg.com/http-save/yehe-11997417/d4b34c14b34d2f8a0d8b6e2d1ef87c0f.png)

独立Hub＋ST-Link / DAP Link＋USB转TTL

实拍图片 **/ 集成接法：**

![](https://developer.qcloudimg.com/http-save/yehe-11997417/f2ab3ec75c53a9a22e58cba7cc0a5047.png)

集成Hub、DAP与TTL，免螺丝接线

### 2.2 免螺丝接线，经常换板时更省事

除了把设备集成起来，接线端也采用了**免螺丝设计**。

调试时经常需要换目标板、换UART、临时加一根地线。以前拧端子还得找螺丝刀，现在不用反复拧紧、松开螺丝，接线和拆线更顺手。

这个细节看起来小，但对经常在开发桌和现场之间来回跑的人来说，**少带一件工具、少做几次重复动作，就能让调试过程利索不少。**

熟悉IDE的朋友，可以在支持CMSIS-DAP的开发环境里配置调试器；习惯命令行的朋友，可以使用OpenOCD。需要看应用日志时，再打开对应TTL串口。

这里有个容易被忽略的细节：**暂停目标CPU之后，目标应用的串口处理也可能停止。**

这时候发一条命令没回包，不一定是扩展器坏了，也可能只是目标程序正停在断点上。

所以，“DAP和TTL能同时连接”与“CPU暂停时应用还能正常响应”，是两回事。

---

## 三、第二种玩法：给AI一套真正能执行的工具

这次配套提供了一个专用技能：

```bash
MCPIOT_DAP_TTL_GO
```

SKILLS可以理解成给AI的项目操作说明，再配上能直接运行的工具。

它告诉AI的不是一句笼统的“你是单片机专家”，而是具体约定：

-   怎样识别这个扩展器的TTL接口。
-   怎样区分探针和下游目标芯片。
-   怎样调用烧录、校验和复位。
-   怎样通过TTL发送请求，并检查预期响应。
-   验证失败时，怎样用GDB继续定位问题。

技能包内带有Python操作脚本、AIR32/STM32F103目标配置、操作参考，以及运行文件和脚本目录。

### 3.1 支持哪些AI编程工具？

这套工具链的接入对象，包括 **Codex、Claude、Cursor、Kimi、TRAE、WorkBuddy、OpenClaw等AI编程工具和智能体环境**。

**技能负责告诉AI怎么做，Python、Debug和串口工具负责真正执行。** 底层调用方式不绑死某一家AI工具，开发者可以沿用自己习惯的编程环境。

例如，你可以让Codex执行烧录与串口验证，也可以在具备本地工具执行能力的Claude、Cursor、Kimi、TRAE、WorkBuddy或OpenClaw环境中接入这套流程。

各工具的技能目录、导入方式、终端权限和设备访问能力会有差异，不能把“使用同一套脚本”理解成所有平台都能原样导入、无需配置。这里只说明接入方式，不表示上述工具的每个版本都已完成逐项兼容性实测。

### 3.2 从一句需求，到实际执行

Python、串口依赖和AI工具的本地执行环境仍要准备好；源码级调试还需要GDB以及与目标镜像对应的调试符号。

安装到支持本地技能与工具执行的AI开发环境后，可以这样提出需求：

> 使用MCPIOT\_DAP\_TTL\_GO，把当前工程编译后的固件烧录到下游开发板，校验并复位运行，再通过TTL查询版本，确认运行的是本次构建，再测试串口收发1000次，看有没有丢包情况，最终生成测试报告。

这句话背后，已经可以拆成一串可执行步骤。

---

## 四、让AI找串口，不能靠“猜COM几”

这一点，我想单独说说。

开发电脑上插几个USB设备，串口号就容易变。今天COM9，换个USB位置，明天可能就不是它了。

更麻烦的是，设备管理器经常统一显示：

```bash
USB串行设备（COMx）
```

人还能挨个拔插确认，AI如果直接挑第一个串口，发错设备怎么办？

所以技能里的识别方式，是读取Windows的**“总线报告的设备描述”**，精确匹配：

```bash
TTL (USART1)
```

再结合USB序列号，区分插在电脑上的不同设备。

```bash
先确认“这是TTL接口”
        ↓
再确认“这是哪一块扩展器”
        ↓
最后得到当前COM号
```

工具已经提供端口发现命令：

```bash
python scripts/ttl_tool.py find
```

多块设备同时连接时，可以指定序列号：

```bash
python scripts/ttl_tool.py find --serial YOUR_USB_SERIAL
```

找不到唯一匹配，就先报告问题，不往未知串口里乱发探测指令。

**硬件自动化的第一步，不是让AI动作更快，而是先让它找对设备。**

---

![](https://developer.qcloudimg.com/http-save/yehe-11997417/b5983fa8b9a5af03bcaec030d0801e6f.png)

以接口描述和USB序列号定位TTL

## 五、第三种玩法：烧录之后，真的验证一下

以前说“下载成功”，通常指烧录工具没报错。

但开发过实际产品的朋友都知道：写进去的字节正确，不代表应用逻辑就正确。

程序可能没有跑到目标任务，波特率可能没设对，版本也可能拿错了。

DAP＋TTL组合的好处，就是能把后半段验证接上。

### 5.1 先烧录，再校验

以支持的AIR32F103目标为例，从技能目录执行：

```bash
python scripts/dap_tool.py --target air32f103 program target.hex
```

工具完成编程、校验和复位，并记录日志与镜像SHA-256。

如果拿到的是不带地址的BIN，就必须指定实际烧录地址：

```bash
python scripts/dap_tool.py --target air32f103 program target.bin --address 0x08000000
```

有Bootloader的工程，应用起始地址应按工程配置填写，不能照抄示例。

Cursor使用截图：

![](https://developer.qcloudimg.com/http-save/yehe-11997417/c5f8df122b2fbc2da517204884e9e95b.png)

### 5.2 再问目标板一句：你现在运行的是什么？

假设目标固件已经实现了版本查询命令，收到 `version` 后返回版本字符串，那么可以这样验证：

```bash
python scripts/ttl_tool.py exchange auto --ascii "version\r\n" --expect-ascii "v1.0"
```

这里的 `version` 是**目标应用协议示例**，不是扩展器替所有开发板内置的命令。实际项目可以换成AT命令、测试帧或自定义协议。

再往前走一步，可以让目标返回构建编号或唯一测试序号，避免“碰巧收到旧日志”也算通过。

于是开发流程变成了：

```bash
修改源码 → 编译 → DAP烧录 → 校验 → 复位
                                    ↓
                              TTL发送测试请求
                                    ↓
                              检查版本和返回值
                                    ↓
                       失败则定位、修改，再跑同一验证
```

**这才是我想要的闭环：AI交付的不只是代码，还有它拿到的验证证据。**

---

![](https://developer.qcloudimg.com/http-save/yehe-11997417/b7b38fa7f66e0f5eafa3cee3801ee89b.png)

从源码修改到目标响应的验证闭环

## 六、不只会下载：GDB还能帮AI看故障现场

串口没输出，怎么办？

过去经常是我打开IDE，打断点，截一张图，再把寄存器抄给AI。

有了CMSIS-DAP，支持本地调试工具调用的AI，可以继续接入GDB：

```bash
AI开发工具 → GDB → OpenOCD → CMSIS-DAP → 目标MCU
```

例如，在业务任务设断点、查看调用栈、读取关键变量，或检查异常状态寄存器。

一个简化的GDB过程：

```bash
file target.elf
target extended-remote localhost:3333
monitor reset halt
break main
continue
```

后续断点应落在实际需要检查的函数里。文件、函数和变量都要来自本次构建，不能拿旧ELF去解释新固件。

当然，工具能读到现场，不代表每个故障都能全自动解决。线没接好、电源不稳、芯片型号不对，仍然需要结合真实硬件判断。

但至少，AI不必每走一步都等人搬一次截图了。

---

## 七、里面跑的是什么？国产XiUOS（矽璓）

这一代固件还有一个值得聊的地方：引入了XiUOS相关内核能力。

XiUOS（矽璓）面向工业物联场景，北京大学官方发布介绍了它的研发与开源背景。有兴趣的朋友可以阅读[北京大学的开源发布说明](https://hcst.pku.edu.cn/info/1029/1511.htm "北京大学的开源发布说明")。

这里把工程范围说准确：**本项目移植的是XiUOS体系下XiZi内核的相关子集，包括抢占调度、任务管理、时钟和内存管理等基础能力。**

不是把文件系统、网络协议栈和全部工业物联组件一股脑装进一个USB扩展器。

为什么扩展器也要用RTOS？

因为它要处理的事情越来越多：USB通信、串口转发、控制台，以及不同固件版本中的脚本服务，都需要合理安排执行机会。

有了任务调度基础，可以把通信服务和其他业务分开组织。这里也别误会：RTOS不是“加上就再也不卡”的开关，USB中断、共享缓冲和阻塞时间仍然要认真设计。

固件还提供了简化控制台。通过TTL对应的USB串口发送：

```bash
/xiuos
```

进入后，可以使用该固件提供的命令查看任务和运行信息，例如：

```bash
help
ps
mem
uptime
```

这是扩展器自己的控制台。进入以后，该端口的输入会由本地控制台解释，不能同时把它当作下游应用的透明串口使用。

另外，**扩展器运行XiUOS，并不要求外接目标板也运行XiUOS**。目标板可以跑裸机程序，也可以使用它自己的RTOS。

---

![](https://developer.qcloudimg.com/http-save/yehe-11997417/085a58b755c9c8a2d562c745043ffc62.png)

XiZi内核子集与本地控制台

## 八、人用和AI用，有什么不同？

硬件接口相同，操作方式不同。

| 开发动作 | 人来操作 | AI配合技能操作 |
| --- | --- | --- |
| 找TTL串口 | 看设备管理器及设备描述 | 查询总线描述和USB序列号 |
| 烧录固件 | IDE或命令行下载 | 调用包内OpenOCD工具 |
| 校验镜像 | 查看下载日志 | 检查退出码、校验日志及镜像哈希 |
| 验证应用 | 串口助手发送命令 | 发送请求并匹配预期响应 |
| 定位故障 | 断点、变量窗口、寄存器 | 通过GDB读取相同类型的现场 |
| 留记录 | 人工整理 | 保存日志与JSON结果 |

我觉得有意思的地方在于：这两种方式可以混着来。

你在IDE里改代码，让AI跑回归测试；或者AI先改一版，你再接过调试器检查关键路径。

**工具交给AI一部分，工程判断仍然可以掌握在开发者手里。**

---

## 九、哪些地方，还得说清楚？

### 9.1 AI需要运行在电脑上

这不是一个在小主控里跑大模型的扩展器。

AI在电脑端理解需求、修改代码、调用工具，扩展器负责把这些操作接到真实硬件上。

### 9.2 不是什么芯片都能直接下载

CMSIS-DAP提供调试通信能力，烧录还需要目标芯片的Flash驱动与正确配置。技能目前配有AIR32F103和STM32F103配置，其他目标应按实际型号增加配置。

### 9.3 自动验证需要应用有可检查的结果

如果目标程序既没有协议响应，也没有可读状态，AI不能凭空知道功能是否正常。开发测试接口、返回构建版本、加入序号和校验，本身就是闭环的一部分。

### 9.4 擦除和保护不能随手自动处理

读保护、写保护、Option Byte和普通烧录是不同操作。连接失败时直接“解锁试试”，可能把目标里的程序和参数一起擦掉。

技能会区分这些操作；正常连接失败，不自动执行解除读保护或永久锁定。

---

## 十、我觉得哪些人会用得上？

| 用户 | 比较直接的用途 |
| --- | --- |
| 单片机工程师 | 下载和串口日志一起接，减少开发工具切换 |
| 用AI辅助写固件的开发者 | 把代码修改接到真实烧录与验证流程 |
| 小团队、创客 | 为重复的板级测试建立可复用流程 |
| 教学和实验用户 | 观察程序、断点和串口响应之间的关系 |
| 自动化测试开发者 | 用脚本统一记录目标身份、镜像和验证结果 |

偶尔烧一片程序，普通下载器就能完成工作。

如果经常重复“改代码、烧录、看日志、再修改”，DAP＋TTL配合AI技能的价值就会明显一些。

---

## 写在最后

从USB串口，到多接口转换器，再到这次DAP＋TTL，我更关心的是：开发工具能不能跟上开发方式的变化。

AI已经越来越会写代码了。

但嵌入式代码最终要在板子上运行，要面对接线、电源、中断和真实的外设。

**给AI接上调试接口和串口，让它能拿到硬件反馈，才有机会把“看起来对”推进到“实际验证过”。**

这就是这个USB转换器家族新成员想做的事。

人用，还是熟悉的下载器和串口。

AI用，多了一套能执行、能检查结果的硬件开发工具。

后续有了具体项目，再把完整的“修改代码—烧录—串口验证—故障定位”过程展开写一篇，会比单纯列参数更有意思。

**互动话题：** 如果让AI接管一个你最不想重复做的硬件调试步骤，你会先交给它哪一步？

配图由Canvas绘制并导出PNG；HTML已内嵌图片，可离线打开。示意图用于说明连接与流程，不代表产品外观。

一套连接，服务开发者与AI工具 国产RTOS【北大 XiUOS（矽璓）】｜提供AI SKILLS与调试工具 作者： 老码农Ewin 标签： 嵌入式开发 / CMSIS-DAP / 串口调试 / XiUOS / AI硬件开发 本文主角： MCPIOT USB 3.0 HUB＋DAP Link＋TTL扩展器 写在前面 先把这次的接口组合摆出来：一个设备里，集成3个USB 3.0 HUB扩展口、1个PD

USB扩展器家族新成员：人与AI都能用的USB 3.0 HUB+DAP Link+TTL扩展器 ----让AI自主闭环开发硬件：烧写、调试、日志分析

硬件

开发工具

人工智能

一套USB 3.0 HUB＋PD充电＋CMSIS-DAP调试＋USB转TTL集成扩展器，配套AI技能，支持DAP烧录、TTL串口验证、GDB定位，基于国产XiUOS内核，适配Codex、Cursor等工具，实现开发板调试闭环。

回归测试

内存管理

文件系统

硬件开发

Bootloader

单片机

调试器

智能体

WorkBuddy 

AI编程

OpenClaw

Windows

Python

JSON

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

USB扩展器家族新成员：人与AI都能用的USB 3.0 HUB+DAP Link+TTL扩展器 ----让AI自主闭环开发硬件：烧写、调试、日志分析-腾讯云开发者社区-腾讯云

USB扩展器家族新成员：人与AI都能用的USB 3.0 HUB+DAP Link+TTL扩展器 ----让AI自主闭环开发硬件：烧写、调试、日志分析

USB扩展器家族新成员：人与AI都能用的USB 3.0 HUB+DAP Link+TTL扩展器 ----让AI自主闭环开发硬件：烧写、调试、日志分析

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐