2111
大家好，我是杂烩君。
越来越多的硬件产品，硬件构成不仅仅是集成在一块板子上，而是多块控制板协同工作。
此时，就会涉及到多块板之间的通信（有线/无线通信），就会涉及到到通信协议。很多时候，我们都会自定义一些协议。
我们之前在也分享一种常用的自定义协议格式：分享一种灵活性很高的协议格式（附代码例子）
在多板系统中，会有以下这些应用场景：
我们在软件迭代过程中，可能会涉及到板间交互的数据的升级，比如新增数据。
新增的某个数据属性上属于某个数据集合，比如与某个结构体是同类数据，理论上为了程序设计得更合理些，应该把这个数据加在已有的结构体里面。
但是，这可能会涉及到兼容性问题。
如果直接往结构体里新增数据，升级时，有些板子升级成功了，有些板子没升级成功。可能就会出现数据异常导致功能异常。
公共板升级新增协议之后，可能就不能完全兼容与其通信的板子。
比如，有一条数据叫做设备信息的数据需要在板间通信，设备信息里包含了：设备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;
}
以上就是本次的分享，欢迎收藏、转发！
下载ECAD模型
