我正在使用来自 Microchip 的 XC8 C 编译器 1.12 开发引导加载程序 MPLAB X 1.60。目标芯片是PIC18F87J60。 我的引导加载程序做了一些引导加载程序通常不会做的额外事情。它将应用程序镜像从服务器下载到闪存，并通过计算 MD5 哈希和来验证其完整性。此外，它必须在该项目特定的服务器上通过身份验证测试。 为了使所有这些都能正常工作，我使用了 Microchip 的 TCP/IP 堆栈 v5.42。
我现在想做的是彻底测试引导加载程序，但我在选择正确的方法和工具时遇到了一些麻烦。我可以使用 Pickit 3 ICD 但不能使用任何其他专用硬件，例如逻辑分析仪等(示波器 除外)。引导加载程序作为分层FSM 实现，这可能(也可能不会)使事情变得更加复杂。
我正在考虑至少对引导加载程序的所有不同部分进行单元测试/模块测试，并将 FSM 的所有状态视为单独的功能。网上有一些单元测试框架，其中一些声称可以在像我这样的嵌入式和受限环境中使用。
这些的问题在于，大多数都是作为某种 C 库实现的，将与程序的其余部分一起编译，但它们都希望编译器遵循某些标准。 XC8 编译器实际上确实遵循了 C90 标准，但并未完全扩展(显然是文档中的“与 ANSI C 标准的分歧”一章)。这在编译框架时造成了麻烦。
我可能会通过模拟所有硬件并注册访问权限并在我的 Windows 7 开发机器上进行测试来解决这个问题，但由于我使用了引导加载程序严重依赖的 TCP/IP 库，因此这将是一项繁重的工作。另一个缺点是，最终我想在芯片上进行测试，因为 C 代码在 PIC 芯片上的行为可能与在我的 intel i7 上的行为不同。
有没有人对如何正确地unit-/moduletest 我的引导加载程序有任何想法？在这样的平台上对这样的程序进行单元测试是个好主意吗？我可以使用任何其他测试方法吗？
要求/预先/注意事项:
- 我说的是白盒测试方法。黑盒测试目前并不痛苦。此外，从功能上讲，引导加载程序未编译，所有功能要求都是可测量的。
- 我想尽可能地自动化测试，甚至在我按下“编译”时自动触发测试。
- 没有任何严格的性能要求，而且我有一些备用 ROM 内存，因此代码检测(如放入大量探测器)应该不是什么大问题。
- 我远不是测试大师。我上面使用的任何花哨的词都来自几个小时的研究，但我没有任何实际的测试经验。
提前感谢您的任何想法和建议。
比特垃圾
最佳答案
我发现嵌入式系统中的单元测试非常困难。外围设备的副作用非常严重。最难处理的是读取内存位置触发的副作用(例如读取清除标志)。您能做的最好的事情就是隔离硬件访问。即使在模块内限制访问也是一个好主意。单元测试是值得的，但在嵌入式空间中可以比其他测试更快地达到 yield 递减点。
我很幸运 seatest .这是非常基本的；它不提供 Unity 提供的更高级的功能等(没有自动模拟)，但它是可移植的，直接使用 C，并支持测试所需的核心功能。
我的第二个建议是创建一个文件，其中包含以 MCU 拥有的所有可用寄存器命名的变量。很容易从 Microchip 的链接描述文件中获取寄存器名称并将它们粘贴到 c 文件中。这使得在 PC 平台上编译所有代码变得更加容易。这可以让您更快地启动和运行，也使测试更容易。
关于c - 如何使用 TCP/IP 堆栈对 PIC18 上的引导加载程序进行单元测试？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17379517/