(本文作者为Silicon Labs软件开发产品经理)
当想要创建一个合适的项目，或是更进一步探索这个想法并将其产品化时，必须先考虑要从哪种软件框架入手。另外，还须分辨Espruino、Arduino、microPython、Segger embOS、Micrium uC/OS-II以及在uC/OS-II和uC/OS-III之间有那些区别。还要决定该采用初始成本较低的开放原始码框架，或者选择须要支付前期费用的商业解决方案来加速设计过程。
因此，这里将讨论在为微控制器(MCU)或无线微控制器项目选择一套优秀的软件时，所需要考虑的各种要素。
认识软件框架 从项目中找灵感
所谓的「软件框架」这个词，本文将其解释为「撰写软件的一种特定方式」。例如，Arduino提供撰写程序代码的一种特定方式，允许软件的片段可以跨越多个项目被重新使用。
软件框架是由几个不同的部分所组成，并由程序语言、应用程序编程接口(API)以及某些工具集的联结等组件所定义。例如，在Arduino和Espruino的案例中，软件框架可以被紧密地关联到工具，或是在Micrium和FreeRTOS的案例中则是去耦合的(Decoupled)。
了解操作系统 分构运行步骤
该如何选择一个软件框架呢？首先，须要对一些操作系统、软件组件等这些名词解释得更明确一点；操作系统(OS)核心需求在撰写可执行特定需求的程序代码，藉由这些程序代码做出产品区隔。但是，仍然须要依靠软件的其他部分共同规划完成，例如ADC的驱动程序或SD卡的文件系统堆栈，而这些软件通常被称为软件组件。
做一个简单明了的比喻，将软件组件想象成砖块，然后把操作系统视为水泥(图1)。在操作系统中定义了砖块的形状以及砖块间将如何互动作用，因此当加入更多组件到软件时，依旧能继续完美地协同工作。这听起来相当不错，但是否真的需要一个操作系统？毕竟增加操作系统，同时带来了额外的负荷，不只会消耗数千字节的闪存，为事件的响应增加延迟的时间，还须要花费些许的时间学习如何在操作系统环境中撰写程序。
图1 可将软件组件想象成砖块，把操作系统视为水泥。
根据一般的经验法则，如果选用的闪存容量是128KB或更高，并且需要通讯功能，便需要一些堆栈如通用串行总线(USB)、以太网络、安全数字输入输出(SDIO)、控制局域网络(CAN)、Wi-Fi、蓝牙低功耗(BLE)，因此从长期来看，使用操作系统还是比较好的选择。
在操作系统中，最重要的其中一件事情便是排程器(Scheduler)。排程器是用在为可能会争夺相同资源的不同任务，分配资源和处理时间的组件。在一般情况下，排程器有两种作业的方式，而这正是实时(RT)在实时操作系统(RTOS)的意义所在。
实时意味着在一个固定的时间内，会有一个特定的任务一定可以被执行。假设得到一个须要处理的无线电封包，无论装置目前正在做甚么事，实时操作系统的核心会先离开其目前所执行的任务，先完成此高优先等级的任务。这种方式在处理器的利用率上并不是最有效率的，但在通讯堆栈中，或是在重视反应时间的应用中，例如马达控制应用，这是有必要的。
商用vs.开放原始码 方案选择的两难
如果已经想通是否须要采用实时操作系统，并开始收集软件的需求。此时将需要一个USB堆栈和以太网络堆栈，搭配外部媒介访问控制(MAC)/实体(PHY)驱动程序一起将装置连接到因特网。但是，该从哪里开始呢？真的只须要为首选的微控制器下载最新的FreeRTOS模板和继续下载开放原始码软件并放到装置中就可以吗？或者必须要寻求产品所需软件的商业供货商，以获得完整的软件组合比较好呢？
为了做出更明智的决定，还须为选定的解决方案提出一个总体拥有成本(TCO)的概念。所谓的总体拥有成本包含的不仅是付出的软件货币价值，还包括花费在寻找解决方案、收集不同的组件，并将不同的组件整合到项目以及开发、测试和生产的工作时间(图2)。
图2 当决定要采用何种微控制器时，必须把一些隐形成本也纳入考虑。
在一般情况下，看到的是商业解决方案的总体拥有成本，将比自己整合开放原始码组件的解决方案要来得更低一些。但既然是商业解决方案便涉及到初始成本，这些厂商通常要求在使用解决方案的前期，取决于自身所需要的组件，便必须先支付1万到10万美元之间的费用。相对地，下载FreeRTOS并开始整合自己的解决方案，在某些拥有密集资源的应用中，可节省金钱，但却消耗更多的整体资源。
决定操作系统种类 选择适用软件框架
到此阶段时，很多人可能都会认为：「只要给我一个可以让我开始使用的框架就好了！」但可惜还没那么快，肯定有一些方案优于其他选项，但由于微控制器的应用非常多样性，因此没有那种单一且适用于所有需求的解决方案。
接下来，将针对主流操作系统和软件框架深入探讨：
慎选操作系统 商用抑或开放源码
所有在这里所提到的操作系统，都应该具有实时能力(RTOS)。说到商用解决方案的选择，可从以下三项选择其一：
．Micrium uC/OS-II与uC/OS-III
这是在微控制器业界最流行的两个实时操作系统，因其创新商业模式，Micrium允许下载完整的软件套件进而开发，待创造营收时，才须要开始支付解决方案的费用。此外，也在安全关键系统中拥有重要的地位，并且其大部分软件组件都已经通过认证。
．Segger embOS
嵌入式软件市场的新进者，但这并不意味着他们是新手。该软件产品已经开发了超过20年的时间，并已经使用在其硬件产品之中，对装置的支持程度非常好，并配有一个完备的驱动程序库。
．Express Logic ThreadX
由业界资深人士所创办，该公司专注在所有关于性能的事物上，并挤压出零组件中每一个频率周期的效能。其通常被看作是操作系统中的劳斯莱斯，并已经有很多安全关键系统的相关认证。
若要从开放原始码中找寻相关的解决方案，计有以下三种选择：
．FreeRTOS
FreeRTOS与Micrium uC/OS一样，都是在业界最常被采用的实时操作系统之一。拥有庞大的社群，许多人都在为软件做出贡献，例如TCP/IP堆栈，但做为开放原始码软件，便意味着没有公司会负责整合，因此需要更多的人力物力和时间来整合出一个完整的解决方案。也有一些公司在FreeRTOS的生态系统中，专门从事将差异化的软件组件提供给那些需要整合协助的客户。例如，Wittenstein High Integrity System就提供一个具有安全认证的FreeRTOS替换核心，称为SAFERTOS，以及HCC Embedded提供可以用在任何实时操作系统的USB、以太网络和文件系统。
．mbed OS
由安谋国际(ARM)负责整合工作，mbed OS解决一般在开放原始码软件容易所遇到的痛点。但因为仍然是处于萌芽阶段，适合想对此系统有些贡献者。
．RIOT OS
RIOT OS被冠以「物联网中最佳操作系统」，以通讯概念为基础所建立起来的操作系统。即使在面对困难的通讯问题时，RIOT OS仍然精简且高效率操作。但即便如此，由于也还在积极发展的阶段，撰写程序时仍须花几个小时来进行除错。
依据项目发展 挑选软件框架
有些操作系统的功能就像是将砖块黏合在一起的水泥，会与发展框架紧密地结合在一块，因此一般而言，不能将其只使用在项目的某一部分，必须围绕着它来进行整个开发流程。这些框架往往是使用比C++更高阶的语言所撰写，通常可以在实时操作系统上运行。
．mbed
mbed也出现在这里，这时则是做为快速原型的项目。使用C++编写，并对大多数微控制器和电路板有绝佳的支持，拥有一个庞大的组件函式库和一个采用网页架构的漂亮集成开发环境(IDE)。在框架准备全面部署前，仍然需要一点成熟的时间，因而较适合硬件原型开发。
．Espruino
Espruino是在微控制器上运行的实时JavaScript解释器。允许动态更改程序代码，甚至不需要刻录微控制器便可以撰写程序代码。但其开始量产之前，仍然需要一些时间来发展，因而较适用于硬件原型。此外，Espruino有成为一个不可忽视的软件框架的巨大潜力。
．microPython
microPython所能做的事与Espruino大致相同，差别仅在于其使用Python而不是JavaScript。其发展的概念是，让开发者从产品开发的一开始到量产时，都有已预先编译程序的支持，并使用C语言来撰写时序关键的程序代码。其目前仍在开发当中。
．microEJ
microEJ是一个采用Java架构的框架，可轻松地为自身的装置打造好看的图形化应用程序，目前已经在许多智能手表和一些物联网(IoT)装置中使用。
以目的为依凭 贯彻项目执行
如果想要着手进行装置的开发，而无考虑量产事宜，诸如mbed和microPython这类的框架，便是入门的好方法。但若是要建立更大的部署，采用一个纯粹的实时操作系统将会是更好的选择。 但对于以工作时间取代金钱来做为软件投资的公司，FreeRTOS或RIOT这类非商业解决方案便有其优势。反之，要是能负担得起前期投资者，Segger、Express Logic和Micrium等商业解决方案，将大幅降低软件开发风险和缩短产品上市的时间。
在商业解决方案中，特别是如Micrium的稳定性和已认证的程序代码基础、广泛普及的部署、良好的零件支持、开放的原始码，以及易于负担的商业模式，更使其在商业解决方案中显得特别突出。
新通讯 2016 年 12 月号 190 期《 技术前瞻 》
文．Alf Petter Mossevig
