执行于现代嵌入式系统中的软件往往出自各种来源。应用开发人员编写的程序代码通常结合RTOS供货商的现成软件组件，而这些组件又可能利用最初由半导体公司提供的驱动程序码。开发人员可以编写每段程序代码以优化效率，但本文更着重于现成软件组件中的效率优化。
对于开发人员来说，如果只是钻研最新的微控制器(MCU)规格表，很容易就会认为有效地使用了CPU资源(包括内存和频率周期)，这是目前在硬件设计上的一个小问题。最新的32位MCU可以为嵌入式系统提供闪存和RAM分配，这在不久前还是前所未闻的;而且其CPU通常还能与桌面计算机默认的运行速度一样。
然而，近来开发过物联网(IoT)产品的人都知道，这些硬件的进步并非空穴来风;它们一直在因应终端用户的期望和设计要求而发生显著的变化。因此，现在比以往任何时候都更重要的是：开发人员必须确保其软件以最高效率执行，并且能有效地利用时间。
执行于现代嵌入式系统中的软件往往出自各种来源。应用开发人员编写的程序代码通常结合了实时操作系统(RTOS)供货商的现成软件组件，而这些组件又可能利用最初由半导体公司提供的驱动程序码。开发人员可以编写每段程序代码以优化效率，但本文更着重于现成软件组件中的效率优化。特别是其中两个组成部份将作为审视资源效率的基础：实时核心和事务文件系统(transactional file system)。
实时核心：高效系统的核心
实时核心是执行于当今许多嵌入式系统中的软件核心。简言之，核心是一个排程器;为基于核心的系统编写应用程序代码的开发人员将程序代码分为多个任务，而核心就负责安排这些任务。那么，核心是main()中无限循环的替代方法，它常常作为裸机(bare-metal)嵌入式系统中的主要调度机制。
使用实时核心提供了重要优点，包括提高效率。选择将其应用程序代码用于核心基础的开发人员可以优化其系统中处理器资源的使用，同时更有效率地利用自己的时间。然而，并不是所有的核心都生而相同，因此，简单地决定在新的项目中采用核心，并不一定能保证提高效率。
“排程”(scheduling)是可能有不同核心且CPU资源的使用效率差异大的关键领域。透过提供一种允许任务以响应事件的方式执行的智慧调度机制，让核心有助于开发人员在无限循环中提升效率，并以固定顺序执行任务(或函数)。基于核心的应用程序之确切效率部份取决于其排程器的实现方式。一个核心的排程器(只是一段负责决定每项任务何时执行的程序代码)最终是一项开销，但它必须不能蚕食掉透过摆脱裸机系统获得的好处。
图1：在μC/OS-II排程器中，每一项任务的优先级由数组中的位表示 (来源：Micrium)
通常，在实时核心中，排程任务是基于优先级的，这意味着应用程序开发人员为其任务分配优先级(通常以时间数字表示)，而且在进行排程决策时，核心即可支持更高优先级的任务执行。在这种机制下，核心必须保持某种类型的数据结构，即追踪应用程序不同任务的优先级以及每项任务的当前状态。例如Micrium的μC/OS-II核心，如图1所示。
在OSRdyTbl[]中显示8-元素数组(每元素8位)，每个位表示不同的任务优先级;其中：第一个元素的最低有效位对应最高优先级;最后一个元素的最高有效位表示最低优先级。数组中的位值反映任务状态：如果相关优先级的任务准备就绪，则用1表示;若任务尚未准备就绪，就用0表示。
附带的OSRdyTbl[]是μC/OS-II排程器的一部份，即图中所示的单个八位变量——OSRdyGrp。该变量中的每个位表示数组中的一整行或元素：1位表示对应的行至少有一个任务就绪;0位表示该行尚无就绪的任务。透过使用列表1中所示的程序代码先扫描OSRdyGrp、再扫描OSRdyTbl[]，μC/OS-II即可确定在特定时间中准备好执行的最高优先任务。如列表所示，如此的作业方式十分高效率，只需要两行C程序代码。
当然，紧凑、高效率的程序代码只是开发人员在核心中寻求的特性之一。有鉴于大多数新款MCU提供的闪存相对多于RAM，对于开发人员来说，考虑核心所占用空间的资料端也很重要。对于核心的排程器来说，庞大的RAM占用空间导致过多的开销，从而减少了多任务应用程序代码通常具有的好处。
核心可以采用两种方法来分配多任务处理所需的基本资源：分配这些资源的责任可以留给应用程序代码，或是本身可以处理分配的核心。在任何核心中必然存在某些变量和数据结构，因为它们对于执行多任务服务至关重要，所以这些变量和数据结构完全存放在核心中。然而，对用于记录每个任务状态的任务控制区块(TCB)等数据结构，或甚至在情境切换期间储存CPU缓存器值的堆栈，核心供货商可以选择在内部进行分配或交给应用程序代码来实现。
无论是哪一种方法，只要在建置时以灵活性为目标之一，即可产生一个高效核心。延迟将资源分配给应用程序代码也是为开发人员提供最大灵活性的方法之一，因为它提供了选择静态或动态分配机制的空间。Micrium的μC/OS-III即采用这种方法，让应用开发人员决定如何最有效地分配其TCB和堆栈。然而，如同在μC/OS-II的TCB情况一样，强制在核心中实施资源分配是同样有效的方法，只要能配置分配资源量的方法即可。最终，应用开发人员需要一种从系统的内存空间中消除未使用资源的方法。
文件系统效率
大多数的装置都需要储存数据和记录事件的选项，作为在传送到云端之前的临时保存空间、或者是更长久地储存在装置上。为此目的设计的任何程序代码就是文件系统，无论是由开发人员编写和测试的，还是以RTOS解决方案的一部份提供。文件系统还可以提供效率选项，其范围从简单(保留多少内存缓冲)到复杂(是否支持完整的POSIX作业)。
开发人员应该从对于储存数据的要求开始。数据是否能在现场进行操作?或只是暂存并在稍后传送?要测量多少内容?数据应该分开或合并储存?数据暂时储存至装置进行收集之后?还是要传送到云端?储存媒体有多可靠?设计能完全免受于电源故障的影响吗?
首先，有些RTOS提供类似FAT的文件系统。这包括使用标准媒体格式(包括文件夹和档案)执行I/O的程序代码。一般来说，其可订制程度有限，很少能防范电源故障时的数据遗失。另一个选择是Datalight的Reliance Edge，它采用交易点提供电源故障安全环境，其令人振奋之处在于设计的灵活性如何有助于提高效率。
Reliance Edge提供储存选项的订制化。在最小化的用例中，它称为「文件系统要素」，不必使用文件夹或甚至档名。数据储存于编号的索引节点(inode)中。这些位置的计数在编译时确定，但大小无需预先确定。一个「档案」可能包含较其它档案更多的数据，并且仅在「档案」的总容量达到阈值时，储存媒体才算满载。还可自由地对档案进行截取、读取和写入。
图2：FAT文件系统与Reliance Edge (来源：Datalight)
相形之下，FAT格式的文件系统具有专用于两种文件分配表的媒体建构模块。针对每个用户数据文件，为其分配档名和元数据——前者可能相当大以支持较长的档名。如果使用子文件夹，其元数据和长文件名也将会占用空间。所有的结果都会导致储存媒体上用于收集用户数据的可用空间变少。
对于较大的设计，Reliance Edge提供了更像是POSIX的环境。这里的文件名、文件夹和文件系统元数据(如属性以及数据和时间)是一种可配置的选项。对于期望从其它设计移植POSIX界面的应用来说，这可能是非常好的选择。最终，文件系统要求的最终选择与用例直接相关，成为最有效率的资源方案。
全面考虑效率
除了资源使用问题之外，多年来，在购买核心、文件系统和其他软件模块时，效率一直是开发人员关注的头等大事。这是因为用于证明采用这种模块的理由通常是：从头开始编写等效的程序代码相当浪费时间。换句话说，应用开发人员最有效的时间利用是编写应用程序，而不是埋首于数万行的基础架构程序代码。
然而，正如核心和文件系统的使用本身并不能保证CPU资源的有效应用一样，将这些模块导入新项目的决定，也不会自动确保开发人员能最有效地利用时间。为了让开发人员真正专注于应用级程序代码，嵌入式软件模块必须具有直观的接口，该接口还必须有详尽的文档介绍。在缺乏有效文档的情况下，开发人员可能要花数周的时间解决事后证明是函数误用导致的问题。
遗憾的是，如果无法可靠地实现所描述的功能，即使是文文件编写良好的程序代码也会不必要地浪费开发时间。这就是为什么除了要求完整的文档外，开发人员在为新项目选择软件时，应寻求可靠性证据——例如过去的认证或测试结果。实际上，每个软件模块在宣传文献中听起来都很可靠，但只有一部份模块提供了可靠证明能确保其「言行一致」。例如，Datalight的Reliance Edge就提供了各种不同测试的源代码，让应用开发人员确认文件系统在特定开发环境中能否可靠执行。
以最佳效率开发物联网医疗装置
什么类型的开发环境可能出现在物联网项目中?有鉴于嵌入式装置对于连接性的要求迅速增加，不可能确定一种硬件、软件和工具链的特定组合来界定这个范围。要找到一种能完全代表物联网可能范围的终端产品同样具有挑战性。尽管如此，这一领域的讨论当然可以从具体的例子中受益。
为了说明物联网开发人员面临的挑战，本文以一款在几年前还未被视为连网装置的血糖仪为例。这种产品的关键特征之一是市场容量：血糖仪每年的产量有数百万，并且往往以低于成本的价格出售，甚至免费赠送。因此，降低BOM成本，并以最少时间开发这些仪器的压力很大。不过，开发这些设备并不容易。事实上，新的血糖仪功能增加了彩色显示、数据记录功能和云端连接。
面对如此复杂的需求，负责血糖仪开发的团队当然希望利用核心的多任务处理功能。优化核心的内存占用空间可能是开发团队的首要关注之一，因为典型的高产量、低成本MCU往往只有有限的闪存和RAM资源。减少空间占用的关键步骤是删除应用程序代码不需要的核心资源(如TCB)。消除应用中各种核心管理任务所需的堆栈耗费也将会有帮助。
例如像Micrium μC/Probe这样的工具，可用于实现这一目标，如图2所示。μC/Probe可以深入了解基于核心的应用的堆栈使用情况，让开发人员轻松地辨识低效情况，以及提高效率。
图3：μC/Probe提供对于系统数据的运行时间存取，包括核心统计信息 (来源：Micrium)
当实施血糖仪的数据记录功能时，仪器的开发团队将可从文件系统的功能中受益。在此，与核心一样，使用现成的软件模块可以减轻开发基础架构程序代码的负担，从而有助于实现时间更短、更具成本效益的开发周期。处理器资源的使用一直是系统的整体限制之一，在开发数据记录程序代码时不可避免地必须予以考虑，因此使用高效的事务文件系统较为理想。藉由Reliance Edge等文件系统方案，开发团队可以轻松地将服务缩减到最低限度，以便尽量为应用程序留出最多的储存空间。
结论
虽然每个嵌入式系统都有其独特的需求，但适于为血糖仪实现最高效率的方法也可以轻松地用于开发其它装置类型。重复利用组件早已被公认为软件开发的最佳实践，而血糖仪所需的许多基础架构程序代码(包括实时核心和文件系统)可以作为其它装置开发的基础，除了替换少数底层程序代码外，仅需很少改动。
透过选择具有质量保证的现成组件作为项目的基础，开发团队可以确保自己的资源以及嵌入式硬件的有效利用，并且可以专注于编写创新的应用程序代码，使其设计在众多的产品中脱颖而出。物联网创新的曙光已经开始闪烁。
（采编：www.znzbw.cn）
