如何最大限度地提高物联网项目的效率

大幅提高物联网项目的效率

作者：Matt Gordon；Thom Denholm, Silicon Labs（亦称“芯科科技”）

如果只研读最新的微控制器数据手册的话，开发人员会很容易认为高效使用CPU资源(包括内存和时钟周期)，是目前硬件设计中的一个小问题。最新的32位MCU可以在嵌入式空间提供闪存和RAM分配，这在不久前都是闻所未闻的；并且其CPU与之前台式机独有的运行速度一样。然而，近来开发过物联网产品的人都知道，这些硬件的进步并非空穴来风；它们一直因应着最终用户的期望和设计要求显著地变化着。因此，现在比以往任何时候都更重要的是：开发人员要确保其软件以最大效率运行，并且有效地利用他们的时间。

在现代嵌入式系统中运行的软件往往有各种来源。应用开发人员编写的代码通常与RTOS(实时操作系统)提供商的现成软件组件相结合，而这些组件又可能利用最初由半导体公司提供的驱动程序代码。开发人员可以编写每段代码来优化效率，但本文更着重于现成的软件组件中的效率优化。特别是其中两个组成部分将作为审视本文给出的资源效率的基础：实时内核和事务文件系统(transactional file system)。Silicon Labs（亦“芯科科技”）将通过本篇技术文章说明如何最大限度地提高物联网项目的效率，欢迎点击“阅读原文”观看完整文章。

实时内核：高效系统的核心

实时内核是当今许多嵌入式系统中运行的软件的核心。简单说，内核是一个调度程序；为基于内核的系统编写应用程序代码的开发人员将代码分为任务，内核负责安排这些任务。那么，内核是main()中无限循环的替代方法，它常常作为裸机(bare-metal)嵌入式系统中的主要调度机制。使用实时内核提供了重要优点，包括提高效率。选择将其应用代码基于内核的开发人员可以优化其系统中处理器资源的使用，同时更有效地利用自己的时间。然而，并不是所有的内核都生而相同，因此简单地决定在新项目中采用内核，并不能保证效率的提升。

调度是内核可能不同且CPU资源的使用效率可以有很大差异的关键领域。通过提供一种允许任务以响应事件的方式运行的智能调度机制，内核可帮助开发人员在无限循环中提升效率；其中以固定顺序执行任务(或换句话说，函数)。基于内核的应用程序的确切效率部分取决于其调度程序的实现方式。一个内核的调度程序(只是一段负责决定每个任务何时运行的代码)最终是种开销，这个开销必须不能蚕食掉通过摆脱裸机系统获得的好处。

通常，在实时内核中，调度是基于优先级的，这意味着应用程序开发人员为其任务分配优先级(通常为数字)，并且在做出调度决策时，内核支持更高优先级的任务运行。在这种机制下，内核必须保持某种类型的数据结构、跟踪应用程序不同任务的优先级以及每个任务的当前状态。

从Micrium的­C/OS-II内核获取的一个例子如图1所示。在OSRdyTbl []中，这里显示的是8元素数组(每元素八位)，每个位表示不同的任务优先级；其中：第一个元素中的最低有效位对应最高优先级；最后一个元素中的最高有效位表示最低优先级。数组的位值反映任务状态：如果相关优先级的任务准备就绪，则用值1表示；若任务未准备就绪，就用0表示。作为­C / O S - I I调度程序的一部分，附带的OSRdyTbl []是图中所示的单个八位变量—OSRdyGrp。

图1：在μC/OS-II调度程序中，每个任务优先级由数组中的位表示

