调试故事：从 printf 到 Flash 及其他

在 1990 年代，基本上有两种基于工具的解决方案，用于在真实硬件上调试嵌入式软件：一种是监视器调试器，一种在嵌入式系统内存中编程并响应外部调试器软件请求的软件. 以及在线仿真器，一个（大型）硬件，它通过自适应替换和仿真位于目标硬件中的微控制器/处理器。

图 1：1980 年代末的在线仿真。

监控调试器解决方案价格便宜，并实现了基本的调试功能；在线仿真器解决方案非常昂贵，使用复杂，而且适配经常不稳定且容易出错。作为回报，开发人员获得了对微控制器/处理器所有总线的完全透明和访问权限。那时，计时测量和代码覆盖率分析已经成为可能。然而，半导体制造商必须为此目的开发一种特殊的、所谓的带有额外引脚的仿真芯片。对所有相关人员来说都是一个关键的成本因素。

半导体的日益小型化和片上调试接口的引入对调试器作为开发工具本身的架构产生了重大影响。越来越多的以前在硬件中实现的功能现在在软件中实现。开发环境和调试器软件变得更强大，硬件更小，带宽和速度方面的性能不断提高。但是，今天调试的基本用例仍然相同。

硬件调试进化，瞄准调试的“圣杯”

从 printf 到“just” flash 到断点、实时监视和单步执行，这就是您可以简要描述调试的方式。原则上，调试用于驱动程序开发、板/硬件启动、启动过程等的开发和故障排除，作为“低级”、硬件相关开发的标准方法。一个调试器被迅速拿出来，将软件闪存到目标硬件上，开始执行或通过断点在代码中的某个点停止它，检查内存区域和寄存器或操作它们测试，读出调用堆栈等等。

在应用方面，它简单易懂，原则上大多数开发人员通过调试都可以理解。大多数时候，人们没有时间深入处理调试器本身，从而可能发现“调试的圣杯”，这些附加功能最终可以节省大量调试和测试时间。例如，在这种情况下，一种被低估的技术是追踪。它在不影响运行时行为的情况下提供对软件执行的洞察。因此，开发人员获得了硬件上软件执行的真实图像。可以发现软件中偶尔出现的错误和瓶颈。这只是调试器的许多替代用例的一个示例。

图 2：硬件调试——嵌入式软件开发人员的日常业务。

微控制器、处理器和 SoC 带来了新的挑战

调试的发展伴随着半导体的小型化、复杂性和速度的增加。在过去的 15 年中，嵌入式行业，尤其是汽车行业，在其产品中引入了许多附加功能，以满足当前和未来的环境法规，减少一般的车祸数量，通过分销更有效地开发和生产车辆跨多个电子控制单元 (ECU) 的功能，而不是按功能开发专用 ECU，并在竞争中脱颖而出。

为了实现这一切，汽车行业需要半导体制造商通过开发和生产更紧凑、更快的微控制器来满足他们的要求。

这是嵌入式多核微控制器的诞生，即具有两个或更多内核的控制器。ECU 中从单核架构向多核架构的转变给每个人带来了新的挑战。嵌入式软件工具供应商面临着新问题，从如何轻松访问多核 ECU 的所有内核，到如何在不同内核上分发嵌入式软件和遗留软件，这些内核运行效率最高，同时保持高性能。开发嵌入式软件的传统方式此时已经受到质疑。

随着高性能/计算平台和多核系统的引入，现在甚至更复杂的处理器架构被用于开发高度复杂的应用程序。调试在这里仍然扮演什么角色？

原则上，它仍然是基础。除了微控制器的内部闪存组件外，还必须运行 SoC 外部闪存组件。调试器首先帮助控制引导过程，然后在下一步中仔细检查这些处理器的各个部分和内核以及在这些设备上运行的软件。除了标准调试功能之外，由于这些软件系统的复杂性越来越高，时序分析、功能分析或 CPU 负载测量等分析选项也越来越多地被使用（图 3）。这样做的先决条件是所用半导体上的跟踪接口的可用性以及相应的调试器，其软件实现这些功能。

图 3：来自 iSYSTEM 的 winIDEA Analyzer；左边是记录的对象，右边是它们的时间相关性。 （点击展开）

半导体行业的技术发展正在改变软件开发过程，进而将调试器作为工艺工具的基本工具。

软件开发过程和标准

