嵌入式软件开发中的硬件调试：我现在怎么重新看待仪器与协议选型

/ 嵌入式 / 作者：

作者：Felix （Haro 协作整理）

过去谈硬件选型，我们习惯先看带宽、采样率、通道数、存储深度。

这些指标当然重要。

但如果目标不只是“人坐在仪器前看波形”，而是希望把设备真正接入自动化流程，甚至让 AI 参与分析、联动测试和归因，那么另一套标准也会迅速变得同样重要：设备是否容易被程序稳定控制，是否能够把原始数据低损耗、结构化地导出来。

换句话说，传统调试流程里，工程师看的是 GUI、截图和波形窗口；而 AI 真正擅长处理的是文本、结构化数据、可重复调用的接口。

问题往往不在于 AI 会不会分析，而在于很多仪器默认提供的是“人类友好界面”，不是“机器友好接口”。

这也是为什么我现在会把“协议与工具链能力”一起纳入硬件选型：在面向 AI 自动化的场景里，传统硬件参数依然重要，但设备是否容易被程序控制、是否能稳定导出结构化数据，同样会直接决定后续自动化能走多远。

不是 AI 不会看波形，而是数据进不了工作流

很多人提到“AI + 硬件调试”时，第一反应是：能不能把示波器截图扔给模型，让它判断哪里不对。

这当然可以做一些辅助判断，但它解决的不是核心问题。

真正影响自动化上限的，是下面这条链路能不能打通：

  1. 仪器能否被程序控制
  2. 原始数据能否稳定导出
  3. 数据能否转成脚本和模型都能处理的结构化格式
  4. 分析结果能否再反过来驱动下一轮测试

一旦这条链路打通，AI 的角色就不再只是“看图说话”，而会变成一个真正参与测试闭环的分析层。它不只会读结果，还能根据结果继续“编程”设备状态。

举个很直观的例子：

  1. 第一次测量时，脚本发现示波器当前垂直刻度不合适；
  2. 自动化框架发 SCPI 指令调整 Vertical Scale；
  3. 仪器重新采样；
  4. 新的原始数据进入后续分析流程。

这个过程中，AI 并不只是被动接收截图，而是在一个可编排的链路里参与判断。

真正值得讨论的问题，不是“AI 能不能帮忙看波形”，而是：你的设备接口和工具链，是否允许它进入自动化闭环。

面向 AI 自动化，我会先看三类接入能力

如果从“自动化友好度”来拆，常见硬件接入方式可以先看三类能力：

  1. 标准协议能力 —— 例如 LXI / SCPI
  2. 统一工具链能力 —— 例如 sigrok / libsigrok / CLI 解码链
  3. 厂商优化能力 —— 例如面向高吞吐量场景的专有实现

这里有一个很重要的前提：第一类和第二类不是上下级替代关系，而是经常并列存在、各自解决不同问题。

比如，一台示波器可以主要通过 SCPI 做控制和数据拉取；而一台逻辑分析仪则更适合通过 sigrok-cli 做抓取和协议解码。它们并不是谁比谁“更高一级”，而是面向不同设备形态和不同自动化链路的两种入口。

真正的工程问题，不是强行把所有设备塞进同一协议，而是：你手上的设备是否至少具备其中一种可持续接入自动化系统的能力。

第一类：标准协议能力 —— LXI / SCPI

这一类是最理想的自动化入口之一。

典型代表是支持 LXI / SCPI 的示波器、电源、万用表等设备。对自动化系统来说，它们提供的是一种基于文本命令的稳定控制接口。很多动作——测量、查询、设置、触发——都可以通过脚本直接编排。

它对 AI 和自动化框架友好的地方主要在于：

  1. 语义清晰：文本命令天然可读，也容易被程序生成。
  2. 控制与读取统一：既能读数据，也能改设备状态。
  3. 远程友好：如果设备挂在 LAN / LXI 网络上，自动化系统不必贴着设备运行。

这意味着 AI 不只是能“读取测量值”，还可以在自动化系统里参与设备状态调整。

例如：

  1. 先读取一次波形数据；
  2. 发现量程不合适；
  3. 自动发 SCPI 指令调整垂直刻度；
  4. 再次采样并继续分析。

这就是闭环能成立的关键：设备不只是“会说话”，而且“听得懂命令”。

第二类：统一工具链能力 —— sigrok / libsigrok

这类能力不是靠仪器自己提供标准协议，而是通过统一驱动层和 CLI 工具，把原本分散、私有、各不相同的设备拉进脚本世界。

很多逻辑分析仪、低成本采集设备，并没有像 SCPI 那样成熟的标准控制接口。但只要它能被 sigrok / libsigrok 稳定支持，并且通过 sigrok-cli 导出数据和解码结果，它依然可以很好地进入自动化流程。

对自动化来说，这一层的核心价值不是“支持的设备多”，而是：它把原本封闭的设备，抽象成了统一可调度的命令行工具链。

它特别适合：

  1. 逻辑信号抓取
  2. I2C / UART / SPI 等中低频协议分析
  3. 把解码结果导出成文本、CSV、JSON，再做进一步处理

这里也要强调一点：sigrok 这一层和 SCPI 那一层是可以并列共存的。

在同一个自动化系统里，很可能出现这样的组合：

  1. 示波器走 SCPI / PyVISA
  2. 逻辑分析仪走 sigrok-cli
  3. 最后两路数据在上层统一汇总分析

所以它更像是“另一条可接入自动化系统的高速通道”，而不是 SCPI 的低配替代品。

当然，这一层也不是没有代价。

