正文 各位好，写了个工具分享给大家，也顺便收集反馈。 背景是我自己做固件时的老问题：代码写完，烧进板子，开串口终端，敲几个命令，看看输出对不对，或者复制贴给 AI 。单次一两分钟，但改一处就要来一遍，回归全靠记忆，经常漏。想放 CI 里，又会遇到： UART 往往被业务日志占用，或者根本没引出； 串口在 CI 里不好枚举，多板并行更麻烦； 烧录要另一个工具，和验证流程对不上。 后来发现我这场景下 RTT 很合适：SEGGER J-Link 的 RTT 走调试探针，不占外设。但是 RTT-Viewer 不咋好用，缺的是一个顺手的命令行封装，于是写了 rttsh （当然是鞭打 AI ）。 它是什么 一个 Windows 命令行工具（.NET ，依赖 JLink DLL ），核心能力三块： 提供 TUI 交互式 RTT 终端； 发送一行命令并等待应答： rttsh send "led r on" --chip STM32H743XI --wait 300 ； Lua 脚本验证，send / expect / 断言输出和时序 rtt.send("led g toggle") rtt.expect("LED g toggled", 500) 烧录/擦除也在支持： rttsh flash download xxx.hex 。这样 CI 里"编译 → 烧录 → 脚本验证"一条流水线搞定。 MCP 固件借 RTT 控制台暴露命令，主机侧能收发文本，那 AI 编码代理其实也能用。所以做了 rttsh mcp ，八个工具（ connect / send / expect / mem_read 等），Claude Code 或 Cursor 配上之后，可以自己烧录、自己敲命令、自己看板子的真实应答来验证它写的固件。我自己的体验是，AI 说"这个功能没问题"和板子说"没问题"是两回事，现在可以让板子说了算。 仓库里有一个示例工程和 23 个针对的 Lua 测试脚本可以参考。 目前局限 目前仅支持 Windows （依赖 JLink_x64.dll ），Linux 在计划中； 只支持 J-Link 系列探针，DAP-Link / ST-Link 不行（未来通过引入 probe-rs 实现更多支持）； 地址： https://github.com/z3oya/rttsh 欢迎拍砖，有问必回。

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/26 22:23:03