在固件开发的初始阶段没有硬件会发生。处理这种情况的常用策略是：

1. 在编写任何代码之前，先花时间仔细构建系统。当然，无论如何你都应该这样做，但在这种情况下，它比平时更重要。调试经过深思熟虑的软件比基于意大利面的混乱要容易得多。

2. 适当地模块化一切，最小化模块之间的接口。这将有助于包含单个模块的错误，并允许更轻松地测试单个模块。

3. 自下而上编写代码，硬件接触驱动程序先行，高级应用程序逻辑最后。这允许尽早发现架构带来的不便。不要害怕随着硬件现实的曝光而改变架构，但要确保所有文档都相应地更新。

4. 模拟。大多数微控制器公司都提供其微控制器的软件模拟器。这些只能到此为止，但仍然非常有用。模拟输入和测量硬件的输出可能很困难，但是以这种方式检查更高级别的逻辑应该不会太难。

   这就是模块化设计再次发挥作用的地方。如果您无法合理地模拟一些低级硬件交互，您可以使用不同版本的模块来接触该硬件，但将其自己的模拟操作传递给上层。上层不会知道发生了这种情况。您不会以这种方式检查低级模块，而是检查其他所有内容。

简而言之，使用良好的软件设计实践，当然无论如何你都应该这样做。

如果不了解您正在开发什么，或者您的硬件最终将基于哪个微控制器系列，大多数微控制器系列都有低成本的开发系统，这些系统上有一套通用外围设备，这可能使您能够至少模拟一些最终的目标硬件。

根据应用程序对硬件的依赖程度，您可以开始在标准 PC（Windows、Linux...）上实施该项目。无论如何，大多数外围访问都应该被抽象出来，因此实现一些虚拟功能并不是什么大不了的事，这些功能将在以后被替换。如果无法模拟某些行为，您至少可以做一个系统模型（API ...），因此一旦硬件准备好，实际实现就会更快更清晰。

当然有很多东西是无法模拟的，比如实时行为或复杂的硬件驱动程序。另一方面，可以使用从文件或网络端口读取值的线程轻松模拟中断驱动的 ADC。

当然，这一切在很大程度上取决于各种因素：

• 您可以在控制器和 pc 上使用相同/相似的工具链（例如 gcc）吗？
• 系统对硬件的依赖程度如何？
• 您对 PC 编程的经验如何？

我，首先在电脑上设计几乎每个固件模块。

尝试为您的芯片获取模拟器。您应该模拟所有预期的输入和一些意想不到的输入。尽可能模块化/抽象并编写单元测试。如果可以的话，这些测试可以成为您实际代码的一部分，并且它们会变成一个功能（电路板自测）。

如果你不能得到一个模拟器，你可以通过 HAL（硬件抽象层）尽可能多地抽象。所有司机都支持它。尝试在某些 C 函数调用之后抽象所有特定于平台的程序集，并将它们也视为驱动程序。将其余部分编写为可移植的 C/C++ 代码，并为 x86 制作一个精简的 HAL，并在您的机器上运行所有测试用例。

这样，当您获得硬件时，您只需调试 HAL。它越薄，您调试它的速度就越快，并且一切正常。请记住，如果您使用特定于平台的程序集来获得更快的操作，那么您非常希望获得位精确测试。