Embedded 最常见的固件更新协议

我应该为没有USB和程序内存大小有限的嵌入式设备选择（并可能实施）固件更新协议/软件/程序。该设备大部分时间将自动工作，但偶尔会有技术人员过来更新固件

如果我想使用RS232或CAN，更新协议最常见的选择是什么

更新的要求是：在中断更新后完成（我认为将需要引导加载程序），内存占用小，将用户设置与新引入的用户数据字段（在EEPROM中）合并，备份固件的早期版本并可能回滚更新，安全地更新引导加载程序本身

如果引导加载程序和更新客户端软件的实现也已经存在（至少对于Windows来说）那就太好了

出于好奇，对于使用USB的设备，有没有替代DFU的好方法

提前谢谢

我不确定“最普通”；我不确定是否有人能够权威地回答这个问题，或者这个答案是否有用。但是，我可以告诉您，我已经在一些设备（例如ARM 7、ARM Cortem-M、PIC24、TI C55xx）上用不到4KB的时间实现了XMODEM-CRC/XMODEM-1K。引导加载程序在每个支持更新的端口上发送XMODEM启动请求，然后对于每个端口，如果在短超时（几十毫秒）内收到响应，则传输继续。如果未收到响应，则应用程序将正常启动

在中断更新后完成（我假设需要引导加载程序）

我所采取的方法是，不立即将起始地址编程为接收时闪烁，而是将其横向复制，然后最后编程。引导加载程序在启动时检查启动地址，如果是0xFFFFFFFF（即未编程），则传输未完成，引导加载程序重新启动连续轮询XMODEM start

将用户设置与新引入的用户数据字段（在EEPROM中）合并

在我的例子中，我使用了Intel十六进制文件，但EEPROM内存通常不是内存映射的。您可以通过使用专有数据格式或将十六进制数据的地址设置为处理器上无效的区域来解决此问题，引导加载程序代码将识别为要发送到EEPROM的数据

备份以前版本的固件，并可能 回滚更新

这是引导加载程序实现的功能，而不是协议。当然，它要求您有足够的空间来存储应用程序的两个副本。未使用的副本可能会被压缩，但在引导加载程序中合并解压缩将增加其大小。一种可能更简单、成本最低的方法是让引导加载程序通过XMODEM支持当前应用程序映像的输出，从而允许将备份存储在主机上。但是，这样做可能会让第三方访问您的代码

安全地更新引导加载程序本身

这也是引导加载程序的功能，而不是协议。如果代码从RAM运行（也就是说，引导加载程序从ROM复制到RAM并执行，这样就很简单了。在这种情况下，在对闪存编程之前，尽可能安全地将整个引导加载程序数据加载到RAM中，以尽量减少目标没有引导加载程序的时间，从而使成功的编程不依赖于正在维护的主机连接自始至终

但是，如果引导加载程序从闪存运行，则无法从引导加载程序本身替换它。相反，您可以加载引导加载程序运行的应用程序，并在加载（或重新加载）最终应用程序之前替换引导加载程序

如果启动加载程序的实现和更新 客户端软件也已经存在（至少对于Windows）

任何终端仿真器软件，如TeraTerm、Hyperterminal、PuTTY等，都将支持XMODEM传输。使用广泛可用的XMODEM源代码，实现您自己的定制XMODEM发送器相对简单

只是出于好奇-有什么好的替代品DFU的 使用USB的设备

我所做的是在引导加载程序中实现一个CDC/ACM设备类USB堆栈，以便它在主机上显示为串行端口，然后使用与以前相同的XMODEM代码进行数据传输。这将引导加载程序的大小增加到大约12KB。它是使用堆栈和CDC/ACM（虚拟COM端口）实现的芯片供应商提供的应用说明。严格来说，你需要一个注册到你公司的USB供应商id（VID）；你不应该只使用任何旧id。

我不确定“然后是最常见的选择”是一个有用或合适的问题；其他人做了什么可能无关紧要。