写了个支持脚本化的 J-Link RTT 命令行工具（rttsh）， AI 在板调试、批量脚本验证、数据导出、CI ...

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

正文

各位好，写了个工具分享给大家，也顺便收集反馈。

背景是我自己做固件时的老问题：代码写完，烧进板子，开串口终端，敲几个命令，看看输出对不对，或者复制贴给 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 测试脚本可以参考。

目前局限