嵌入式系统调试 - 我应该使用 output/log 文件吗?

Embedded system debugging - Should I use an output/log file?

我对嵌入式系统相当陌生,但对编程不是很熟悉。

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

为了避免增加代码大小,包括仅用于调试版本的代码。系统是stm32F2xx和IDEkeil uVision.

谢谢!!

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

如果您可以像传输字符串一样将解析后的结构传输回来,那么您可以考虑在宿主环境中处理它们。

幸运的是我们的设备和主机都运行 Linux 并使用 GCC,整数大小、浮点格式、对齐要求、字节顺序等在设备或主机上都是相同的,我们没有遇到什么困难使用结构的原始字节流。

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

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

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

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

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

我很少将工具链的调试器用于我的嵌入式工作,除非我面临非常困难的问题或启动板时。相反,我通常对设备的一个串行端口执行 "printf debugging",然后在主机 PC 上的串行终端程序(例如 putty)中查看输出。

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

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