工程师喜欢解决问题。当然，这就是我们所做的。不幸的是，嵌入式软件工程师面临的最大问题之一是我们自己制造了很多问题，然后花费大量时间修复它们，最终让自己成为英雄（在调试方面！）。许多公司的嵌入式软件工程师将20-40%的时间花在调试上。值得庆幸的是，从团队的角度来看，可以做出很多潜在的改变，以减少他们花在调试上的时间，并将时间百分比压缩到个位数。在本文中，我们将了解一些减少调试时间的技巧。技巧1-测试驱动开发(TDD)测试驱动开发是一种允许开发人员逐步构建其产品软件的技术，依靠测试来指示他们编写的代码。例如，开发人员首先编写一个测试用例，如果测试失败，则编写新的代码以通过测试。然后重复这个过程。传统上，嵌入式软件开发人员在测试之前编写整个软件代码模块。数周内可能会编写数千行代码。到了测试代码的时候，如果它不起作用，问题是什么？只有上帝知道！开发人员必须煞费苦心地审查代码，找出问题所在并加以修复。执行此操作所需的时间可能会很长。另一方面，对于使用TDD的开发人员来说，如果出现问题并将错误注入代码，测试用例会立即告诉开发人员！由于编写代码的逐步过程，因此更有可能确切地知道程序的哪一部分发生了什么变化，并能够立即解决问题。TDD似乎需要更多时间来验证，但是通过创建一系列可以在回归测试中运行的测试用例来确保一切都按预期工作。TDD功能达到了以一石二鸟的目的：减少调试和自动化测试的时间。技巧2-尽可能不依赖机器进行开发当项目开始时，几乎每个嵌入式软件开发人员的第一反应都是拿到开发板并开始编码。不幸的是，在许多情况下，嵌入式软件代码并不是产品与竞争对手的差异化因素，不同之处在于应用程序代码。虽然许多应用程序代码最终需要与硬件交互，但许多模块可以独立于主机环境开发。实施无机器代码开发为开发人员提供了许多机会来减少每个调试周期所花费的时间。例如，通常要为目标微控制器编写和测试代码，开发人员必须执行以下操作：1.交叉编译代码2.启动调试会话3.通过SWD对设备进行编程4.在目标上运行代码machine5.通过Runonthetargetmachine验证代码是否有效（同样必须有所有Low-Level代码）如果代码是在宿主机上开发的，开发者必须在宿主机上编译代码然后使用用于运行正在开发的代码的单元测试工具、模拟器或自定义程序。如果发现问题，修复、重新编译并再次开始测试要快得多。在嵌入式板上，仅编写目标程序就可以使每个周期增加数十秒，更不用说单步执行代码了。没有机器依赖性的开发/调试可能会产生特定的错误。从我现在写了大约75%相关代码的例子来看，我发现会有更快更高效的效果。我可以快速定位代码中的问题，确定原因，修复它，然后继续调试，而不是仅仅跟踪嵌入式板上的问题。当然，有些问题会出现在板子环境上，不会出现在上位机上。技巧3-掌握您的调试策略我们所知道的效率最低的调试方法是单步调试您的代码。但是不要误会，有特定的程序运行时间和发生位置，这往往会造成很多时间的浪费。不幸的是，嵌入式软件开发人员通常默认使用断点和单步调试的解决方案。为了更好地调试，开发人员还需要掌握现代微控制器上可用的其他调试策略。目前至少有八种不同的调试技术可供开发人员使用。下面按从简单到最复杂的顺序列出了这些技术：Watch/Expressions：为开发人员提供检查CPU和外围寄存器的能力。它们通常可用于监视变量、执行计算或在更改时停止CPU。断点：为开发人员提供在特定代码行停止CPU执行的能力，高级断点功能可用于设置条件语句。打印：为开发人员提供将字符数据打印到映射的串行接口的能力，有一定概率影响实时性能。断言：用于验证程序中特定点的假设的条件语句。断言失败通常会暂停CPU并提供失败断言的文件和行位置。统计分析：在运行的应用程序中对各种寄存器进行定期采样。通常不影响实时性能。例如，您可能想要对程序计数器(PC)进行采样以查看正在执行哪个代码模块。数据分析：定期对包含可变数据的各种内存位置进行采样。当与实时可视化工具一起使用以监视系统状态、感兴趣的变量变化等时，数据分析会非常有用。任务和数据跟踪：使开发人员能够跟踪实时操作系统应用程序中的事件。因此，开发人员可以深入了解应用程序性能、任务延迟、正常运行时间等。指令跟踪：使开发人员能够记录在处理器上执行的每条指令。这可用于了解测试期间的代码覆盖率、调试编译器问题等。了解所有这些技术并知道何时使用它们可以大大减少异常发生和进入系统时调试所花费的时间。结论我们可以在开发阶段花费大量时间调试嵌入式软件代码。有时调试时间是不可避免的；但在许多情况下，开发人员可能会花费比预期更多的时间。我们探索了几个领域，您可以进一步调查这些领域以减少您和您的团队花费在调试上的时间。如果您花在整个软件周期调试上的时间超过20%，请在本周花一个小时来确定您可以立即调整和优化上述哪些区域，以控制花在调试上的时间。
