1. 嵌入式Rust调试工具链概览
调试嵌入式Rust程序，说白了就是跟硬件打交道。你写好的代码烧进去，跑起来不对，这时候就得靠工具来「看」里面发生了什么。我刚开始用Rust做嵌入式时，踩过不少坑——最惨的一次是程序跑飞了，连个打印都出不来，折腾了两天才发现是中断优先级配错了。
所以这一章，我们先摸清工具有哪些，各自擅长什么，怎么选。后面实战时才不会手忙脚乱。
1.1 调试工具全景图
嵌入式Rust调试，核心就三件事：连接目标板、控制执行流、获取运行时数据。围绕这三件事，工具链分成了几个层次。
核心调试链路：
PC端调试器（GDB/lldb） → 调试代理（OpenOCD/probe-rs） → 调试硬件（J-Link/ST-Link/DAPLink） → 目标芯片
下面这张图把整个工具链的关系画清楚了，我建议你先看一遍，有个整体印象。
1.2 核心工具逐个说
1.2.1 GDB — 调试器的「老大哥」
GDB 是 GNU 的调试器，嵌入式调试的基石。它支持断点、单步、变量查看、内存读写、反汇编……几乎所有你能想到的调试操作。
在 Rust 嵌入式里，GDB 配合 rust-gdb 或 gdb-multiarch 使用。我个人习惯用 gdb-multiarch，因为它能同时处理 ARM 和 RISC-V 目标。
小技巧： 在 GDB 里加载 Rust 符号表时，记得用 file target/thumbv7em-none-eabihf/debug/your-app，这样能看到 Rust 源码级别的调试信息，而不是只有汇编。
1.2.2 OpenOCD — 老牌调试代理
OpenOCD（Open On-Chip Debugger）是开源调试代理的「老将」。它支持 J-Link、ST-Link、FTDI 等几十种调试器，配置灵活但稍显复杂。
我记得第一次配 OpenOCD 时，光找正确的配置文件就花了半小时。后来发现，大部分开发板厂商都会提供现成的 .cfg 文件，直接 openocd -f board/stm32f4discovery.cfg 就能用。
# 启动 OpenOCD 连接 STM32F4 Discovery
openocd -f board/stm32f4discovery.cfg
# 然后在另一个终端启动 GDB
gdb-multiarch -q target remote :33331.2.3 probe-rs — Rust 原生的新秀
probe-rs 是用 Rust 写的调试代理，完全不需要 OpenOCD 那套配置。它原生支持 CMSIS-DAP、J-Link、ST-Link，而且跟 cargo 集成得非常好。
用 probe-rs 烧录和调试，一条命令搞定：
# 烧录
cargo run
# 启动 GDB 调试
probe-rs gdb --chip STM32F407ZGTx我的建议： 如果你用 Rust 做新项目，优先考虑 probe-rs。它省去了 OpenOCD 的配置烦恼，而且对 Rust 生态的支持更原生。但如果你需要调试老芯片或特殊调试器，OpenOCD 仍然是更稳妥的选择。
1.2.4 ITM — 硬件级追踪输出
ITM（Instrumentation Trace Macrocell）是 ARM Cortex-M 内核内置的追踪模块。它通过 SWO（Single Wire Output）引脚输出调试数据，带宽高、对实时性影响极小。
ITM 的典型用法是替代 println!：
// 使用 rtt-target 或 itm crate
use rtt_target::{rtt_init_print, rprintln};
fn main() {
rtt_init_print!();
loop {
rprintln!("Hello from RTT!");
// 延时
}
}注意： ITM 需要芯片支持 SWO 引脚，且调试器必须连接 SWO。不是所有开发板都引出了 SWO 引脚——我吃过这个亏，焊了根飞线才搞定。
1.2.5 RTT — Segger 的极速日志
RTT（Real-Time Transfer）是 Segger 推出的调试输出技术。它利用芯片的 RAM 作为环形缓冲区，调试器通过 JTAG/SWD 直接读取，速度比 ITM 还快。
在 Rust 里用 RTT，通常借助 rtt-target crate：
// Cargo.toml
[dependencies]
rtt-target = { version = "0.3", features = ["cortex-m"] }
// main.rs
use rtt_target::{rtt_init_print, rprintln};
fn main() {
rtt_init_print!();
rprintln!("RTT is working!");
}1.3 工具选型对比
选工具没有银弹。我根据实际项目经验，整理了一张对比表，你直接对着看就行。
| 工具 | 适用场景 | 优点 | 缺点 | 我的推荐 |
|---|---|---|---|---|
| GDB | 所有调试场景 | 功能最全，生态最成熟 | 命令行操作，学习曲线陡 | 必学，调试基本功 |
| OpenOCD | 多调试器、老芯片 | 兼容性极强，配置灵活 | 配置复杂，启动慢 | 备选，特殊场景用 |
| probe-rs | Rust 新项目 | 原生 Rust，配置简单，cargo 集成 | 对老调试器支持有限 | 首选，新项目推荐 |
| ITM | 低开销日志输出 | 硬件级，不影响实时性 | 需要 SWO 引脚，配置稍烦 | 性能敏感场景用 |
| RTT | 高速日志输出 | 速度极快，无需额外引脚 | 占用 RAM 缓冲区 | 日常调试首选 |
1.4 我的选型建议
如果你刚开始学嵌入式 Rust，我建议这样搭配：
- 调试代理： 用
probe-rs。省心，少踩坑。 - 日志输出： 用
RTT。速度快，配置简单，不需要额外硬件。 - 断点调试： 用
GDB+probe-rs gdb。遇到复杂 bug 时，断点比日志高效得多。 - 性能分析： 用
ITM。需要精确测量时间或分析中断延迟时，ITM 的硬件级追踪不可替代。
避坑指南： 我曾经在一个项目里只用 println! 调试，结果发现程序跑飞时连最后一条日志都没打印出来。后来换成 RTT，问题立刻定位——是中断嵌套导致栈溢出。所以，别在正式调试时用 UART 打印，它太慢了，会掩盖时序问题。
1.5 本章小结
嵌入式 Rust 调试工具链，说白了就是「PC 端调试器 + 调试代理 + 调试硬件 + 数据输出」四层结构。GDB 是核心，probe-rs 是 Rust 生态的利器，ITM 和 RTT 是获取运行时数据的两大法宝。
选型时记住一句话：新项目用 probe-rs + RTT，复杂场景加 GDB，性能分析上 ITM。 后面几章，我会带你一个个工具上手实战，把每个工具的用法和坑都讲透。