我应该选择（并且可能实现）没有USB且程序存储器大小有限的嵌入式设备的固件更新协议/软件/程序。该设备大部分时间都可以自动工作，但偶尔会有技术人员来更新固件。
如果我想使用RS232或CAN，那么更新协议最常见的选择是什么？
更新的要求是：在中断更新后完成（我需要引导加载程序），占用内存小，将用户设置与新引入的用户数据字段（在EEPROM中）合并，备份以前的版本固件可以回滚更新，安全地更新启动加载器本身。
如果已经存在启动加载程序和更新客户端软件的实现（至少对于Windows），那将是很好的。
出于好奇 - 对于带有USB的设备，DFU有什么好的替代方案吗？
提前致谢
答案 0 :(得分：2)
我不确定＆＃34;最常见的＆＃34 ;;我不确定是否有人可以权威地回答这个问题，或者答案是否有用。但是我可以告诉你，我已经在不到4K字节的许多设备（例如ARM 7，ARM Cortem-M，PIC24，TI C55xx）上实现了XMODEM-CRC / XMODEM-1K。引导加载程序在每个支持更新的端口上发送XMODEM启动请求，然后对于每个端口，如果在短暂超时（几十毫秒）内收到响应，则继续传输。如果没有收到响应，则正常启动应用程序。
在中断更新后完成（需要引导加载程序，我假设）
我采取的方法是不立即将起始地址编程为闪存，但要将其复制到横向然后再编程。引导加载程序在启动时检查起始地址，如果它是0xFFFFFFFF（即未编程），则传输未完成，并且引导加载程序重新开始连续轮询XMODEM启动。
将用户设置与新引入的用户数据字段（在EEPROM中）合并，
在我的情况下，我使用的是英特尔HEX文件，但EEPROM内存通常不是内存映射的。您可以通过使用专有数据格式或将HEX数据的地址设置为处理器上无效的区域来解决这个问题，而引导加载程序代码将识别该区域作为要发送到EEPROM的数据。
可以备份以前版本的固件 滚动更新，
这是引导加载程序实现的功能，而不是协议。它当然要求您有足够的空间来存储应用程序的两个副本。未使用的副本可能是压缩的，但在引导加载程序中加入解压缩将增加其大小。一种可能更简单且成本最低的方法是让引导加载程序通过XMODEM支持当前应用程序映像的输出，从而允许备份存储在主机上。但是，通过这样做，您可能会使第三方访问您的代码。
安全地更新引导加载程序本身。
同样，这是您的引导加载程序的功能，而不是协议。如果代码从RAM运行（即引导加载程序从ROM复制到RAM并执行，那么它很简单。在这种情况下，如果可能的话，最安全的是在编程闪存之前将整个引导加载程序数据加载到RAM中以便最小化时间目标没有引导加载程序，因此成功编程不依赖于整个主机连接。
但是，如果引导程序从闪存运行，则无法从引导加载程序本身替换它。相反，您可以加载引导加载程序运行的应用程序，并在加载（或重新加载）最终应用程序之前替换引导加载程序。
如果启动加载程序和更新的实现会很好 客户端软件也已经存在（至少对于Windows而言）。
任何终端仿真器软件（如TeraTerm，Hyperterminal，PuTTY等）都将支持XMODEM传输。使用XMODEM源代码可以实现自己的自定义XMODEM发送器相对简单。
出于好奇 - 有什么比DFU更好的选择 带USB的设备？
我所做的是在引导加载程序中实现CDC / ACM设备类USB堆栈，使其在主机上显示为串行端口，然后使用与以前相同的XMODEM代码进行数据传输。这增加了引导程序的大小;在我的情况下大约12千字节。它是使用芯片供应商提供的堆栈和CDC / ACM（虚拟COM端口）应用程序实现的。严格来说，您需要在公司注册USB供应商ID（VID）;你不应该只使用任何旧的身份证。