维护嵌入式代码和非嵌入式代码之间的单个代码库。

Question

我正在从事一个机器人研究项目，其中包括设计一个微控制器。我希望能够尽可能地将软件测试与硬件测试分离开来。这既提高了开发速度，也使我可以更容易地单元测试/模拟代码，然后才把它放在机器人上。例如，我可能会编写一个"MyRobot“库。然后，我可以将这个库包括在嵌入式代码和非嵌入式仿真/测试代码中。在运行时，我会提供函数指针，这些指针可以读取(在嵌入式情况下)，也可以模拟(在模拟中)传感器数据，并将其输入库。

因此，我所需要做的就是在编译时生成两个库:一个用于嵌入式代码，一个用于非嵌入式代码。

我的问题是，这是否可行/如果有更好的方法来做/如果有什么问题，我应该小心。

提前感谢！

Answer 1

这是嵌入式系统开发中常见的情况，您创建两个库的方法通常是推荐的解决方案。在嵌入式系统固件中，将底层硬件与软件解耦被认为是一种最佳实践。

您提到的库通常称为“硬件抽象层”，即HAL。HAL的API (应用程序编程接口)可以在一个名为hal.h的头文件中提供。您的软件中需要访问硬件的每个源模块在源文件的顶部都有下面一行：

#include "hal.h"

像这样设计系统的好处包括：

• 模数.如果需要对读取传感器的UART或SPI接口进行定时更改，则只需更改HAL库，即使代码中可能有多个读取传感器的位置。
• 可移植性.如果以后需要将项目迁移到不同的微控制器，则只需要更改HAL层。
• Encapsulation.硬件的细节隐藏在HAL层中，这允许您的其他软件在更高的抽象级别上操作。如果您正在使用由微控制器制造商提供的设备库，该设备库提供寄存器地址、I/O端口等，则可以将对该库的引用封装在HAL库中，以便您的应用程序代码不需要了解它。
• Testability.这是你问题的主要焦点。您可以编写HAL层的特殊版本，该版本可以在不同的平台(例如Windows )上运行，用于测试应用程序软件。此特殊版本不需要包含微控制器制造商提供的设备库，因为当您在测试环境中运行时，微控制器并不存在，因此您的软件不需要访问它的寄存器和I/O端口。

按照您的建议，对于两个场景，您将创建两个版本的HAL库:包含在嵌入式硬件上运行的代码的标准版本，以及模拟硬件以以受控方式测试软件的模拟版本。您可以命名标准库hal.lib (可能有不同的扩展，这取决于您的开发环境)和模拟库hal_simulated.lib。正如hal.h中所描述的，两者都具有相同的接口。也就是说，两个库都将包含在hal.h中声明的所有函数，如void halInit()、int halReadProximitySensor()等。

假设您的IDE支持Release和Debug配置，您可以为您的软件测试创建名为SW_Test的第三个配置。此配置将与您的Debug配置重复，只不过hal_simulated.lib将链接到项目中，而不是标准的hal.lib。

也见

硬件抽象(Wikipedia)

Answer 2

考虑到您使用的不是面向对象语言的C语言，我会使用一些内部逻辑甚至#ifdefs (如果性能是必须的话)的单个库，如下所示：

bool turnOn()
{
   #ifdef DEV
       printf ("Turned On\n");
       return true;
   #endif

   #ifdef PROD
      return robot_command_turnOn();
   #endif
}

或

bool turnOn()
{
   if (inProduction())
      return robot_command_turnOn();

   printf ("Turned On\n");
   return true;
}

甚至更好：

bool turnOn()
{
   printf ("Turned On\n");

   if (!inProduction())
        return true;

  return robot_command_turnOn();
}

有几种方法可以做到这一点。在我看来，我不会选择两个库，因为我需要保持函数签名和版本的同步，这可能会很混乱。

秘诀是将接口库构建到硬件(万一有机器人)，并开发库，转换所有可能的交互，从而保持硬件层的抽象水平。该接口库可以控制您是否正在测试单元(使用类似于上面的inProduction()函数)，并在允许的情况下将命令发送到硬件。

使用面向对象的语言(如C++ )，您可以使用模式来帮助您:例如:接口模式、工厂模式等等。