很多人开始一个新的嵌入式项目，第一反应是购买开发板。一旦有了开发板，嵌入式开发人员就可以设置开发环境，获得一些示例代码，开始运行并编写项目代码。但是这真的是开发嵌入式软件的最佳方式吗?自下而上的方法真的能最有效地实现企业和客户的目标吗?

自下而上方法的问题

(资料图片仅供参考)

嵌入式软件开发人员自然会自下而上地思考。假设我告诉一个团队，一个产品需要的第一个功能是一个可以打开和关闭的加热器。我不知道加热器是如何工作的。没有人问最小值和最大值、客户安全机制、滞后、砰砰控制或诸如此类的需求。相反，我被问及加热器连接的GPIO引脚、GPIO外围设备如何工作、必须开发的驱动程序等。

事实是那些低级的细节并不重要。客户、你的老板和企业并不关心这些细节。他们需要一个可以开关的加热器，有最小值和最大值，可能还有超时等等。事实上，他们需要尽早看到这个软件及其行为，以验证功能并确保产品特性符合他们的需求。

嵌入式开发人员不是从产品特性开始，从应用程序堆栈的顶部获得早期反馈，而是关注底层细节，并逐步提升。他们得到一个开发板，编写一堆驱动程序，集成中间件，通常，经过几个月的努力，最终得到应用程序代码。在此期间，开发人员在开发板上编写代码，通常没有足够的工具，这将经历一个非常缓慢的编译、擦除、编程和调试周期。

嵌入式软件的自上而下方法

在开发嵌入式产品时，你确实希望尽快获得应用程序代码。你越早在客户面前获得产品及其功能的反馈越好。你可能会发现产品走错了路，甚至你的团队认为非常棒的产品变成了死胡同!如果是这样的话，所有在开发板上工作以启动和运行低级代码的时间都将被浪费，更不用说所有的钱了。

在许多情况下，一种更好的方法(老实说，没有办法对它们全部进行规则化)是从应用程序代码开始，并朝着低级代码的方向努力。这对嵌入式开发人员来说听起来很荒谬，但它会带来更好的产品。如果你从应用程序开始，你可以快速地在客户面前获得功能。客户反馈至关重要。你会发现，你被迫为尚未编写的低级代码创建接口。你可能正在PC上进行设计，并使用网络适配器作为模拟USART。该接口将使你的代码更加灵活，这样你就可以更好地测试、移植它，并在其他产品中重用它。事实上，这些接口将使你更容易测试代码，并且你的代码不会关心底层细节。你的代码将与硬件解耦!

改变你的思维方式

我们可以想出很多借口来解释为什么我们应该在开发板上开发嵌入式软件。我们可能会说，我们需要硬件加速，或者我们需要了解目标硬件的某些功能才能构建系统。有时情况确实如此，但你通常可以为应用程序代码抽象这些细节。恢复机制、固件更新等可能需要低级别的详细信息。

如果你在早期阶段放弃开发板，专注于应用程序代码，你会更快地行动，拥有更灵活的代码库，获得客户反馈，最终获得更可靠的系统。这不是一个保证，但在时间和预算上更有利于你。

诀窍是嵌入式开发人员从上到下改变你对开发嵌入式软件的看法，而不是自下而上。