Z-Stack 綁定中的原碼補碼反碼小插曲

話說博主這兩天使用CC2531執行綁定操作的時候，出現點小插曲。首先EndDevice在按鍵處理程序中，發送ZDP_MatchDescReq（）廣播匹配端點描述符請求，這個函數只對允許綁定的設備有效。

ZDP_MatchDescReq（）請求函數如下。

			dstAddr.addrMode = AddrBroadcast;
			dstAddr.addr.shortAddr = NWK_BROADCAST_SHORTADDR;
			ZDP_MatchDescReq( &dstAddr, NWK_BROADCAST_SHORTADDR,
							 WSN_PROFILE_ID,
							 /*WSN_MAX_IN_CLUSTERS, (cId_t *)WSN_ClusterList,*/
							 0,(cId_t *)NULL,
							 WSN_MAX_OUT_CLUSTERS, (cId_t *)WSN_ClusterList,
							 FALSE );

允許綁定的目的設備，ZDO層自動處理Match請求，無需手動處理，ZDO層會對Req請求進行響應。EndDevice如果註冊了ZDO層消息Match_Desc_rsp，那麼設備將會在SYS_EVENT_MSG事件中的ZDO_CB_MSG裏收到Match_Desc_rsp這個響應。註冊接收響應的消息方法如下：

			ZDO_RegisterForZDOMsg( WSN_TaskID, Match_Desc_rsp );

在ZDO_CB_MSG處理函數爲WSN_ProcessZDOMsgs( (zdoIncomingMsg_t *)MSGpkt );

該函數的參數zdoIncomingMsg_t 的數據結構如下：

typedef struct
{
  osal_event_hdr_t hdr;
  zAddrType_t      srcAddr;
  uint8            wasBroadcast;
  cId_t            clusterID;
  uint8            SecurityUse;
  uint8            TransSeq;
  uint8            asduLen;
  uint16           macDestAddr;
  uint8            *asdu;
} zdoIncomingMsg_t;

我們使用zdoIncomingMsg_t的clusterID來判斷消息類型。在這裏，我們調試的時候，發現接收到的ClusterID值爲-32762，而我們要接收的ClusterID爲Match_Desc_rsp。該值的定義在ZDOProfile.h

#define Match_Desc_rsp          (Match_Desc_req | ZDO_RESPONSE_BIT)

其中

#define Match_Desc_req          ((uint16)0x0006)

#define ZDO_RESPONSE_BIT        ((uint16)0x8000)

所以Match_Desc_rsp = 0x8006.

無符號的值爲32774，其二進制爲1000000000000110，

由於數字在計算機中是以補碼形式存在的，一個有符號的-32762與無符號的32764作比較，我們就得計算其補碼。補碼，原碼，反碼請看這篇文章，講的很詳細。

http://www.cnblogs.com/zhangziqiu/archive/2011/03/30/ComputerCode.html

我們計算無符號的值的反碼爲1111111111111001，由於是負數，所以補碼要在原碼的基礎上再加1.

得到補碼爲1111111111111010，計算其有符號的值就是-32762。

而調試時值正是以計算機的補碼爲基礎的。所以這兩者是相等的，也就是收到了該響應。