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

控制块)等数据结构，或甚至对于在上下文切换时存储CPU寄存器值的堆栈，内核提供者可以选择在内部分配或依赖应用代码实现。

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

文件系统效率

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

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

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

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

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

全面考量效率

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

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

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

例如，Datalight的Reliance Edge就有用于各种不同测试的源代码，允许应用开发人员确认文件系统在特定开发环境中能否可靠运行。示例：开发具最高效率的IoT医疗设备什么类型的开发环境可能出现在物联网项目中？鉴于嵌入式设备中连接需求的快速增长，不可能确定一种硬件、软件和工具链的特定组合来界定这个范围。找到完全代表物联网可能性范围的单一终端产品同样具有挑