分布式开发团队、日益复杂的代码库、日益增长的功能需求、标准化和时间压力：即使在嵌入式软件开发中，在最短的时间内将可靠和安全的产品推向市场的挑战也只能通过更高程度的抽象和自动化。

因此，经典意义上的开发工具必须比以往更加通用。以前由微控制器专家专门用作与硬件相关的开发工具，现在越来越多地可以在各种软件开发情况中找到调试器。调试器仍然是通过标准调试接口连接到实际目标硬件，目的是开发和测试尽可能接近实际硬件的嵌入式软件。

除了简单地连接到目标硬件之外，调试器还提供更高级的调试功能，包括测试功能。在这里，开发人员可以跟踪正在运行的软件的执行情况。为此，可以检查程序状态，并在某些条件下停止程序的执行。这是在对被测软件的影响最小或没有影响的情况下完成的。专业的调试解决方案还可以实时记录软件中的过程（跟踪）、记录时钟周期范围内的执行时间以及评估与测试相关的软件处理部分（代码覆盖率）。

图 4：如今，调试器提供的 API 可通过平滑和自动化的工具转换来实现开发和测试流程。

为了让客户能够灵活地使用所有这些功能，调试器制造商提供了通用接口 (API)，可以将这些工具集成到客户的开发和测试过程中（图 4）。这些接口必须适合解决各种各样的任务（开发、测试、验证和验证软件和硬件）。这里的标准是支持编程（C、C++、C#、Java 等）和脚本语言（Python 等），以便从另一个（也是客户特定的）应用程序“远程控制”开发工具。基本上，该过程的一部分可以在开发和测试期间实现自动化。

此外，当今的调试器提供了所谓的“mini-HIL”功能（用于测试的硬件在环、测量和激励模块）来生成或测量数字和模拟信号，同时记录和关联程序执行. 这使得在软件开发过程中尽可能早地进行非常接近现实的测试成为可能。所有这些都是从已知环境中实现的，几乎是即时的，无需学习新的方法。

这些用于测试自动化的灵活接口的典型用例是持续集成 (CI)。CI 通过将开发人员的更改或新创建的代码集成到与团队共享的存储库中来支持敏捷/分布式软件开发和测试。为此目的，有几个合适的持续集成服务器，例如 Jenkins、GitLab、TeamCity、CircleCI 或 GitHub Actions。通过集成，通过内部或云中托管的 CI 软件触发一系列快速且高度自动化的步骤（称为“管道”）。管道通常包括并结合构建、静态分析、单元和系统测试。

图 5：持续集成基础设施的管道，包括构建、静态分析、单元测试、系统测试，最后是可交付产品。

经典调试器因此成为在真实硬件上进行测试的测试工具。

通常，软件也可以在 PC 平台上进行广泛的测试，与目标硬件无关。然而，并非所有潜在错误都在模拟环境中检测到：例如，所需的硬件外围通常不可用，或者应用程序的行为与真实硬件不同，时序行为不同，或者交叉编译器生成目标- 特定的目标代码，因此与用于测试环境的编译器的代码不同。

因此，有必要在早期尽可能接近真实硬件进行测试，以确保最终产品的正确功能以及应用程序的准确时序行为。

ISO26262 和 DO-178C 等安全标准会影响工具的功能范围以及向客户提供这些功能正确性的证明。特别是在航空领域，工具制造商被要求在工具认证方面进行合作已经有很长一段时间了——但最近在汽车行业也需要通过 ISO26262 进行合作。

为此，工具制造商必须为与特定用例相关的工具的功能正确性创建验证选项。这些可以是组织措施，例如开发过程的外部审计或独立第三方对工具的认证，或支持客户执行正确性证明的参考工具套件。上述使用调试器自动化测试过程的方法非常适合实施此类工具鉴定过程。

结论：更复杂的调试器，不断发展的新业务模型

调试器越来越多地变成了一个过程工具。调试器的基本功能找到了它们的普通应用，并辅以强大的分析功能。软件日益复杂，软件开发本身使用的大量软硬件工具及其相互依赖性，推动了工具制造商、芯片供应商和客户之间对知识转移和咨询服务的需求。

参与这些发展的各方之间持续和开放的沟通是成功的关键。今天，客户不再想购买工具，他们想随时随地使用它们。嵌入式软件开发和软件测试的新商业模式将发挥作用，其中工具、知识转移和咨询是一种常见的产品，最终是一种服务。正如软件行业所发生的那样，订阅业务模式也越来越适合全球嵌入式软件开发和测试。

审核编辑 黄昊宇