构建嵌入式解决方案的各种CPU架构的软件注意事项

感知、组织、分析、呈现和决策信息需要软件。几十年来，我们一直在使用各种平台以不同级别的能力来执行此任务。现在，我们拥有非常小的设备，这些设备由单节电池运行，具有1990年代后期基于80486的个人计算机的功率，下一个问题是显而易见的 - 软件。有了裸机的实时操作系统（RTOS）和像Linux这样的真实操作系统可供选择，我们将遇到无线电和计算机中探索的类似问题，但从软件的角度来看。

从可扩展的软件架构开始是任何嵌入式应用所必需的。在最终确定嵌入式应用程序的编程体系结构之前，必须考虑将来可能调用的增强软件。许多工程师认为这是事后的想法，因为他们习惯于在操作系统之上编写代码。

另一个重要的考虑因素是成本。随着系统功能的增加，对更快的处理器、更多的代码内存和 RAM 的需求也在增加。下面的图 1 显示了嵌入式系统的典型功能与成本关系图，尽管在可能的硬件选择方面，不同层之间的界限是模糊的：

在以下情况下，首选裸机编程：

该应用程序很简单，可以在低端处理器上实现。

应用程序需要提取每个周期的CPU功率，并且操作系统引入的开销是不可接受的。

安全性和安全性与硬件密切相关，其中系统按照确切的期望执行和运行，并且系统一直处于这种状态。

硬件成本受到限制，并且需要出色的效率。

许多嵌入式应用程序是无限循环，其中它们执行一个任务，然后执行另一个任务，依此类推，重复相同的功能。这些任务中的大多数都是相互依赖的。裸机编程对于代码应该是可预测的、可理解的、并且应该易于调试的情况并不理想。拥有调度程序使嵌入式工程师的生活更加简单 - 每个软件模块都可以独立设计，然后使用调度程序的帮助与其他软件模块链接和调度。因此，随着代码复杂性的增加以及系统需要功能强大的微处理器/微控制器，RTOS是首选。当MCU集成更多内存和外设时，实时操作系统成为必需品。复杂的物联网应用可能需要更多的中断源、更多的功能和更多的标准通信接口——主要是无线。在如此复杂的解决方案中可能需要RTOS。

实时操作系统可以充分利用功能丰富的MCU，特别是当提供中间件可以处理复杂任务时，否则将需要真正的操作系统。但是，在软件方面，有许多不重叠的复杂性和功能领域。具有添加中间件的RTOS可以接近通用操作系统的功能。例如，中间件可以添加文件系统、网络、图形和复杂输入支持等功能，尽管与本地支持这些功能的真正操作系统相比，需要增加开发工作。一些远程操作系统甚至支持 POSIX API，这些 API 可以在一定程度上重用来自 Linux/Unix 应用程序的代码。

但是，当应用程序复杂性增加到超过特定限制时，通用嵌入式操作系统就会显现出来。这时，处理器会说：“给我一个MMU，我就可以解决你所有的问题。由于其代码大小和主存储器要求，昂贵的SRAM和NOR存储器变得不切实际。大多数嵌入式版本的通用操作系统需要至少 16-32 MB 的主内存和 64+MB 的代码存储才能正常运行。幸运的是，应用处理器和通用操作系统能够处理更便宜、更慢的存储器，如DRAM和NAND闪存。

当您迁移到嵌入式通用操作系统时，您不会丢失“实时功能”。它们能够以略高的延迟级别运行实时应用程序，具有不同级别的确定性（“软实时”）。但大多数应用程序不需要“硬实时”功能。在嵌入式操作系统上运行的经过良好验证的应用程序可以像在中间件的帮助下在RTOS上运行的类似应用程序一样防弹和确定性。

由于持续的硅扩展以及大量工程师对合适的操作系统更满意，应用处理器和内存的成本每年都在降低，许多本来会使用RTOS的应用程序现在发现应用处理器+适当的操作系统组合具有成本效益，并且还缩短了上市时间。

审核编辑：郭婷