当嵌入式软件开发人员要开始一个新项目时，他们做的第一件事就是要一个开发工具包。开发工具包允许开发团队熟悉微控制器及其外设。然后，他们可以开始用分隔板之类的东西拼凑一个系统。

这种方法的问题在于，它迫使开发人员从头开始思考。他们专注于他们正在使用的硬件。是的，这是难题的一个重要部分，但是低层次的思考往往会导致紧密耦合的代码、硬件依赖性，并且客户几个月都看不到任何结果。

在今天的开发环境中，没有理由为什么一个团队不能从第一天开始模拟他们的系统。事实上，嵌入式团队需要采用模拟来使他们的实践现代化并取得成功有三个原因。

原因1–更快的上市时间和更低的开发成本

几十年来，许多工具和服务公司都在吹嘘更快上市和更低成本的能力。这些方法是否真的有效还有待讨论。

任何产品公司的目标都是尽可能快地开发他们的产品。在许多情况下，产品开始是模糊的。他们认为自己知道顾客想要什么，需要什么，但这通常只是猜测。

如果你从主机上的模拟开始，你会立即放弃对硬件的关注。相反，你要关注客户和他们的需求。这意味着在第一天，你正在编写以客户为中心的代码。不是为使LED闪烁或传感器被读取而设计的代码。虽然这些都很重要，但产品的最终目标是向客户交付价值。

如果客户提前拿到产品，他们可以告诉你产品是否符合他们的需求。他们可能认为他们需要一件东西，但是在他们试验过之后，他们意识到他们需要别的东西。如果你已经设计了整个产品，这意味着你必须回去重做它的大部分。这既费时又费钱，还会推迟你的产品上市。

模拟可以帮助巩固客户和管理团队眼中的产品。当改变不涉及硬件时，要容易得多。这意味着应用程序可以放在第一位，实时的、底层的、硬件的东西可以放在后面。不管怎样，这很好，因为硬件公司不会有硬件供你使用几个月。有了清晰的产品和分离的应用代码，结果将是更快的上市时间和更低的开发成本！

原因2–模拟鼓励硬件去耦

你是否尝试过移植与硬件紧密耦合的应用程序代码？虽然你可能在开始编写代码时认为可以将其耦合到硬件上，但你永远不知道什么时候硬件可能变得不可用，或者什么时候功能蔓延会迫使你升级处理器。

模拟迫使开发人员立即开始开发不依赖于硬件的代码。你从一台主机开始，必须使用抽象和接口来获得硬件通常会提供的预期结果。通过打破对硬件的依赖，你会发现你自然会写出更可重用、可移植和可伸缩的代码。

将硬件从软件中分离出来有很多好处。例如，它在开发过程的早期为团队提供了灵活性。他们可以在自己的开发机器上运行代码，甚至可以在Raspberry Pi之类的设备上运行代码。开发人员可以编写和测试他们的代码，而不必等待硬件的出现。事实上，它可以帮助他们编写更好的单元测试，更容易集成到CI/CD框架中！

当团队开始模拟时，软件架构和实现通常更具可伸缩性、可重用性和可移植性。它让他们思考应用程序级别，这是产品真正的“秘方”。

原因3——在主机上调试效率更高

在目标上调试代码效率不是很高。你必须遵循一个有点神秘的过程：

l 交叉编译代码

l 抹去目标

l 对目标编程

l 启动调试会话

l 逐句通过代码

开发人员平均花费20-40%的时间在调试上！当你用几个月的时间来思考这个问题时，你会发现一年大约有2.5到4个月的时间花在了做失败的工作上！

当你有一个模拟器时，你可以跳过晦涩难懂的目标调试过程。运行应用程序和重新创建问题通常会更容易、更快。你可以生成日志信息，以便于识别问题。当你进行更改时，只需进行更改、编译并运行即可。它很快。目标调试不是。这可能会更有趣，因为你可以玩电子产品，但这浪费了很多时间和资源。

结论

采用模拟技术可以极大地改进嵌入式软件，它可以迫使你首先关注你的应用，这有助于客户更快地巩固产品。运行与底层硬件分离的应用程序代码将鼓励代码的可伸缩性和重用性。你将能够更好地为你的应用程序编写自动化测试，并确保低级硬件不会碍事。

考虑使用模拟器编写软件可能有点令人畏惧，但这并没有太大的不同。你可以像在嵌入式目标上一样，在Linux、Windows或MacOS上轻松执行你的RTOS。调试问题会更快。将代码部署到客户面前会更容易。

虽然需要一点时间来适应，但模拟代码将帮助你更新嵌入式软件的开发方式，最终，你会发现你可以更快地完成这项工作。