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