嵌入式开发中调试器中的小技巧和窍门小结

嵌入式系统开发过程实际上就是一个调试诊断的过程，而且调试诊断将一直伴随着一个产品的终身，即使是最成熟的产品也偶尔会出现这样或那样的问题，这都需要开发人员去诊断、排查。

从只有几千字节存储空间的简单 8 位控制器，到现在先进的 32 位控制器，虽然微控制器经历了诸多演变，但是许多开发人员仍在使用老旧的工具，拖慢了开发周期。

设计人员若要适应当今快速发展且复杂多变的开发环境，则需要确保拥有合适的工具才能应对。他们需要嵌入式工具，以便监视芯片并查看其软件是否按照预期方式运行;他们还需要可指出错误或优化代码规模的工具，以降低其 BOM 成本。

现在有许多工具可以帮助他们降低整体开发成本，加快调试过程，从而缩短上市时间。本文将介绍一些这样的工具，然后说明如何通过它们获得最大收益。

利用专业调试器节省时间和金钱

开发人员编写的软件程序第一次试运行就正常工作非常少见。因此软件开发需要调试，所以对于软件开发人员来说，最重要的工具就是调试器。利用调试器，开发人员可以将应用程序加载到目标微控制器上，逐步检查代码，查看存储器和其他寄存器，并操纵硬件。

问题是，许多专业开发人员通常使用的调试器是其低成本开发板所附带的。这些调试器方便、便宜，而且在演示时表现完美。但是，在开发专业软件时，可能会出现以下限制：

断点有限

时钟速率降低

缺乏跟踪功能

功能极少

换言之，有时真是一分钱一分货：附送的简化工具集可能不是快速有效地开发和调试软件的最佳方式。

专业级调试器具有许多功能，可提高工程师的生产力，例如无限制的断点。许多调试器只能使用微控制器的内部比较器来设置断点，而在大多数情况下只有两个可用。在有数万行代码的复杂程序中，只有两个可用的断点可能会导致开发人员把时间浪费断点切换上，也可能会导致开发人员错过软件中的关键点，从而错过潜伏的漏洞。这样一来，可能会导致编码时间更长，反而增加了开发成本并影响了上市时间。

专业级调试器提供的算法不仅可以使用硬件断点，还可以使用软件和闪存断点，为开发人员提供了更多的灵活性，而且用来评估代码的断点数量几无限制。

当然专业级调试器不便宜。它们的价格可以轻松标到几百到几千美元。但它们为开发人员带来了不可计算的投资回报，并能使用多年，无需升级或更换。选择调试器时，开发人员应该问自己几个问题：

调试器的断点数是否无限制?

这是一款可以与几乎所有工具链和微控制器配合使用的第三方调试器吗?

五年后这个调试器还能使用吗?

这个调试器有很好的生态系统吗?

调试器的能力可以扩展吗?

因为符合上述标准而变得非常受欢迎的一款第三方调试器是 Segger J-Link。根据开发人员的需求，Segger J-Link 可提供不同的版本。其中包括 J-Link Base Unit、J-Link Plus、J-Link Ultra Plus 和 J-Link Trace(图 1)。

Segger J-Link 调试器型号比较图片

图 1：Segger J-Link 调试器型号比较。(：Segger)

使用调试器跟踪和分支检测来揪出潜藏的错误

高级调试器(通常也是最昂贵的)配备 ETM 跟踪连接器，可以获得大量跟踪数据，这是使用 JTAG 或 SWD 的标准跟踪无法实现的。

使用高级跟踪功能，开发人员可以将调试器与商业工具链(如适用于 ARM 的 Keil MDK-PRO)连用，来监视系统中的每一行代码在测试期间是否得到执行。如下例所示，针对 ARM 的 Keil MDK-PRO 与跟踪调试器一并运行，检测到了那些代码行在测试期间得到执行(图 2)。这种跟踪对于需要 100% 测试覆盖的安全关键型系统非常有用。在未测试代码之处，可能会潜藏错误并在以后导致问题。

