嵌入式系统调试 - 我应该使用输出/日志文件吗？答案

【问题标题】：Embedded system debugging - Should I use an output/log file?嵌入式系统调试 - 我应该使用输出/日志文件吗？
【发布时间】：2015-03-05 17:16:08
【问题描述】：

我对嵌入式系统相当陌生，但对编程并不熟悉。

我们在应用程序中管理大量不同数据结构的列表，我们用从传入的字符数组解析的数据填充这些数据结构。对于调试，查看每个结构的手表似乎不太实用，我考虑构建功能以将结构中包含的数据打印到文件中，因此我可以轻松比较预期结果与结果。这是你会在嵌入式系统中做的事情吗？我还有哪些其他选择？

为了避免增加代码大小，仅包括调试版本。系统是stm32F2xx和IDE keil uVision。

谢谢！！

【问题讨论】：

“嵌入”涵盖了许多罪恶，老实说，我不清楚您为什么要征求我们的许可。一般来说，您应该继续使用任何您认为有用的调试工具，但您期望这个工具会产生什么不利影响？作为记录，我发现这种技术在嵌入式世界中很有用。
我想我可能会做类似here 或here 之类的事情
@doynax 我的问题正是：“如果有的话，我可能会产生哪些不利影响”。我想你已经回答说你确实使用了这种技术。谢谢。
目标上是否真的有文件系统？如果您腾出空间，那就可以了；否则，将其从调试 UART 或 USB 接口（可选，或根据明确请求）发送出去，如果需要，将其直接发送到开发系统上的文件会更有意义。

【解决方案1】：

我很少将工具链的调试器用于我的嵌入式工作，除非我面临一个非常困难的问题或提出一个板。相反，我通常对设备的一个串行端口进行“printf 调试”，并在主机 PC 上的串行终端程序（例如putty）中查看输出。

这使我可以通过优化进行编译并去除生成的二进制文件中的非必要信息，同时仍然监视我的程序的执行和内存。我的工具库中有一些实用程序函数可以使这种调试变得高效，我包装了跟踪/调试代码#ifdef TRACE 或类似代码以确保此类代码不会最终出现在我的发布版本中。

我不知道在这个领域工作的其他人，但这对我很有效，老实说我不知道更好的方法。

【讨论】：

【解决方案2】：

在将纯数据处理代码与您的嵌入式应用程序集成之前，在 PC 上的测试框架中开发、调试和单元测试纯数据处理代码通常更简单；只留给您调试 I/O 驱动程序、调度和在目标上实时处理的任务。

STM32 数据类型大小和字节序与 32 位 x86 编译器相同，因此数据处理代码的可移植性通常没有问题。但是，您可能要注意浮点数据，因为 ARM 编译器的软件浮点结果可能与 x86 硬件浮点的结果可能不完全相同。

当然，如果您打算将实际结果与确实建议使用单元测试框架的预期结果进行比较。您还可以从更大的数据吞吐量中受益，因此您可以在目标上执行更多的测试。然后，您可能只需要对目标进行最少的测试，以验证结果是否与单元测试行为相当。 32位

【讨论】：

感谢克利福德。这本来是我要做的第一件事。然而，在这个项目中，这种方法将涉及剥离与 STM32 相关的代码的 fw（包括、flash_write 调用等），这需要很长时间！
您无需剥离此类调用，只需为它们实现测试存根即可。例如，闪存读/写调用可以简单地与使用文件系统存储数据的实现一起存根。如果您在设备层和应用程序层之间有一个清晰的区别，那么这当然是最简单的，这样可以存根的高级函数更少，这在任何情况下都是很好的做法。例如，如果您的应用程序级代码中充斥着非常低级的 STM32 标准外设库或 ARM CMSIS 调用，那么您将遇到困难，并且在任何情况下修复都会带来好处。
恐怕到处都是非常低级的代码...这是我们继承的代码，该项目的任务之一是在层之间进行区分。不过，它会在以后发生。

【解决方案3】：

如果你可以JTAG进入设备，那么通常你可以fprintf通过JTAG/IDE链进入你的主机项目目录。

如果您可以以与传输字符串相同的方式将解析的结构传输回，那么您可以考虑在主机环境中处理它们。

幸运的是，我们的设备和主机都运行 Linux 并使用 GCC，整数大小、浮点格式、对齐要求、字节序在设备或主机上都是相同的，我们在处理结构。

如果你是这种情况，你也可以这样做。

此外，您可以使用 mex 函数将 C 结构体转换为 MATLAB 结构体并在 MATLAB 中进行处理。

【讨论】：