硬件产品升级时的兼容性问题

越来越多的硬件产品，硬件构成不仅仅是集成在一块板子上，而是多块控制板协同工作。

此时，就会涉及到多块板之间的通信（有线/无线通信），就会涉及到到通信协议。很多时候，我们都会自定义一些协议。

我们之前在也分享一种常用的自定义协议格式：

分享一种灵活性很高的协议格式（附代码例子）

在多板系统中，会有以下这些应用场景：

每块板都有OTA升级的需求。

可能某块板是一块公共的板子，其它项目也会同时使用，这块公共板子软件需要同时兼容多个项目。

我们在软件迭代过程中，可能会涉及到板间交互的数据的升级，比如新增数据。

新增的某个数据属性上属于某个数据集合，比如与某个结构体是同类数据，理论上为了程序设计得更合理些，应该把这个数据加在已有的结构体里面。

但是，这可能会涉及到兼容性问题。

如果直接往结构体里新增数据，升级时，有些板子升级成功了，有些板子没升级成功。可能就会出现数据异常导致功能异常。

公共板升级新增协议之后，可能就不能完全兼容与其通信的板子。

比如，有一条数据叫做设备信息的数据需要在板间通信，设备信息里包含了：设备IP、设备Mac。

#defineMSG_ID_DEV_INFO0x0001

typedefstruct_dev_info
{
chardev_ip[IP_MAX_LEN];
chardev_mac[MAC_MAX_LEN];
}dev_info_t;

此时，有新需求需要再加一个设备的sn，这个数据我们应该如何加？

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

#defineMSG_ID_DEV_INFO0x0001

typedefstruct_dev_info
{
chardev_ip[IP_MAX_LEN];
chardev_mac[MAC_MAX_LEN];
chardev_sn[SN_MAX_LEN];
}dev_info_t;

如果是项目后期，或已经上市流通，则就需要考虑兼容性问题了。

针对这种兼容性问题，有如下解决方案：

方案一：新增的数据单独走一条数据协议

比如针对以上例子，可以这么来扩展：

#defineMSG_ID_DEV_INFO0x0001
#defineMSG_ID_DEV_SN0x0002

typedefstruct_dev_info
{
chardev_ip[IP_MAX_LEN];
chardev_mac[MAC_MAX_LEN];
}dev_info_t;

typedefstruct_dev_sn
{
chardev_sn[SN_MAX_LEN];
}dev_sn_t;

这种方案虽然能解决问题，但越到后面，程序会越来越乱，各种数据很散乱，很不好维护。

而且，一开始也不可能把所有数据都规划得很完美。有没有什么方法，可以比较合理地扩充数据，并且也能应对这种兼容性问题。

看一下方案二。

方案二：项目设计初期，引入一些数据序列化库。

比如protobuf。

Protocol Buffers，是Google公司开发的一种数据描述语言，类似于XML能够将结构化数据序列化，可用于数据存储、通信协议等方面。它不依赖于语言和平台并且可扩展性极强。

同XML相比，Protocol buffers在序列化结构化数据方面有许多优点：

消息格式升级和兼容性好

支持跨平台多语言

序列化反序列化速度很快

序列化后体积相比Json和XML很小，适合网络传输

相关文章：

Protobuf：一种更小、更快、更高效的协议

干货 | 项目乏力？nanopb助你一臂之力

干货 | protobuf-c之嵌入式平台使用

如何利用Google的protobuf，来实现自己的RPC框架

针对上面的例子，使用protobuf。

原来的数据：

syntax="proto2";

messagedev_info
{
requiredstringdev_ip=1;
requiredstringdev_mac=2;
}

新增数据dev_sn直接新增即可：

syntax="proto2";

messagedev_info
{
requiredstringdev_ip=1;
requiredstringdev_mac=2;
requiredstringdev_sn=3;
}

审核编辑：汤梓红