该变量中的每个位表示数组中的一整行或元素：1位表示对应的行至少有一个就绪任务；0位表示该行的任务都没就绪。通过使用清单1中所示的代码首先扫描OSRdyGrp、再扫描OSRdyTbl[]，­C/OS-II可以确定在任何给定时间已准备好运行的最高优先级任务。如列表所示，此操作很高效，只需要两行C代码。当然，紧凑、高效的代码只是开发人员在内核中寻求的特性之一。鉴于大多数新MCU提供的闪存要相对多于RAM，对于开发人员来说，考虑内核所占用空间的数据端也很重要。对于内核的调度程序来说，臃肿的RAM占用会导致过多开销，从而减少多任务应用程序代码通常带来的好处。

内核可以采用两种方法来分配多任务所需的基本资源：分配这些资源的责任可以留给应用代码；或者内核本身可以处理分配。在任何内核中必然会存在某些变量和数据结构，因为它们对于执行多任务服务至关重要，所以这些变量和数据结构完全放在内核中。然而，对诸如用于记录每个任务状态的TCB(或任务控制块)等数据结构，或甚至对于在上下文切换时存储CPU寄存器值的堆栈，内核提供者可以选择在内部分配或依赖应用代码实现。

任何一种方法，如果实现时以灵活性为目标之一，都可以产生一个高效内核。延迟将资源分配给应用代码也许是为开发人员提供最大灵活性的方法，因为它为静态，或动态分配机制留有选择。 Micrium的­C/OS-III采用这种方法，让应用程序开发人员决定如何最好地分配其TCB和堆栈。然而，如同Micrium的­C/OS-II中的TCB情况一样，强制在内核中实施资源分配可以是同样有效的方法，只要有能配置所分配资源量的方法即可。最终，应用开发人员需要一种从系统的内存空间中消除未使用资源的方法。

文件系统效率

大多数设备需要存储数据和日志事件的选项，作为在传送到云之前的临时保存空间、或者是更长久地存储在设备上。为此目的设计的任何代码都是文件系统，无论是由开发人员编写和测试的、还是作为RTOS方案的一部分提供。文件系统还可以提供效率选项。其范围可从简单(保留多少内存缓冲区)到复杂(是否支持完整的POSIX操作)。

开发人员应从其数据存储要求开始。该数据是否在现场进行操作？或仅存储并稍后传送？要测量多少内容？其数据应该分开或组合吗？在对设备实施数据采集前先行存储数据吗？还是将其传送到云？存储介质有多可靠？设计能完全免受电源故障的影响吗？首先，一些RTOS提供类似FAT的文件系统。这包括使用标准介质格式(包括文件夹和文件) 执行I /O的代码。一般来说，其可定制程度受限，很少能防范电源故障时的数据丢失。

另一个选择是Datalight的RelianceEdge，它使用交易点(transactionpoint)来提供里令人兴奋的是：设计的灵活性如何有助于提高效率。Reliance Edge提供存储选项的定制。在最小用例中，称为“文件系统要素”，不使用文件夹甚至文件名。数据存储到编号的inode中。这些位置的计数在编译时确定，但大小不是预先确定的。一个“文件”可以包含比其它文件更多的数据，并且仅当“文件”的总大小达到阈值时，存储介质才装满。还可自由地对文件进行截取、读取和写入。

相比之下，FAT格式的文件系统具有专用于两个文件分配表的介质块。对于每个用户数据文件，分配了文件名和元数据—前者可能相当大以支持长文件名。如果使用子文件夹，其元数据和长文件名也将占用空间。所有这些都会导致存储介质上所收集的用户数据可用空间变少。

对于较大的设计，Reliance Edge提供了更像POSIX的环境。这里的文件名、文件夹和文件系统元数据(如属性以及数据和时间)是一个可配置选项。对于期望从其它设计移植POSIX接口的应用来说，这可能是个非常好的选择。最终，文件系统要求的最终选择与用例直接相关，这是迄今为止最有效的资源方案。

全面考量效率

除了资源使用问题之外，多年来，在购买内核、文件系统和其他软件模块时，效率一直是开发者关注的头等大事。这是因为用于证明采用这种模块的理由通常是：从头开始编写等效的代码是浪费时间。换句话说，应用开发人员最有效的时间利用是编写应用程序，而不是死磕数万行的基础架构代码。

