使用MCU进行无线更新面临的5大挑战

使用引导加载程序更新嵌入式系统的能力是一项重要的技能。尽管开发嵌入式系统付出了很多努力,但还是在现场发现了错误,还是最终用户要求了其他功能。为了在现场或通过无线方式远程更新固件,嵌入式系统必须在板载引导程序。对于作为物联网一部分进行无线更新的嵌入式系统,开发团队面临着五个主要挑战。

挑战#1 –代码大小

基于微控制器的应用程序过去非常小,最多约为8至16 KB。现代微控制器可以为开发人员提供多达1024 KB的应用程序代码空间。尽管容量和功能出现了爆炸式增长,但是代码大小仍然是寻求通过无线方式更新其固件的嵌入式程序员的第一个挑战。

代码大小的挑战之一是,与运行Linux的基于CPU的系统不同,微控制器通常没有用于正在运行的应用程序代码的板载文件系统。由于文件不存在,因此链接器将目标文件连续放置在内存中。对应用程序进行细微调整可能会导致更新整个闪存空间!为避免此类灾难,开发人员需要预见到对内存进行分区的预期,因为可能需要修改代码库的哪些区域。结果可能是板载闪存的使用效率低下,并且增加了系统的复杂性。

挑战2 –带宽

通常,当开发人员考虑与引导加载程序有关的带宽时,该带宽用于确定更新应用程序所需的最大刷新时间。通过空中更新嵌入式系统可能会带来另外两个挑战。

第一个挑战涉及引导加载程序,该引导加载程序需要通过无线链路工作,这可能会带来与发送和接收数据相关的成本。在许多情况下,空中更新可能会通过WIFI或以太网进行,但是使用蜂窝数据链路的移动设备又如何呢?考虑到一个嵌入式系统,可能会忽略更新系统所需的一兆字节的应用程序代码。但是,当有数百万个设备需要更新时会发生什么?仅推出一个更新就可能会产生可观的成本。

开发自举程序的工程师,尤其是正在通过空中执行更新的自举程序,需要找到压缩应用程序映像的方法,以最大程度地减少通过空中传输的数据量。压缩可以通过多种方式执行,或者如果开发人员在每个对象的基础上划分了闪存空间,则甚至可以使用diff文件。

挑战3 –稳健性

许多开发团队面临的引导加载程序诱惑之一是使用芯片制造商提供的引导加载程序解决方案。芯片制造商解决方案的问题在于它们通常位于无法定制的ROM空间中。更重要的是,基于ROM的引导加载程序通常只不过是功能代码。功能代码可以在受控条件下实现目标,但不适用于任何环境的生产环境。

从一开始就需要将健壮性内置到引导加载程序解决方案中。引导加载程序应具有验证机载应用程序完整性的功能。引导加载程序应该能够检测到失败的固件更新并回滚到原始应用程序,而不是阻塞系统。在生产环境中,有许多事件可能会使系统崩溃,但是经过适当设计的引导加载程序将足够强大,可以平稳地处理它们,而最终用户永远不会意识到存在问题。

挑战4 –安全

许多基于微控制器的引导加载程序忽略了安全性,这是开发人员执行空中更新所面临的关键挑战。开发人员可以采取的最简单的安全措施之一就是简单地锁定闪存系统。正在执行无线更新的开发人员可能会考虑对其应用程序映像进行加密,以防止任何人深入了解专有固件,甚至阻止反向工程和入侵系统。空中引导加载程序应具有内置方法来认证更新过程。

挑战5 –版本管理

空中引导加载程序开发人员面临的讨论中的最后挑战是版本管理。管理将分发给可能数百万个设备的固件版本并非易事。奇怪的是,固件更新不会一次全部推送,而是分批推送。更重要的是,有可能在某个时候存在不同版本的硬件,并且对于不同的最终用户而言甚至可能存在不同的应用程序集。保持跟踪并确保固件顺利推出可能是一个重大挑战。

结论

引导加载程序通常在开发周期结束之前都会被忽略,但是它们在嵌入式系统中起着至关重要的作用。此处提出的五个挑战只是嵌入式软件开发人员所面临的几个挑战,他们正在使用微控制器开发连接的系统。

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.