减少调试时间的 3 个技巧

There are a lot of potential changes that software development teams can make to decrease the time they spend debugging and get it into single-digit percentages.

工程师喜欢解决问题。这就是我们所做的。不幸的是，嵌入式软件工程师最大的问题之一是我们制造了很多问题，然后通过花费大量时间来修复它们（调试！）使自己成为英雄。嵌入式软件工程师花费 20% 到 40% 的时间进行调试的公司很常见！值得庆幸的是，团队可以做出很多潜在的改变来减少他们花费在调试上的时间，并将其降低到个位数的百分比。在本文中，我们将研究几个减少调试时间的技巧。

提示 #1 – 拥抱测试驱动开发 (TDD)

测试驱动开发是一种允许开发人员增量构建他们的生产软件的技术，他们依靠测试来指示他们编写的代码。例如，TDD 让开发人员首先编写一个测试用例，使其失败，然后只编写允许该测试用例通过的代码。然后重复该过程。

传统上，嵌入式软件开发人员会在测试之前编写整个代码模块。在几周内编写数千行代码是可能的。那么，到了测试它的时候，如果它不起作用，问题在哪里呢？只有天知道！开发人员必须煞费苦心地回顾代码并发现问题所在并修复它。执行此操作所需的时间可能相当可观。

另一方面，对于使用 TDD 的开发者来说，如果出现错误并在代码中注入了 bug，测试用例会立即告诉开发者！由于他们正在逐步编写代码，因此他们更有可能确切地知道他们所做的更改并可以立即解决问题。TDD 似乎需要更多时间来练习，但它创建了一组可以在回归测试中运行的测试用例，以确保一切都按预期工作。TDD 一石二鸟：减少调试时间和自动化测试。  

提示 #2 – 尽可能多地开发脱靶

当一个项目开始时，几乎每个嵌入式软件开发人员的第一反应就是获得一块开发板并开始编写嵌入式代码。不幸的是，在许多情况下，嵌入式代码并不是我们产品的差异化因素。这是应用程序代码。虽然许多应用程序代码最终需要与硬件交互，但许多模块可以脱靶开发，即在主机上。

开发脱靶代码为开发人员提供了许多减少每个调试周期所花费时间的机会。例如，通常，要为目标微控制器编写和测试代码，开发人员必须：

交叉编译代码

启动调试会话

通过 SWD 对设备进行编程

在目标上运行代码

通过在目标上运行代码来验证代码是否正常工作（还必须具有所有低级代码）。

如果代码是在主机上开发的，开发人员必须为主机编译它，然后使用单元测试工具、仿真器或自定义程序来运行正在开发的代码。如果发现问题，修复、重新编译并重新开始会更快。在嵌入式目标上，仅对目标进行编程就会使每个周期增加几十秒，更不用说单步执行代码的诱惑了。

脱靶开发/调试可能会产生特定的错误。但是，我现在编写了大约 75% 的代码偏离目标，并且发现我的速度更快、效率更高。我可以快速强制代码中的问题，确定原因，修复它，然后继续前进，而不是通过嵌入式目标跟踪问题。当然，有些事情会出现在目标上，而不会出现在主机上。

提示 #3 – 掌握调试策略

人类已知的效率最低的调试方法是单步调试代码行。不要误会我的意思，有时间和地点，但往往会浪费很多时间。不幸的是，嵌入式软件开发人员默认使用断点和单步调试。为了更好地调试，开发人员需要掌握现代微控制器上可用的其他调试策略。

今天，至少有八种不同的调试技术可供开发人员使用。这些技术从最简单到最复杂的顺序包括：

Watch / Expressions：为开发人员提供检查 CPU 和外设寄存器的能力。它们通常可用于监视变量、执行计算或在更改时停止 CPU。

断点：为开发人员提供在特定代码行上停止 CPU 执行的能力。高级断点可用于设置条件语句。

printf：为开发人员提供将字符数据打印到映射的串行接口的能力。根据实现，这可能会或可能不会影响实时性能。

断言：这些是用于验证程序中特定点的假设的条件语句。断言失败通常会停止 CPU 并提供失败断言的文件和行位置。 

Statistical Profiling：对应用程序中的各种寄存器进行定期采样，这些寄存器同时发生在其运行中。通常不会影响实时性能。例如，可能想要对程序计数器 (PC) 进行采样以了解正在执行的代码模块。

数据分析：对包含可变数据的各种内存位置进行定期采样。当与实时可视化工具一起使用来监控系统状态、感兴趣的变量变化等时，数据分析会非常有用。

任务和数据跟踪：使开发人员能够跟踪实时操作系统应用程序中的事件。因此，开发人员可以深入了解应用程序性能、任务延迟、运行时间等等。

指令跟踪：使开发人员能够记录在处理器上执行的每条指令。这可用于了解测试期间的代码覆盖率、调试编译器问题等。

掌握所有这些技术并知道何时使用它们可以大大减少当缺陷确实进入系统时用于调试的时间。

结论

可能会花费大量时间调试嵌入式软件。有时，调试时间是无法避免的；但是，在许多情况下，开发人员可能会花费比他们需要的时间更多的时间。我们已经探索了几个您可以进一步调查的领域，以减少您和您的团队花费在调试上的时间。如果您花费超过 20% 的时间进行调试，请在本周花一个小时确定您可以立即开始进行哪些更改，以控制您花在调试上的时间。

审核编辑 黄昊宇