大家好，我是杂烩君。

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

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

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

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

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

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

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

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

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

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

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

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

#define MSG_ID_DEV_INFO 0x0001typedef 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 0x0001typedef struct _dev_info{ char dev_ip[IP_MAX_LEN]; char dev_mac[MAC_MAX_LEN]; char dev_sn[SN_MAX_LEN];}dev_info_t;

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

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

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

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

#define MSG_ID_DEV_INFO 0x0001#define MSG_ID_DEV_SN 0x0002typedef 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;

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

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

看一下方案二。

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

比如protobuf。

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

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

消息格式升级和兼容性好支持跨平台多语言序列化反序列化速度很快序列化后体积相比Json和XML很小，适合网络传输

相关文章：

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

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

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

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

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

原来的数据：

syntax = "proto2"; message dev_info{ required string dev_ip = 1; required string dev_mac = 2;}

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

syntax = "proto2"; message dev_info{ required string dev_ip = 1; required string dev_mac = 2; required string dev_sn = 3;}

以上就是本次的分享，欢迎收藏、转发！

如果文章对你有帮助，麻烦帮忙点赞、收藏、转发，谢谢！

私信回复【嵌入式书籍】，可获取博主精心整理的嵌入式电子书一份