在高采样率、大数据量场景下，驱动层、USB 传输链路和解码过程本身都会增加系统复杂度。问题不只是“能不能抓到”，还包括“能不能稳定、可重复、低损耗地抓到”。

第三类：厂商优化能力 —— 以 DSView / DSLogic 为例

这一类不该简单理解为“私有协议所以不好”。

更准确的说法是：当标准抽象层在性能或吞吐量上不够用时，厂商往往会为了自己的设备做一套更贴近硬件能力的优化实现。这在工程上完全合理。

问题不在于它是不是私有，而在于：它是否仍然给自动化保留了入口。

如果某个工具虽然底层做了厂商专有优化，但依然提供 CLI 或脚本调用方式，例如 dsview-cli 这类入口，那么它仍然保留了接入自动化系统的价值。

所以真正需要权衡的不是“标准一定好、私有一定坏”，而是：

  1. 私有实现是否换来了你确实需要的吞吐量或稳定性；
  2. 它是否仍然允许你把控制和数据导出接进脚本链路。

从“波形”到“语义”，AI 真正需要什么数据

很多时候，工程师手上的原始信息其实已经足够判断问题，但这些信息停留在 GUI 或专有格式里，导致它没法进入自动化分析链路。

如果想让 AI 真正参与，就要先把数据转成它擅长消费的形式。

逻辑信号：从比特流到结构化文本

比如抓 I2C。

对人类来说，我们会在 GUI 里直接看 SDA / SCL 波形，再肉眼判断起始位、地址、应答位是不是正常。对 AI 来说，更合适的形式不是截图，而是已经解码好的结构化结果。

一个更实用的链路是：

  1. 用逻辑分析仪采样；
  2. 用协议解码器输出 JSON / CSV / 文本事件流；
  3. 再让 AI 分析哪里不符合预期。

这时候模型就不是在“看波形图片”，而是在读一串事件，例如：

  • 起始条件是否正常
  • 地址阶段是否有 ACK
  • 数据阶段是否出现 NACK
  • 哪一帧和预期寄存器访问序列不一致

模拟信号：从截图到采样数组

示波器也一样。

真正有价值的往往不是屏幕截图，而是设备内存里的原始采样点。只要仪器支持通过 SCPI 读取波形数据，就可以把它转成数组，再由脚本先做基础预处理，比如：

  • 电压范围归一化
  • 异常脉冲候选筛查
  • 边沿、周期、占空比等简单统计

之后再把筛过的结果或关键片段交给 AI 解释。

这里有一个很重要的边界：AI 不应该直接替代示波器软件或协议解码器，它更适合做“跨设备、跨日志、跨上下文”的解释层。

检测类工作，通常应该优先让脚本和规则先做第一轮；AI 更适合解释“为什么是这个问题”“和历史现象是否相似”“下一步应该测什么”。

一个更现实的三层架构

如果把这些东西放进一个可落地的自动化框架里，我更倾向于把它拆成三层。

1. 设备接入层

这一层负责和硬件说话。

  • 对 SCPI / LXI 仪器，用 PyVISA 或直接 socket 交互
  • 对 sigrok 生态，用 sigrok-cli
  • 对厂商 CLI，用 subprocess 封装调用

目标不是优雅，而是把每类设备都变成“脚本可调用对象”。

2. 数据整理层

这一层负责把不同设备出来的数据，统一整理成适合后续分析的结构。

例如：

  • 纯文本测量值
  • 协议解码结果
  • 原始采样数组
  • 时间戳和上下文元数据

最后都可以收敛到统一对象，比如 Numpy 数组、Pandas DataFrame，或者结构化 JSON。

3. 智能分析层

这一层才是 AI 最适合介入的位置。

它不负责直接替代设备或驱动，而是基于整理好的数据来回答更复杂的问题，例如：

  • 当前 SPI 时序为什么没有外设响应？
  • 这次失败和前几轮测试相比，最大的差异在哪里？
  • 结合电源波形和总线日志，最有可能的故障点是什么？
  • 下一步应该先改哪一个测试条件？

真正有价值的地方，是它能把原本分散在多个设备、多个日志、多个回合中的信息串起来。

未来硬件选型，我会先看“新三表”

如果未来嵌入式开发真的越来越走向自动化和 AI 协同，那么评价一个设备好不好，标准也应该比过去多一层。

除了传统参数表，我会额外先看这三件事：

1. 是否支持标准协议控制

最好是像 LXI / SCPI 这种成熟、可远程、可脚本化的接口。

2. 是否有稳定的 CLI 或脚本入口

比如 sigrok-cli、dsview-cli 这类工具链。没有 CLI，就很难真正接进自动化系统。

3. 原始数据是否容易结构化导出

如果一个设备只能导出截图、专有工程文件，或者必须人工观察，那它天然就更难进入 AI 闭环。

这三点并不会替代传统参数指标，但在自动化场景里，它们往往更早决定你未来能把系统推进到什么程度。

总结

过去我们看硬件，习惯先问：测得准不准、带宽够不够、通道多不多。

而当目标变成“让设备进入自动化系统，并让 AI 参与闭环分析”时，问题会变成：

  • 它能不能被程序稳定控制？
  • 它能不能把数据低损耗地导出来？
  • 它能不能把原始信号转成脚本和模型都能消费的结构化结果？

从这个角度看，协议能力不再只是一个附属功能，而是自动化上限的一部分。

所以如果今天让我重新看待硬件选型，我会把它从“参数表比较”变成“数据链路比较”。

不是哪台设备测得最漂亮，而是哪台设备最容易进入下一代自动化工作流。