Question

我目前正在用C语言为微控制器（TI MSP430）编写状态机。现在，编写代码和实现我的设计时没有任何问题，但我想知道如何在不使用实际硬件（当然，尚未提供）的情况下证明状态机逻辑。 / p>

使用调试功能，我可以模拟中断（虽然我还没有尝试过这样做，我只是假设它没问题 - 毕竟记录了它）并且我已经定义并保留了特定的内存区域持有TEST数据，使用调试宏，我可以在Python脚本中在应用程序之外的运行时访问。换句话说，我有一些测试基础。但是，我的问题的重点是：

“我最好如何强制某个状态机流程用于需要硬件输入的决策，例如，当输入引脚为高电平或低电平时”。例如，“如果某个引脚为高电平，请遵循此路径，否则请遵循此路径”。

再次，使用调试宏，我可以写入应用程序外部的寄存器（例如，点亮LED），但我不能（理解）写入用于输入的只读寄存器，因此强制以上述方式进行的国家机器流程证明是在征税。

我曾想过使用#ifdefs，如果我想测试流程，我可以使用输出引脚并检查此值而不是最终将使用的输入引脚。但是，这无疑会使我的代码库充满仅测试代码，感觉这是错误的方法。有没有人对实现这种测试水平的好方法有任何建议？我知道我可能只是使用模拟器，但我想尽可能使用真正的硬件（虽然现阶段是评估板）。

Answer 1

听起来你需要抽象。

代替在“应用程序”代码（状态机）中使用例如硬编码输入读取。 GPIO寄存器读取，将这些读取封装到执行检查并返回值的函数中。在函数内部，您可以放置#ifdef：从您的TEST存储区读取的ed代码，从而模拟来自GPIO引脚的响应。

即使你的目标是高性能，这也应该是可能的，这不是很多开销，如果你工作，你应该能够inline这些功能。

Answer 2

即使你还没有所有的硬件，你可以模拟几乎所有的东西。

在C中进行此操作的可能方法......

中断处理程序=等待事件的线程。

输入设备=触发上述事件的线程。它们可以“连接”到PC键盘，因此您可以手动启动“中断”。或者他们可以拥有自己的状态机来以自动方式执行任何必要的操作（您也可以编写脚本，它们不必硬连接到固定行为！）。

输出设备=同样是线程。它们可以“连接”到PC显示器，因此您可以看到“LED”状态。您也可以将输出记录到文件中。

I / O引脚/端口可以只是专用的全局变量。如果您需要在读/写它们时唤醒I / O设备线程，您也可以这样做。将对它们的访问包装成适当的同步和通信代码，甚至以这样的方式映射底层内存，即对这些端口变量的任何访问都会触发信号/页面错误，其处理程序将为您执行所有必要的同步和通信。

主要部分是，main()。：）

这将创造一个非常接近真实的环境。你甚至可以获得竞争条件！

如果你想更加硬编码，如果你有时间，你也可以模拟整个MSP430。指令集非常紧凑和简单。今天存在一些模拟器，因此您可以使用一些参考代码。

如果您想要很好地测试代码，则需要使其足够灵活。这可能包括在函数中添加＃ifdefs，宏，显式参数而不是访问全局变量，指向数据和函数的指针，您可以在测试时覆盖它们，各种测试挂钩。

您还应该考虑将代码拆分为特定于硬件的部件，特定于硬件的部件和简单的业务逻辑部件，您可以将这些部件编译到单独的库中。如果你这样做，你将能够用模拟硬件的测试库替换真正的硬件库。

无论如何，你应该抽象掉硬件设备并使用测试状态机来测试生产代码及其状态机。

Answer 3

建立一个测试台。首先，我建议当你读取输入寄存器或其他什么时，使用某种函数调用（vs一些volatile，这是另一个地址的东西）。基本上一切都至少有一层抽象。现在，您可以轻松地将主应用程序提升并放置在任何位置，并为每个抽象提供测试功能。您可以在没有任何真实硬件的情况下完全测试该代码。此外，在真实硬件上，您可以使用抽象（包装函数，无论您想要调用它）作为更改或伪造输入的方法。

switch(state)
{
   case X:
      r=read_gpio_port();
      if(r&0x10) next_state = Y;
      break;
}

在测试平台（甚至是硬件）上：

unsigned int test_count;
unsigned read_gpio_port ( void )
{
   test_count++;
   return(test_count);
}

最终在asm或C中实现read_gpio_port以访问gpio端口，并将其与主应用程序而不是测试代码链接。

是的，除非你内联，否则你会遇到函数调用，但作为回报，你的调试和测试能力要大得多。

无外部硬件测试状态机流程

3 个答案: