妙用結構體 簡化報文封裝和解析

佛門里有句話：諸法無自性，盡隨汝心轉。就是說，同樣一個東西，在不同的人眼中，呈現的是不同的印象。

比如，同樣是榴蓮，有人視為美味，直流口水，有人卻覺得聞起來臭穢，吃起來反胃，正所謂汝之蜜糖，彼之砒霜。

這一點倒是和“一千個讀者的眼中就有一千個哈姆雷特”有點異曲同工之妙。

同樣的東西，在不同使用者手中也能發揮不同的作用。比如倚天劍，張無忌拿它主持武林正義，護佑天下蒼生，滅絕師太卻拿它發泄更年期的怒火，切蘿卜似地大殺四方。

比如C語言中的結構體，有的人輕車熟路，信手拈來，經常孔乙己似地“你可知結構體和聯合體有幾種用法？”

有的人卻笨手笨腳，不得章法。

說他不會用結構體吧，他便漲紅了臉，額上的青筋條條綻出，爭辯道：“用得不好不能算不會用。。。不用。。。碼農的事，能說不會用嗎？”接著便是難懂的話，什么“不同的變量干嘛揉在一起”，什么“物以類聚人以群分”之類，引得眾人都哄笑起來，辦公室里充滿了快活的空氣。

灑家向來中規中矩，也沒研究過結構體到底有幾種用法，直到有一天，用它解決了工作中的一個大問題，才領會了它的妙用。

一

代碼交接也許是碼農最不愿意干的事情之一了，尤其是要接過一個要離職的“兄弟”的代碼的時候。

當其時也，真個是左右為難。

卡得嚴一點吧，害怕傷交情，人都要走了，好說好散，何必在這個時候讓人為難？放松一點吧，苦的是自己，人都要走了，一拍兩散，他甩下的鍋有那么容易刷完？

總之，一邊是交情，一邊是心情，左右都不是，為難了自己。該為他想吧，該為自己想吧，我已糾結地不可自拔。

當小韓離職、領導讓我交接他的代碼時，我陷入的便是這樣的困境。

小韓交接給我的是一個半成品的電動防夾車窗控制器，雖然一時半會我還看不大懂他的防夾算法，但是應用部分還是比較容易理解的。待我沉下心去一看，我很快被代碼中此起彼伏的位操作語句淹沒了。

代碼里到處涌現的這些位操作是干嘛的呢？原來，這個產品是個CAN節點，這些位操作是用來提取CAN報文里的某個“信號”，或者給CAN報文的某個“信號”賦值的。

這里面實際上牽扯到一個挺麻煩的事情，因為，傳統的CAN信號讀取和賦值方法以報文字節數組為操作對象，讀取某個CAN信號或者對某個CAN信號賦值時，確實需要對報文字節數組中的某個字節進行位操作。

但是，根據具體應用不同，一個CAN節點需要讀取和賦值的CAN信號可能多達數十個甚至上百個，這種位操作方式使得解析和賦值CAN信號的工作非常繁重，而且容易出錯。當CAN節點功能升級造成網絡矩陣表發生改變時，CAN信號解析和賦值操作也會隨CAN信號位置或長度的變化而變化，這時又會造成大量的修改操作。

也就是說，且不說小韓的半成品代碼里是不是埋了雷，就是以后要做一點修改時，也會很麻煩。

這可咋整？

二

進一步行文之前，還是有必要先給大家科普一下。

在CAN網路中，CAN報文是底層通信接收和發送的主體，每條CAN報文中的數據場為8個字節。在這八個字節里，有很多“信號”，這些信號一般是位形式，比如車窗命令可以用一個2位的信號表示-01上升10下降11停止。

這么說吧，從“通信”的角度，報文收發的操作對象是“字節形式”的報文數據，但是從“邏輯”的角度，應用的操作對象是“位形式”的CAN信號。

一邊是字節形式的報文數據，一邊是位形式的CAN信號，顯然需要通過一種手段把它們聯系起來。

位操作當然是手段之一。

就像小韓在代碼里寫的那樣，先把CAN報文寄存器里的字節形式的數據賦值給具體報文中的某個字節，比如：

WDW_CMD_REQ[0]=(unsigned char)(CANmsgReceiveNow[1]>>8);

再用位操作提取該報文該字節里面的信號，比如：

Lf_cmd=WDW_CMD_REQ[0]&0x03;

在寫代碼和讀代碼時，位操作畢竟比不得直接的加、減、邏輯、賦值操作那樣容易理解，但是，程序員的心一般都比較大，應該不怕自己人讀時頭大。

而且，就算如前文所說，信號在字節中的位置發生了變化，無非是多費點腦汁，重寫一下這個位操作語句就行了。

總之，位操作是麻煩了點，但是好像也不是多大的硬傷。

好吧，如果你沒有覺得哪里有什么不對勁，請你思考一下這個問題：

每個報文對應八個字節，這八個字節里可能有二三十個信號，如果每個信號都定義一個變量，一條報文就差不多消耗三十來個字節的RAM，如果報文多了，會消耗多少RAM資源呢？要知道，在MCU里面，RAM可算是寸土寸金吶！

三

信號對應的RAM資源其實是可以省掉的！方法就是本文要說的聯合體和結構體。

聯合體可以節省RAM空間，這是C語言里的常識。可是，怎么把字節形式和位形式“聯合”為一體呢？

方法就是根據報文的信號矩陣設計信號組結構體。即根據網絡矩陣表給出的每個報文的所有CAN信號的名稱、起始位和長度信息，每個報文都設計一個由一組位信號組成的結構體。

這里首先要注意你所用處理器的大小端模式，看看是先定義第一個字節里的信號，還是先定義最后一個字節里的信號。然后根據信號的占位（第幾個字節的哪幾位），把它定義在相應的位置，如果在報文里有空位，比如說第二個字節的0-3位沒有定義，這時也要以占位符信號的形式把它定義出來。

然后為每個報文定義一個聯合體類型。聯合體有兩個成員變量，一個是數組變量，一個是上述信號組結構體變量。根據聯合體的定義，數組變量和信號組結構體變量的尺寸相同，存放于相同的地址空間（同一個RAM地址）里，無論誰發生了變化，另一方也會同步發生改變。

在這個聯合體中，數組變量是以單字節類型定義的數組，存儲字節形式的報文數據，它用于報文的收發，對應于底層通信。

信號組結構體變量是以上述信號組結構體類型定義的結構體，存儲信號組形式的報文數據，它用于信號的解析和封裝，對應于上層應用。

報文聯合體和信號組結構體內存空間示意圖

CAN節點接收報文并放入報文緩沖區后，進行報文解析時，首先根據報文ID，找出對應的報文，然后將報文緩沖區當前報文的數據寫入對應的報文聯合體變量的數組變量中，由于聯合體字節數組和聯合體信號組結構體位于相同的地址空間上，數組變量的內容更新直接更新了該聯合體變量中的信號組結構體變量的內容，當提取和解析CAN信號時，直接讀取該報文聯合體中的結構體中定義的信號即可。

當需要發送報文時，如果需要賦值信號，直接賦值該報文聯合體中的結構體中定義的信號，不需要進行位操作對報文數據進行封裝，然后將該報文聯合體中的字節數組填充到CAN控制器的發送寄存器中，啟動CAN控制器的發送就可以完成報文的發送。

這種實現方案是不是很酷？Super Cool！

四

這種對結構體和聯合體的妙用，只需要在定義結構體的時候膽大心細一些，便可以將CAN信號的解析及封裝畢其功于一役，之后的工作就像那橋邊姑娘，風華模樣，落落大方了。

如果是底層報文收發，你就對聯合體中的數組形式的字節變量進行操作，如果是應用層CAN信號的讀取和賦值，你就對聯合體中信號組結構體形式的位變量進行操作。

有了聯合體，報文里字節形式的數據變化后，位形式的信號量自動發生變化，直接拿來用即可。反之，在應用中對某個位形式的信號更新賦值了以后，報文里的字節數據自動發生變化，該發送時直接發送即可！

再也沒有惱人的位操作了，是不是非常地神清氣爽？

總之，假輿馬者，非利足也，而致千里；假舟楫者，非能水也，而絕江河。君子生非異也,善假于物也！

就在于這個善假于物也！