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

对信息的感知、组织、分析、呈现和决策需要软件。几十年来，我们一直在使用各种平台以不同的功能级别执行此操作。现在，我们已经有了由单节电池运行的极小设备，其功率从 1990 年代后期开始基于 80486 的个人计算机，下一个问题很明显——软件。有了裸机、实时操作系统（RTOS）和真正的操作系统（如Linux）可供选择，我们将遇到在Radio和Computer中探索的类似问题，但从软件的角度来看。

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

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

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

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

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

安全性和安全性与硬件密切相关，在这些硬件中，系统按照确切的期望执行和运行，并且系统一直一直以这种方式运行。

硬件成本存在限制，需要出色的效率。

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

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

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

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

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

审核编辑：郭婷