大家好，我是杂烩君。

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

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

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

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

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

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

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

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

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

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

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

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

#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;

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

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

方案一：新增的数据单独走一条数据协议
比如针对以上例子，可以这么来扩展：

#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;

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

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

看一下方案二。

方案二：项目设计初期，引入一些数据序列化库。
比如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;
}

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