怎么读这一卷

主线位置：三条主线的总览。本页把命令、访问、调试三条主线各画一遍，标出每一步落在哪个文件、哪一章；再说明本卷没有开发板时怎么做实验，页面上的标注是什么意思。

flowchart TB
  start[从这里开始] --> q{读这一卷为了什么}
  q -->|会用| u1[01 全景]
  u1 --> u2["06 烧录、07 RTT"]
  u2 --> u3["10 和 embassy 连起来"]
  u3 --> u4[12 常见坑]
  q -->|读懂实现| all[00 到 13 按顺序]

锁定版本

源码链接都用 tag，形如 https://github.com/probe-rs/probe-rs/blob/v0.32.0/probe-rs/src/probe.rs#L669。想在本地对照：

git clone https://github.com/probe-rs/probe-rs
cd probe-rs
git checkout v0.32.0

写作时上游 main 已经比 tag 多了 313 个提交。本卷的每一处行为、每一个行号都只对 0.32.0 负责；读 main 看到的代码可能不一样。

三条主线

每一页开头都会标出本页在哪条主线上。

命令主线（probe-rs run fw.elf）：从敲下命令到终端上出现第一行 defmt 日志。

flowchart TB
  main["main：注册 ESP、Linux 插件"] --> rpc["run_app：本进程起 RPC 服务端"]
  rpc --> runcmd["cmd/run.rs：Cmd::run"]
  runcmd --> sel["cli::attach_probe：先 select_probe"]
  sel --> att["RPC attach：Probe::attach_with_registry"]
  att --> sess["Session::new：序列、DP、AP、核"]
  sess --> fl["cli::flash：FlashLoader::commit"]
  fl --> mon["cli::monitor：RunLoop::run_until"]
  mon --> poll["每 100 ms：查 halt、读 RTT"]
  poll --> dec["客户端：defmt 解码、打印"]

访问主线（一次 32 位读，从 API 到线上）：core.read_word_32(0x2000_0000) 最后变成线上的哪几个 SWD 包。

flowchart TB
  api["Core::read_word_32"] --> armv7["Armv7m 的 CoreMemoryInterface"]
  armv7 --> adi["ADIMemoryInterface::read_32：写 TAR、读 DRW"]
  adi --> sel["ArmCommunicationInterface：需要时先写 DP SELECT"]
  sel --> raw["RawDapAccess：raw_read_register / raw_write_register"]
  raw --> dap["CMSIS-DAP：batch_add 攒成一个 DAP_Transfer"]
  raw --> poly["位级探针：polyfill 拼出 46 位的 SWD 包"]

调试主线（停下来、看得懂）：前半段在本卷 03 部分，后半段在 08 调试信息、09 调试服务器。

flowchart TB
  halt["DHCSR：C_HALT、C_STEP"] --> bp["FPB：FP_CTRL、FP_COMPn"]
  bp --> why["DFSR：停下的原因"]
  why --> regs["DCRSR / DCRDR：读寄存器"]
  regs --> unwind["probe-rs-debug：CFI 栈展开、异常帧"]
  unwind --> vars["VariableCache：变量"]
  vars --> dapsrv["DAP server：VS Code 请求"]

阅读路线

• 只想会用：读 01 全景，然后 06 烧录、07 RTT、10 和 embassy 连起来、12 常见坑。读完能配好 cargo runner 和 VS Code，知道常见报错从哪来。
• 想读懂实现：按顺序读。02 探针层和 03 ARM 调试架构是访问主线和调试主线的前半段，后面各章都会链回来；08 调试信息是本卷另一个重点。

摘自 probe-rs 的代码片段一律保留原来的格式（4 空格缩进），方便和原文件对照；本站自己写的实验代码用 2 空格缩进。

前置知识

这一卷默认你写过 Cortex-M 上的 Rust 固件，至少知道下面几件事。它们在 embassy 卷里从固件一侧出现过，这里只列 probe-rs 会碰到的部分：

调试端口一侧的知识（SWD、DP、AP）本卷从头讲，不需要先读 ARM 的规范。

没有开发板时怎么做实验

本机没有调试探针和开发板。本卷的实验分五类，页面上会写明用的是哪一类：

第四种办法是本卷的主力：探针 trait 是公开的，ArmCommunicationInterface::create 也是公开的，所以可以在库外接上一个假的探针，让 probe-rs 的原生代码一路跑到「线上」。用它测出来的事务数、周期数都注明「模拟目标」，它们反映的是 probe-rs 的代码行为，而不是硬件。

页面上的标注：

• 待实测：结论需要真硬件，本机没法验证。这些项登记在内容仓库的硬件待测清单里，有了板子集中测一次再回填。
• 未核实：从源码或文档推出来、但没有实验支撑的说法。
• 实验输出里的本机路径一律改写成 <项目>/src/...、<cargo registry>/... 这样的形式。

目录

小结

• 全卷锁定 tag v0.32.0（48f5e4d5，2026-07-22）；probe-rs-mi 在同一个 tag 里，版本是 0.2.0。
• 命令主线：插件 → 本地 RPC → 选探针 → attach → 烧录 → 每 100 ms 轮询 halt 与 RTT；访问主线：read_word_32 → TAR / DRW → SELECT → CMSIS-DAP 批处理或 polyfill 位流；调试主线：DHCSR、FPB、DFSR、DCRSR → DWARF 展开 → DAP server。
• 只想会用读 01、06、07、10、12；想读懂实现按顺序读，02、03、08 是重点。
• 没有开发板：用无硬件命令、gdb --dry-run + lldb、FakeProbe，以及自己写的软件模拟 SWD 目标；需要真硬件的数字写「待实测」。