为什么正确的软件架构对IoT设计越来越重要

我们都曾在职业生涯的某个时间点思考过这个问题：现在，你想要创建一个合适的项目，看是要更进一步探索这个想法或是将其产品化。但是，应该从哪种软件架构入手呢？Espruino？Arduino？micro Python？Segger embOS？MicriumuC/OS-II？以及在uC/OS-II和uC/OS-III之间又有什么区别呢？究竟该采用初始成本较低的开源架构，还是选择需要支付前期费用的商业解决方案，来加速你的设计过程呢？

什么是软件架构？

在本文件中，将"软件构架"解释为"编写软件的一种特定方式"。例如，Arduino提供编写程序代码的一种特定方式，允许软件的片段可以跨越多个项目被重新使用。

软件架构是由几个不同的部分所组成，并由以下组件所定义：程序语言、应用程序编程接口（API），以及某些工具集的连接。例如，像是在Arduino和Espruino的案例中，软件架构可以被紧密地连接到工具，或是像在Micrium和FreeRTOS的案例中则是会被分离。

什么是操作系统？

因此，该如何选择一个软件架构呢？首先，我们需要对一些名词解释的更明确一点，我们已经开始提到操作系统（OS）这个名词。你真正需要写的是可以执行你的特定要求的程序代码，这些程序代码将可以把你的产品与其他产品区分出来。但是，你仍然需要依靠软件的其他部分，像是ADC的驱动程序或SD卡的文件系统栈。这些软件的部分通常被称为软件构件。

在此用一个比较实质的比喻方式，你可以想象你的软件构件就像是砖块，然后把操作系统视为水泥。在操作系统中定义了砖块的形状，以及它们将如何与其他的砖块互动，因此当你添加更多构件到软件之中时，他们将可以继续完美地协同工作。这听起来相当不错，但你真的需要一个操作系统吗？增加操作系统也带来了额外的负荷，它将会消耗数千字节的闪存，为事件的响应增加了延迟的时间，并且还需要花费些许的时间学习如何在操作系统环境中编写程序。

决定采用哪个软件架构，将会决定你的想法是否可以按时间、按预算地推动，或是将你的投资放在风险之中。

一般的经验法则是，如果你的目标闪存容量是128 KB或更高，并且或是需要通讯功能，便需要一些栈（USB、以太网络、SDIO、CAN、Wi-Fi、BLE），长期来看，你最好还是使用操作系统。

在操作系统中最重要的其中一件事情便是调度程序（scheduler）。调度程序是用在为可能会争夺相同资源的不同任务、分配资源和处理时间的组件。在一般情况下，调度程序有两种作业的方式，而这正是"实时"在实时操作系统（RTOS）的意义所在。实时意味着在一个特定的时间内，会有一个特定的任务将会被执行。假设你得到一个你需要处理的射频封包，无论你的设备目前正在做什么事，实时操作系统的核心会先离开它目前所做的任务，先完成这一个高优先等级的任务。这种类型的行为在处理器的利用上并不是最有效率的方式，但例如在马达控制应用中，它在通讯栈与应用中最需要重视的便是反应时间的议题。

商用与开源解决方案的比较

举例来说，如果你已经想通了是否需要采用实时操作系统，并开始组建软件需求。你可能知道，你需要一个USB栈和以太网络栈，搭配外部MAC/PHY驱动程序来一起将设备连接到互联网。但是，你该从哪里开始呢？你真的只需要为你首选的微控制器下载最新的FreeRTOS模板，并继续下载开源软件并放到装置中就可以了吗？或者你只是需要去找有你所需软件的商业供货商，并获得完整的软件组合？

为了做出更明智的决定，我们经常谈论要给选定的解决方案一个总体拥有成本（TCO）的概念。所谓的总体拥有成本包含的不仅是你为软件付出的货币价值，还包括花费在寻找解决方案、组装不同的构件，并将不同的构件整合到你的项目，以及开发、测试和生产的工作时间。

在一般情况下，我们看到的是商业解决方案的总体拥有成本（TCO），将比自己组建开放原始码组件的解决方案要来的更低一些。但既然是商业解决方案便涉及到初始成本，这些厂商通常要求在使用解决方案的前期，取决于你所需要的组件，便必须先支付1万到10万美元之间的费用。在另一方面，下载FreeRTOS并开始组装自己的解决方案，在某些拥有密集资源的应用中，其所花费的金钱，相对会更便宜一些。

决定你的项目的最佳解决方案，将高度依赖于它是否是最容易让你赚到现金，或是能够为总体拥有成本的工时来"买单"。
候选方案

所以，当你已经看到这里，你的大脑中可能已经开始吶喊："只要给我一个可以让我开始使用的架构就好了！"

可惜没有那么快，肯定有一些方案的选项是比其他选项更好，微控制器的应用非常多