不容忽视的嵌入式软件兼容性问题

嵌入式项目中，软件是一个不断迭代的过程，需要考虑各种兼容性。之前我们的项目，因为这方面考虑得比较少，导致项目中后期开发起来很被动。

项目系统总体设计阶段，应尽可能地考虑到未来可以遇见的情况，覆盖到尽可能多的业务扩展。项目虽然分阶段开发，各个阶段完成的功能都不一样，总体设计要指向最终的需求。

数据兼容性

1、协议制定

制定的协议要满足整个项目所有数据的交互。

比如：

这里的 ID 设置为 1 个字节，可能有一定的风险。后面功能加着加着，可能 1 个字节的 ID 满足不了，就得改协议。尽管可能满足了某个项目的需求，但万一之后其它项目也用了这一套代码，但是 1 个字节的 ID 满足不了，又得改代码。这里设置 2 字节可能会好一点，基本上能满足绝大部分情况的使用。

不一定为了覆盖范围更广而设置 4 字节，这样可能有点冗余。很多情况都有一个平衡点，需要自己权衡。

Length字段只设置了 1 个字节，可能也有一定的奉献。后面功能中如果有发较大的数据，可能要分好多包发，原本可以发得很快，被这里限制死了。到时候想要提速，就得改协议。

之前项目里，几块板间的通信都用同一套协议。但后期发现该协议满足不了新需求，但为了不影响到前面的数据，又搞了一套协议。导致项目里有两套差不多一样的协议处理代码。

协议应该是项目一开始考虑好、制定好，整个项目开发期间，都不应该再做改动。

2、数据添加

后面新增的数据，不应该插入现有的数据中，应该单独增加一个数据ID。

比如：

现有的数据中，有一条数据叫做设备信息的数据，设备信息里包含了：设备IP、设备Mac。这个数据会显示在手机APP上。对应的 C 语言代码：

#define MSG_ID_DEV_INFO   0x0001 typedef struct _dev_info { char dev_ip[IP_MAX_LEN]; char dev_mac[MAC_MAX_LEN];
}dev_info_t;

假如后面需要再显示一个设备的sn，这个数据我们应该加在哪里？

如果是项目前中期，这时候还是在开发阶段，我们可以随意修改。因为设备sn也是设备信息的一部分，可以直接在设备信息这个数据里添加会比较合理：

#define MSG_ID_DEV_INFO   0x0001 typedef struct _dev_info { char dev_ip[IP_MAX_LEN]; char dev_mac[MAC_MAX_LEN]; char dev_sn[SN_MAX_LEN];
}dev_info_t;

如果是产品已经在市场上流通，这时候这么加的话，软件兼容性就不太好。因为假如你的手机APP版本与设备版本不匹配，原有的设备IP及设备MAC这两个设备信息可能都显示不出来，因为我们这么一改，破坏了原有的数据结构，而手机APP按照原来的数据来做解析的，会解析不过。

这时候可以这么来加：

#define MSG_ID_DEV_INFO   0x0001 #define MSG_ID_DEV_SN     0x0002 typedef struct _dev_info { char dev_ip[IP_MAX_LEN]; char dev_mac[MAC_MAX_LEN];
}dev_info_t; typedef struct _dev_sn { char dev_sn[SN_MAX_LEN];
}dev_sn_t;

这样，哪怕手机APP版本与设备版本没有对应上，原来的数据还是能正常显示的。当然，最好的情况当然是在开发阶段就合理地设计好。不然，像这种情况，只能牺牲一些程序可读性来换取程序兼容性了。这会让后面看代码的人觉得很奇怪，你这个sn不也是数据设备信息吗，怎么还单独给一个ID。后面接手这个代码的人可能就会把这一块代码给改了。

温馨提示：在没有完全弄懂维护项目的代码为什么这么实现的情况下，能正常在跑的程序还是别乱动得好，哪怕你觉得这是屎山代码。否则可能会出大问题。要么等到软件重构时再修改，要么就继续打补丁。

3、数据删除

如果是删除本模块内部自己使用的数据，你想怎么删就怎么删。

如果是删除与其它模块进行交互的数据，这就不能这么随意了。比如，请求、应答的方式。应答端给请求端返回的数据是不能随意删的，如果要删，一定要确保请求端已经没有请求数据的需求，并且已经去掉相关代码时，这时候应答端才去删数据，否则还是留着吧。

4、数据修改

其实数据定了，为了保证软件兼容性，应该是要禁止修改的。

如果一定要修改，可以先增加一条新数据，后面慢慢切为新数据、删除旧数据。

接口兼容性

正在使用的接口，应该尽量不要修改。如果要修改，一定不要影响之前的功能。

之前就有遇到类似的情况。举个例子：

typedef enum _sys_status
{
 SYS_STATUS_IDLE,
 SYS_STATUS_RUNNING,
 SYS_STATUS_STOP,
}sys_status_t; static sys_status_t g_sys_status; sys_status_t get_sys_status(void) { return g_sys_status;
}

这里的系统状态是要显示在手机APP上的，不同的状态显示不同的图标。后面要新增一个状态，结果数据提供者这么改：

typedef enum _sys_status
{
 SYS_STATUS_IDLE,
 SYS_STATUS_NEW_STATUS,
 SYS_STATUS_RUNNING,
 SYS_STATUS_STOP,
}sys_status_t; static sys_status_t g_sys_status; sys_status_t get_sys_status(void) { return g_sys_status;
}

接口提供者把新增的数据插入了中间，影响了枚举原有的顺序。结果手机APP上图标显示乱了。

影响到接口的修改，要保证原有的数据不受影响。

系统兼容性

在软件升级过程中，需要考虑软件所依赖的其他系统组件是否发生变化，以确保升级后软件能够正常运行，不会影响其他系统组件的正常运行。如果其他系统组件发生变化，则需要进行相关测试和文档更新，以确保整个系统能够正常运行。

另外随着项目的迭代，这一套代码有可能运行于不同的系统不同的芯片平台。

比如，我们嵌入式Linux项目，有些项目里会用到一些第三方库，这时候可能会编译成动态库的形式。要考虑升级的时候能不能升级动态库。如果不能，就得把依赖的库一起编译到可执行程序里。

另外，如果使用动态库，之后产品软硬件迭代换了一个芯片平台的话，我们就需要重新交叉编译一次所依赖的库。如果为了保证这一块的兼容性，也可以考虑把所依赖的库与用户代码一起编译。

当然，这个根据实际情况进行权衡取舍。如果依赖的库很多，一起编译到可执行程序里，导致可执行程序很大，到时候更新也不好更新。

功能兼容性

涉及到功能的添加的，尽量不要影响到之前已开发的功能。不然也会增加用户对产品的学习成本。比如某些指示灯在前一个版本的快闪、慢闪代表什么意思，这个在之后就尽量不要去修改了，不然用户又得重新理解。

性能兼容性

在软件升级过程中，需要考虑软件的性能是否发生变化，以确保升级后软件的性能仍然能够满足用户需求。如果软件的性能发生变化，则需要进行相关测试和优化，以确保软件能够正常运行，并且能够满足用户的性能需求。

比如，原来正常升级需要3分钟，某个版本之后升级变成了6分钟，升级效率变差了。

安全兼容性

在软件升级过程中，需要考虑软件的安全性是否得到加强，以确保升级后软件的安全性能够得到保障，不会出现新的安全风险。如果软件的安全性得到加强，则需要进行相关测试和文档更新，以确保软件能够正常运行，并且能够保障用户的安全。