MCU上的资源有限，可能性有限?
微控制器(MCU)具有有限的资源，这可能会限制开发和应用的可能性。
由于它们经常需要更多的内存和计算能力，因此实现繁重的算法和功能具有挑战性。你不要在42MHz，2k RAM的MCU上运行Windows 11!开发人员需要优化他们的应用程序，通过专门为其目标开发来消耗更少的资源。这使得代码不灵活或不适应。同样，你不能运行Docker或任何虚拟化系统，因为它很重，你需要访问真实的硬件，而不是虚拟的硬件。
因此，嵌入式系统可能需要特定的工具来跟上技术进步并满足用户不断增长的需求和期望，这可能是一个很大的缺点。例如，随着物联网的发展和扩大，对具有尖端连接和计算能力的嵌入式设备的需求肯定会更大。提高他们能力的一种方法是考虑制作在互联网上运行的功能，但这变得很困难，因为连接并不总是有*的——你可能会失去连接，或者在某些困难的情况下被禁止。
这种系统临界性使得嵌入式开发人员更喜欢使用旧的但经过验证的技术，以避免可靠性意外。
随着时间的推移，MCU上有限的资源也可能使维护和更新嵌入式系统变得更加困难。正因为如此，我们正在创建我们的开源产品，以尽可能使用最少的系统资源。许多其他操作系统选项，如ROS，需要更多的资源，对于目前可用的最小设备来说是不够的。
由超定制需求驱动的整体理念
事实上，嵌入式系统经常被创建为针对特定目的或任务集合进行非常专业和优化的，这是开发如此落后的主要原因之一。这种超定制的理念导致一切从头开始重新制作，并导致单片代码，因为你的优先事项是使某些东西*，而不是开发一个适应的、可靠的、优化的和可伸缩的代码架构。
我们经常看到工业版模块化架构的梦想，但没有时间这样做——特别是因为它可能会损害大量*代码。所以最终，模块化架构的想法没有实现。
这使得在不实质性改变当前系统的情况下整合新技术或新功能变得非常困难。这种设计方法导致缺乏模块化和可重用性，最终减慢了开发过程，并增加了对原始设计进行更改时出现错误和缺陷的可能性。加剧这一问题的是，许多嵌入式系统使用专有的硬件和软件，这可能会限制嵌入式开发开发人员对底层代码的访问和控制。因此，嵌入式系统倾向于更慢地采用新技术。它们可能不如利用更模块化和更灵活的方法创建的系统灵活。
组件的多样性使整个系统变得复杂
这些系统种类繁多是嵌入式系统发展缓慢的另一个原因。嵌入式系统有大量的硬件和软件组件，所有这些组件在使用前都需要仔细集成和测试。复杂设备意味着多个电路板使用专用或定制的网络交换信息，有时甚至在同一产品中使用多种不同的网络技术。同样，所有这些都需要进行大规模测试。
这可能是一个劳动密集型且容易出错的过程，会减慢开发周期，并使快速实现新功能或新技术变得非常困难。由于其复杂性，创建和管理系统可能具有挑战性，因为可能需要特定的知识和经验来理解每个组件如何作为一个整体进行交互和运行。
对实时应用的需求给嵌入式领域增加了另一层重要的复杂性。最重要的是，你不能像在正常的软件调试过程中那样容易地从运行的嵌入式代码中提取信息。事实上，同样的人机界面在嵌入式(屏幕、键盘、互联网)中是不存在的。结果，调试和测试变得更加困难。我们看不到正在发生的事情。
像Luos这样的方法旨在为用户提供将系统活动实时视为数字孪生的能力。你可以使用Luos创建实际系统的数字复制品，以测试和观察任何潜在的问题。
让我们将微服务的愿景应用于这些问题
如今，嵌入式系统依赖于连接的子系统。我们称之为网络物理系统(CPS)。但独立的子系统并不意味着你不是单片的，你可能有不可能维护的单片子组件，也不直接与其他组件兼容。此外，为了连接整个系统的所有部分，嵌入式开发人员需要创建一个经过调整的通信系统，这可能需要花费大量时间才能使其可靠。你可能无法将其用于其他产品。
由于设计更改、产品可用性或任何其他外部变量，这种灵活性的缺乏导致许多与我们互动的开发人员重做他们的整个系统(数月的*)。半导体危机是众多僵化举措的一个典型例子，这些举措仅仅因为兼容性问题而被迫戛然而止。
网络物理系统可以利用许多紧凑、自主的服务来创建，这些服务由于微服务而易于组合和修改。我们必须把嵌入式系统看作一种产品，而不是一块板。
近年来，微服务哲学在软件行业越来越受欢迎，这为解决这些同样的问题提供了补救措施。微服务将软件应用程序分离为可管理的、自*含的部分，这些部分可以独立创建、部署和扩展。因此，开发人员可以轻松地添加新功能或技术，而无需对当前系统进行大的调整。微服务的模块化设计也使测试和实现新功能变得更简单，这有助于缩短开发周期。但正如本文开头所提到的，我们不能在嵌入式世界中使用相同的工具。像Luos项目这样的开源努力正在创造未来所需的工具。
延迟问题
在嵌入式系统中使用微服务可能存在一定的延迟问题。在考虑微服务时，开发人员可能会想到管理各种服务之间通信的延迟。基于微服务的系统将需要在服务之间进行一种板间IPC(进程间通信)，这可能会导致延迟。嵌入式开发人员可以通过测量延迟并使其对实时应用程序具有确定性来管理延迟。通过使用时间戳，它将允许你以数学方式计算延迟。我们可以使用排队和调度等策略来确保请求得到一致处理，并使延迟具有确定性。
市场需求
嵌入式系统的设计和构建通常是为了满足短期需求，但需要长期维护。因此，解决某些标准可能优先于添加可能需要一些时间才能变得必要或重要的新技术或功能。嵌入式系统适应不断变化的环境或不断发展的需求的能力可能会受到这种对实现精确目标的强调的阻碍。
在研发程序经常受到限制的情况下，从长远来看，考虑一个嵌入式项目需要更多的时间，从而需要更多的资金。因此，嵌入式系统可能难以跟上技术进步。考虑使事物具有适应性总是比在给定时间产生满足需求的系统更复杂。
此外，市场需求可能会迫使嵌入式系统开发采用同样久经考验的方法，这最终可能会使灵活性和互操作性面临挑战。
到目前*，已有一些项目试图建立一个“开发标准”，但很少有项目能在受嵌入式系统影响的各个领域真正获益。开源哲学可以成为一种解决方案。开源的使用*了无论发生任何意外事件(公司崩溃或出售)，你都可以长期维护你的系统。它由嵌入式开发人员社区维护，可以更好地适应你的需求，更新最新功能，并在开发方面具有灵活性。
以更可持续的方式发展
通过使用更可持续的方法，嵌入式系统的开发可以变得更加灵活和适应性，以及更加有效和资源高效。这种方法意味着开发可根据你的需求重复使用的代码，而不仅仅是当前的特定项目。这种可重用性可以应用于系统中的代码或组件，并且应该从可重用性的角度进行长期考虑，而不仅仅是针对当前的特定项目。
通过将你的全局系统划分为小代码块来开发你的项目，也将允许随着时间的推移进行更好的维护。这种维护将针对系统的单个元件，这样就不会改变整个系统的其他功能。
总结
总之，由于其复杂性、专业性以及对专有硬件和软件的依赖，嵌入式系统在发展方面落后于其他技术领域。然而，通过使用微服务或数字孪生等方法来思考一种新的系统开发方式，可以帮助开发人员在日常生活中发挥作用。
利用这种微服务的理念，我们正在创建一个开源项目，以增加嵌入式系统的灵活性。我们创建的许多工具可以帮助嵌入式开发人员更快、更轻松地编写代码。
