微控制器 C 代码的单元测试模式答案

【问题标题】：Unit testing patterns for microcontroller C code微控制器 C 代码的单元测试模式
【发布时间】：2010-10-31 19:48:17
【问题描述】：

虽然有很多支持 C 的单元测试框架，但我对如何为微控制器代码编写单元测试感到有些困惑（在我的例子中是 PIC，但我认为这个问题比这更笼统）。

为微控制器编写的大部分代码都围绕着将配置和数据值写入寄存器、从寄存器读取传入数据以及响应中断事件。我想知道是否有人可以就最有效的方法提供一些指示。

【问题讨论】：

有足够代表的人可以在这个问题中添加“嵌入式”标签吗？谢谢。

标签： c unit-testing embedded microcontroller

【解决方案1】：

你写；

“为微控制器编写的大部分代码都围绕着将配置和数据值写入寄存器、从寄存器读取传入数据以及响应中断事件”。

我同意在实践中经常出现这种情况，但我实际上并不认为这是一件好事，而且我认为稍微重新考虑一下会帮助您实现测试目标。

也许是因为微控制器程序员可以在他们喜欢的任何时候伸出手来触摸硬件，他们中的许多人（大多数？）已经养成了这样做的习惯，贯穿他们的代码。通常，这种习惯会被毫无疑问地遵循，可能是因为很多从事此类工作的人都是 EE，而不是经过培训和倾向的计算机科学家。我知道，我自己就是这样开始的。

我想说的是，微控制器项目可以而且应该像任何其他软件项目一样设计得很好。良好设计的一个非常重要的部分是限制对硬件驱动程序的硬件访问！将所有写入寄存器、响应中断等的代码划分为模块，为您的软件的其余部分提供对硬件的良好、干净、抽象的访问。使用逻辑分析仪、示波器、定制测试台或其他任何有意义的东西在目标上测试这些驱动模块。

非常重要的一点是，现在您的软件的其余部分（希望其中的大部分）现在只是您可以在主机系统上运行和测试的 C 代码。在主机系统上，硬件模块被剔除，以提供对被测代码正在做什么的可见性。您可以在此代码上使用主流的单元测试方法。这需要一些准备和工作，但如果您组织良好，您可以创建一个可应用于所有项目的可重用系统。潜在的好处是巨大的。我在这里写了更多关于这些想法的内容；

[http://discuss.joelonsoftware.com/default.asp?joel.3.530964.12][1]

【讨论】：

好点。我可以补充一下：习惯使用 uint16_t、uint8_t 等（而不仅仅是 int、char），以便在从嵌入式平台跳转到 PC 以及不同嵌入式平台之间时，您的类型更可预测。
这个答案的问题：硬件驱动抽象会产生很大的开销，通常是不可接受的，除非用汇编程序编写。但是混合 C 和汇编程序是一件非常令人头疼的事情 - PIC 架构不仅是一个可以使用的 PITA，而且编译器跳过了处理不同寄存器组等的循环，这是一个非常巨大的 PITA，可以同时编写汇编程序。

【解决方案2】：

一种方法可能是使用模拟器。我一直在研究 AVR 模拟器，使用它的想法之一确实是对代码进行单元测试。模拟器实现 CPU 和寄存器、中断和各种外围设备，并且（在我的情况下）写入模拟 UART 的字节转到模拟器的常规 stdout。这样，单元测试代码就可以在模拟器中运行，并将其测试结果写入控制台。

当然，还必须确保模拟器正确实现真实 CPU 的行为，否则在此之上的单元测试将不可信。

【讨论】：

【解决方案3】：

编写您的寄存器访问函数/宏的模拟版本。请注意，这假定您的代码使用一组通用的寄存器访问函数，而不是随处可见的 *(volatile int*)0xDEADBEEF = 0xBADF00D 之类的临时内容。

直接从您的测试代码调用您的中断处理程序（在某些架构上可能会出现问题¹），如果可用，可以调用“软件中断”，或者如果您需要异步执行它们，可以从定时器中断处理程序调用。这可能需要将您的中断启用/禁用代码包装在您可以模拟的函数/宏中。

¹ 8051 浮现在脑海中：至少使用 Keil 8051 编译器，您不能直接调用中断函数。不过，这可以通过 C 预处理器解决。

【讨论】：

【解决方案4】：

是否有任何类型的环回模式，以便您可以使用控制器本身生成可以测试的事件？

【讨论】：