在我们公司，我们为微控制器开发裸机嵌入式软件。到目前为止，我们一直在目标或模拟器上使用手动单元测试，特别是针对瑞萨微控制器（RL78和RX系列）。我们现在计划进入自动单元测试。我们的想法是将它们集成到我们现有的CI系统中。
在这一点上，我们遇到了一个难题。到目前为止，我们一直在使用相同的编译器和目标运行单元测试（或模拟器），之后用于将软件部署到生产中。我们希望保持这种方法，作为开发者（以及每个人）都特别喜欢使用相同的条件进行测试和部署。因此，我们的想法是使用一个测试工具/用C语言编程的库，允许在嵌入式环境中使用模拟器编译和运行测试。（例如http://www.throwtheswitch.org/unity）
但是，另一方面，我们要应对两种即将出现的情况，这两种情况会使困境出现：
- 我们越来越多地使用Cortex uC，在那里，更难获得特定的模拟器来实现自动化。（例如，Renesas RA系列）
- 许多高级测试工具都是用C++开发的，并考虑在x86架构中使用gcc/g ++编译器的PC环境，这与我们预计使用的使用arm-none-eabi-gcc编译的Cortex目标不匹配。
因此，此时，我们想知道，这也是我的问题，如果我们的最终目标是Cortex uC，并且最终将使用arm-none-eabi-gcc生成二进制文件，那么使用gcc运行单元测试的可靠性如何。间接地，我会询问针对不同目标编译时gcc和arm-none-eabi-gcc之间的差异。
我希望了解gcc内部结构的人能提供反馈，以应对同样的问题。
先谢谢你，
伊格纳西比利亚格拉萨
1条答案
按热度按时间vddsk6oq1#
一般来说，模拟器是没用的，但对于生产测试尤其如此。既然是嵌入式系统，你就想同时测试软件和硬件--在没有预期的MCU和硬件到位的情况下测试软件只是无稽之谈。
如果你坚持使用像模拟器或PC“测试套件”这样的绒毛软件，那么要意识到：
至于如何正确测试您的特定嵌入式系统，这取决于应用和产品应该做什么。如果您按书做项目，那么您将拥有：规格说明，导致实现，导致测试。测试的唯一目的是验证实现是否遵循规格说明。
因此，如果规格说明书规定产品应激活10个继电器，则需要将软件闪存到真实的PCB上的实时MCU上，然后正确执行测试，验证所有10个继电器是否按预期激活。
这个完整而正确的产品测试不能用任何其他的方法来完成。所以问问你自己你是否真的需要这个不正确和不完整的模拟测试。也许你的开发相关测试应该集中在更有意义的事情上，比如设计评审，编码标准，静态分析，代码评审等等。