【技术】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并开始组装自己的解决方案，在某些拥有密集资源的应用中，其所花费的金钱，相对会更便宜一些。

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

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

可惜没有那么快，肯定有一些方案的选项是比其他选项更好，微控制器的应用非常多样性，肯定没有那种一个尺寸便适合所有需求的解决方案。我们先来了解许多最流行的操作系统和软件架构，并分别仔细地讨论（本文所提到的操作系统都具有实时能力）：

1）商用解决方案
• Micrium uC/OS-II与uC/OS-III

这是在微控制器业界最流行的两个实时操作系统，特别是因为其创新的商业模式，因为Micrium公司允许你下载完整的软件套件，并开始发展，等你真正开始产生营收后，才需要开始支付解决方案的费用。他们在安全至上的系统中拥有重要的地位，并且他们的大部分软件构件都已经通过认证。

• Segger embOS

嵌入式软件市场的新进入者，但这并不意味着他们是新手。该软件产品已经开发了超过20年的时间，并已经使用在他们自己的硬件产品之中，因此对装置的支持程度非常好，并配有一个优秀的驱动程序库。

• Express Logic ThreadX

由行业的资深人士所创办，该公司专注在所有关于性能的事物上，并挤压出元器件中每一个时钟周期的效能。它通常被看作是操作系统中的劳斯莱斯，并已经有很多认证被使用在安全至上的系统之中。

2）开源解决方案

• FreeRTOS

FreeRTOS跟MicriumuC/OS一样，都是在同行业中最常被采用的实时操作系统之一。它有一个庞大的社群，有很多人都在为软件做出贡献，像是TCP/IP栈，但做为开源软件，便意味着没有公司会负责整合，因此需要更多的工作来创建一个整合的解决方案。
 

也有一些公司在FreeRTOS的生态系统中，专门从事将差异化的软件构件提供给那些需要整合协助的客户，例如，Wittenstein高完整性系统公司提供称为SAFERTOS安全认证的FreeRTOS替换核心，以及HCC嵌入式公司提供可以与任何实时操作系统工作的USB、以太网络和文件系统。
 
• mbed OS

mbed OS解决一些你通常会在开源软件所遇到的痛点，因为ARM这一家公司会负责整合的工作。然而，它仍然是处于萌芽阶段，所以如果你想要有些贡献就可以去这里。
 
• RIOT OS

RIOT OS被冠以“物联网中最友好的操作系统”，它是以通讯概念为基础所建立起来的操作系统。这使得它即使在面对困难的通讯问题时，仍然精简且高效率。然而它仍然还在积极发展的阶段当中，所以你得计划多花几个小时来进行除错。

3）架构
有一些操作系统的功能就像是将砖块黏合在一起的水泥一样，会与发展框架紧密地结合在一起，因此一般不能使用软件本身做为项目的一部分，你必须围绕着它来进行整个开发流程。这些框架往往是使用比C++更高阶的语言所编写，通常可以在实时操作系统上运行。
 
• mbed

mbed也出现在这里，这时则做为快速成型的项目。它是用C++编写，并对大多数微控制器和电路板有绝佳的支持，拥有一个庞大的元件程序库，和一个采用网页架构的漂亮集成开发环境（IDE）。目前，在它准备全面部署之前，它仍然需要一点成熟的时间，但它很适合硬件原型的开发。
 
• Espruino

Espruino是在微控制器上运行的实时JavaScript解释器。它允许你能够动态地更改程序代码，甚至不需要读写微控制器便可以撰写程序代码。在它开始量产之前，仍然需要一些时间来发展，但它很适合用于硬件原型，并呈现出成为一个不可忽视软件架构的巨大潜力。
 
• microPython

microPython所能做的事与Espruino大致相同，差别仅在于其使用Python来代替JavaScript。它发展的概念，便是让你从产品开发的一开始到量产，都能够支持预先编译的程序代码，并使用C语言来编写时序至上的程序代码。目前仍在开发当中。
 
• microEJ

microEJ是一个采用Java架构的框架，让你轻松地为你的设备打造好看的图形化应用程序。它已经在许多智能手表和一些物联网（IoT）设备中使用。

结语
如果你想要着手进行设备的开发，而无需安装单一的程序，像是mbed和microPython这类的框架，便是入门的好方法。但是，如果你要建立更大的部署，采用一个纯粹的实时操作系统将会是更好的选择。如果使用工作时间而不是金钱来当作软件的投资，对你的公司来说会更为轻松的话，像是FreeRTOS或RIOT这类非商业解决方案便有其优势。如果你的公司能负担得起前期投资，像是Segger、Express Logic和Micrium的商业解决方案，将大大降低软件开发风险和缩短产品上市的时间。在商业解决方案中，特别像是Micrium的稳定性和认证的程序代码基础，广泛普及的部署，良好的元器件支持，开放的原始码，以及适合大多数经济效益的商业模式，更使其在商业解决方案中显得特别突出。