和 embassy 连起来

本站自己不跑嵌入式代码，所以这一部分代替其他卷的「在本站中」：把 embassy 卷的固件接到 probe-rs 的工作流上。embassy 卷的实验跑在 QEMU 的 b-l475e-iot01a（STM32L475VG）上，输出走 semihosting；这里讲换成真板子、换成 defmt 之后，probe-rs 这一侧发生了什么。三章：

1. cargo runner 与 defmt 三件套：runner = "probe-rs run --chip …" 之后 cargo run 变成什么；defmt、defmt-rtt、panic-probe 各自往 ELF 和 RAM 里放了什么，probe-rs 读哪一样；probe-rs run 怎么认出 embedded-test 的固件、一条条跑用例。
2. 从 QEMU 换到真板子：embassy 卷的 ticker 固件改成真板子版本要动的六处（运行器、链接脚本、HAL 补丁、时间驱动、日志、panic），改完离线编译通过；debug::exit 在 probe-rs 下照样能结束 run。
3. VS Code 调试配置：launch.json 的每个字段对应 DAP server 里哪个结构体的哪个字段，哪些有默认值、哪些组合会被拒绝；RTT 窗口默认不开。

flowchart TB
  fw["embassy 固件：defmt、defmt-rtt、panic-probe"] --> cargo["cargo run / cargo test"]
  cargo -->|"runner：probe-rs run --chip"| run["probe-rs run：烧录、轮询"]
  run --> rtt["读 _SEGGER_RTT，defmt 在客户端解码"]
  run --> hf["panic-probe：udf 进 HardFault，打印调用栈"]
  run --> et["embedded-test：每个用例复位一次"]
  vscode["VS Code：launch.json"] --> dap["probe-rs dap-server"]
  dap --> rtt

本部分的实验都不需要硬件：固件只交叉编译（thumbv7em-none-eabihf，依赖从本机缓存离线取），用目标文件工具看 ELF 里有什么，再用本机的 probe-rs 0.32.0 跑一次 cargo run，看它停在哪一步。固件真正跑起来以后的输出（defmt 日志、HardFault 的调用栈、embedded-test 的报告、VS Code 里的断点）待实测，已登记在硬件待测清单。