在调试模式下运行的用于 ARM 的 Keil MDK-PRO 图片

图 2：在调试模式下运行并对软件执行分支分析的用于 ARM 的 Keil MDK-PRO。左侧的绿色块表示在测试期间得到执行的代码行。(图片：Keil)

如果开发人员不想购买成熟的跟踪工具，则可以使用 SWD 进行跟踪。在这种情况下，开发人员可以选择使用如 Segger 的 SystemView 或 Percepio 的 Tracelyzer 之类软件工具将跟踪信息流传输到在 PC 上执行的应用程序。这些跟踪系统通常在 RTOS 中工作，并且需要几行代码来设置跟踪任务、捕获数据并将其发送到调试器，然后再发送到 PC 上。

显示软件跟踪的输出示例(图 3)。开发人员可以使用这些工具来检测诸如优先级转换、死锁、线程饥饿以及许多在复杂系统中可能遇到的其他问题。每个任务都有一条生命线，显示其何时就绪、何时执行、何时完成，以及在此期间可能发生的任何事件，例如发出和接收信号。

专业开发人员需要这样的细节，同样地，也要求他们使用的调试工具能够检索这类信息。

Percepio 的 Tracealyzer 图片

图 3：使用如 Percepio 的 Tracealyzer 之类工具检查软件操作，并查看执行时间和时间长短。(图片：Digi-Key)

最大限度利用调试器的技巧与窍门

调试工具有很多功能，但有时可能受限于为应用选择的微控制器。开发人员需要了解其调试器的功能，并要将其与微控制器正确配对。现今的许多调试器都可与 ARM? Cortex?-M 微控制器配合使用，开发人员在调试这些系统时应考虑以下几个因素：

避免通过 UART 进行 printf。而应使用 ITM 端口来获得更好的性能

不要逐条查看代码，使用高级断点来提高调试效率

选择一个通过服务器控制的调试器，以便为多个应用提供调试数据，即自定义分析仪、跟踪、调试环境等等。

调整调试器使用的默认时钟速率，因该速率通常比最大值慢得多

在开发周期的早期阶段设置跟踪，以建立比较基准

使 SWO 能够从系统获取更多信息

在硬件、软件和闪存断点之间进行选择性选择，以最小化实时性能影响

使用这些技巧可以帮助开发人员从调试器及其调试会话中获取更多信息。

使用商业编译器降低成本

GCC 是一款极受欢迎且大获成功的编译器。它与商业工具相比有一个优点就是免费!免费并不意味着编译器的质量和输出将产生与商业工具同等的可执行代码。事实上，在许多情况下，将 GCC 与商业编译器(如用于 ARM 的 Keil MDK-PRO 或 IAR Embedded Workbench)进行比较，得出的结果是，GCC 使用的代码规模更大，占用的 RAM 空间更多。Renesas 甚至在他们的 Synergy 平台规格书中显示了这一点(图 4)。

在图中，Renesas 使用 EEMBC CoreMark? 对其编译器进行了基准测试，显示了 IAR 编译的代码比 GCC 编译的代码更快。

基准测试还显示，使用商业级编译器可以显着减少代码规模。乍一看，开发人员可能会认为购买诸如用于 ARM 的 Keil MDK-PRO 之类工具不值得投资，而应该使用 GCC。但是，当开发人员使用包含 128 KB 代码空间的微控制器(如 NXP MK20DX128)并发现使用 GCC 应用程序需要 132 KB 时，会发生什么?

若发生这种情况，开发团队就被迫要寻找一个具有足够内存但却更为昂贵的引脚兼容器件，如 NXP MKD20DX256。如果该公司只能生产适量的产品，那么每年花在 MCU 上的成本可能会超过最初投资于商业编译器上的成本。

使用商业编译器也有其他优势，有助于降低成本，例如：

代码分析功能，如分支检测

软件复杂性测量

高效生成代码

卓越的调试工具和功能

技术支持

集成到驱动程序库和框架