闪存|嵌入式开发：使用MCU进行无线更新面临的5大挑战控制器

使用引导加载程序更新嵌入式系统的能力是一项需要掌握的重要技能。尽管为开发嵌入式系统付出了所有努力，但要么在现场发现错误，要么最终用户要求附加功能。为了在现场或远程无线更新固件，嵌入式系统必须具有板载引导加载程序。对于作为物联网一部分的无线更新的嵌入式系统，嵌入式开发团队面临五个关键挑战。

挑战 1 – 代码大小
基于微控制器的应用程序过去非常小，最多只有8到16 KB 。现代微控制器可以为开发人员提供价值超过1024 KB 的应用程序代码空间。尽管容量和功能呈爆炸式增长，但对于希望通过无线方式更新固件的嵌入式程序员来说，代码大小是第一个挑战。
代码大小的挑战之一是微控制器通常没有用于正在运行的应用程序代码的板载文件系统，这与运行Linux的基于CPU的系统不同。由于文件不存在，目标文件被链接器连续放置在内存中。对应用程序的微小调整可能会导致更新整个闪存空间!为了防止这样的灾难，开发人员需要预先考虑对内存进行分区，并预测可能需要修改代码库的哪些区域。结果可能是板载闪存的使用效率低下，并增加了系统的相当复杂性。
挑战 2 – 带宽
通常，当嵌入式开发人员考虑与引导加载程序相关的带宽时，带宽用于确定更新应用程序所需的最大闪存时间。无线更新嵌入式系统可能会增加一些额外的挑战。
第一个挑战涉及需要在无线链路上工作的引导加载程序，这可能会产生与传输和接收数据相关的成本。在许多情况下，无线更新可能会通过WIFI或以太网执行，但使用蜂窝数据链路的移动设备呢?考虑到单个嵌入式系统，可能会忽略更新系统所需的单个MB应用程序代码，但是，当有数百万台设备需要更新时会发生什么?仅仅推出一个更新就可能产生相当大的成本。
开发引导加载程序的工程师，尤其是在无线执行更新的工程师，需要找到压缩应用程序映像的方法，以最大限度地减少空中传输的数据量。可以通过多种方式执行压缩，或者如果开发人员在每个对象基础上对闪存空间进行了分区，甚至可以使用diff文件。

挑战 3–稳健性
许多嵌入式开发团队面临的引导加载程序诱惑之一是使用芯片制造商提供的引导加载程序解决方案。芯片制造商解决方案的问题在于它们通常位于无法定制的ROM空间中。更重要的是，基于ROM的引导加载程序通常只是功能代码。功能代码可以在受控条件下执行目的，但不适用于任何事情发生的生产环境。
需要从一开始就将鲁棒性内置到引导加载程序解决方案中。引导加载程序应具有验证板载应用程序完整性的能力。引导加载程序应该能够检测到失败的固件更新并回滚到原始应用程序，而不是使系统变砖。在生产环境中，有许多事件可能会扰乱系统，但设计合理的引导加载程序将足够强大，可以顺利处理它们，而最终用户不会意识到存在问题。
挑战4 – 安全
许多基于微控制器的引导加载程序忽略了安全性，这是执行无线更新的开发人员面临的关键挑战。嵌入式开发人员可以采取的最简单的安全措施之一就是简单地锁定闪存系统，执行无线更新的开发人员可能会考虑加密他们的应用程序映像，以防止任何人深入了解专有固件，甚至是逆向工程和入侵系统。无线引导加载程序应具有用于验证更新过程的内置方法。
挑战 5 – 版本管理
管理将分发给潜在数百万台设备的固件版本并非易事。奇怪的是，固件更新不会一次全部推送，而是分批推送。更重要的是，有可能在某个时候存在不同版本的硬件，甚至可能为不同的最终用户提供不同的应用程序集。跟踪并确保固件顺利推出可能是一项重大挑战。