硬件產品升級時的兼容性問題

越來越多的硬件產品，硬件構成不僅僅是集成在一塊板子上，而是多塊控制板協同工作。

此時，就會涉及到多塊板之間的通信（有線/無線通信），就會涉及到到通信協議。很多時候，我們都會自定義一些協議。

我們之前在也分享一種常用的自定義協議格式：

分享一種靈活性很高的協議格式（附代碼例子）

在多板系統(tǒng)中，會有以下這些應用場景：

每塊板都有OTA升級的需求。

可能某塊板是一塊公共的板子，其它項目也會同時使用，這塊公共板子軟件需要同時兼容多個項目。

我們在軟件迭代過程中，可能會涉及到板間交互的數據的升級，比如新增數據。

新增的某個數據屬性上屬于某個數據集合，比如與某個結構體是同類數據，理論上為了程序設計得更合理些，應該把這個數據加在已有的結構體里面。

但是，這可能會涉及到兼容性問題。

如果直接往結構體里新增數據，升級時，有些板子升級成功了，有些板子沒升級成功。可能就會出現數據異常導致功能異常。

公共板升級新增協議之后，可能就不能完全兼容與其通信的板子。

比如，有一條數據叫做設備信息的數據需要在板間通信，設備信息里包含了：設備IP、設備Mac。

#defineMSG_ID_DEV_INFO0x0001

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

此時，有新需求需要再加一個設備的sn，這個數據我們應該如何加？

如果是項目前中期，這時候還是在開發(fā)階段，我們可以隨意修改。因為設備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;

這種方案雖然能解決問題，但越到后面，程序會越來越亂，各種數據很散亂，很不好維護。

而且，一開始也不可能把所有數據都規(guī)劃得很完美。有沒有什么方法，可以比較合理地擴充數據，并且也能應對這種兼容性問題。

看一下方案二。

方案二：項目設計初期，引入一些數據序列化庫。

比如protobuf。

Protocol Buffers，是Google公司開發(fā)的一種數據描述語言，類似于XML能夠將結構化數據序列化，可用于數據存儲、通信協議等方面。它不依賴于語言和平臺并且可擴展性極強。

同XML相比，Protocol buffers在序列化結構化數據方面有許多優(yōu)點：

消息格式升級和兼容性好

支持跨平臺多語言

序列化反序列化速度很快

序列化后體積相比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;
}

審核編輯：湯梓紅