然而，正如内核和文件系统的使用本身并不能保证CPU资源的有效应用一样，将这些模块引入新项目的决定，也不会自动确保开发人员能最有效地使用其时间。为了真正让开发人员专注于应用级代码，嵌入式软件模块必须具有直观的界面，并且该界面必须有详尽文档。在没有有用文档的情况下，开发人员可能要花数周的时间来解决事后证明是函数误用导致的问题。

不幸的是，如果不能可靠地实现所描述的功能，甚至文档编写良好的代码也会不必要地浪费开发时间。这就是为什么除了要求完整的文档外，开发人员在为新项目选择软件时，应寻求可靠性证据—例如过去的认证或测试结果。实际上，每个软件模块在宣传文献中都是可靠的，但只有部分模块提供了可靠证明，能保证它们“言行一致”。

例如，Datalight的Reliance Edge就有用于各种不同测试的源代码，允许应用开发人员确认文件系统在特定开发环境中能否可靠运行。示例：开发具最高效率的IoT医疗设备什么类型的开发环境可能出现在物联网项目中？鉴于嵌入式设备中连接需求的快速增长，不可能确定一种硬件、软件和工具链的特定组合来界定这个范围。找到完全代表物联网可能性范围的单一终端产品同样具有挑战性。尽管如此，这一领域的讨论当然可以从具体的例子中受益。一种有助于说明物联网开发者面临的一些挑战的产品，就是在几年之前甚至不会被认为是种连接设备的—血糖仪。

该产品的关键特征之一是市场容量：血糖仪每年的产量有数百万，并且往往以低于成本的价格出售，甚至免费赠送。因此，降低BOM成本，并最短化这些仪器开发时间的压力很大。不过，开发这些设备并不容易。事实上，新血糖仪的功能列表可能包括彩色显示、数据记录功能和云连接。面对如此复杂的需求列表，负责血糖仪开发的团队当然希望利用内核的多任务功能。优化内核的内存占用可能是该团队的首要关注点之一，因为典型的高产量、低成本MCU往往只有有限的闪存和RAM资源。减少空间占用的关键步骤是删除应用代码不需要的任何内核资源(如TCB)。消除应用的各种内核管理任务所需的堆栈中的浪费也将会有帮助。

像Micrium的­C/Probe这样的工具，可用于实现这一目标，其截图如图2所示。­C/Probe可以深入了解基于内核的应用的栈(stack)和堆(heap)的使用情况，使开发人员能够轻松识别低效并提高效率。当实施血糖仪的数据记录功能时，仪器的开发团队将受益于文件系统的功能。在此，与内核一样，使用现成的软件模块可以减轻团队开发基础架构代码的负担，从而有助于实现短得多、具成本效益的开发周期。处理器资源使用作为系统的总体约束之一，在开发数据记录代码时不可避免地需要予以考虑，因此使用高效的事务文件系统是理想情况。

图2：FAT文件系统与Reliance Edge (资料来源：Datalight)

借助Reliance Edge等文件系统方案，开发团队可以轻松地将服务缩减到最低限度，以便为应用程序留出尽可能多的存储空间。

图3：μC/Probe提供对系统数据的运行时访问，包括内核统计信息(来源：Micrium)。

结论

虽然每个嵌入式系统都有其独特的需求，但是适用于最大限度提高血糖仪效率的方法可以很容易地用于开发其它类设备。组件重用早已被公认为软件开发的最佳实践，血糖仪所需的许多基础架构代码(包括实时内核和文件系统)可以作为其它设备的基础，除了替换少数底层代码外，仅需很少改动。通过选择质量有保证的现成的组件作为项目基础，开发团队可以确保自己的资源以及嵌入式硬件的有效利用，并且可以专注于编写创新的应用代码，使其设计在众多的产品中脱颖而出。物联网创新的曙光已经开始闪亮