协议栈中绑定流程的一点认识

2011年4月27日

初学者关于协议栈中绑定流程的一点认识

本人刚接触zigbee不久，在学习中将不断记录每天的进步，期待大家的指导！！

在这里指出我还是参考了ZStack-CC2530-2.3.1-1.4.0\Projects\zstack\Samples\GenericApp例程

在协议栈中关于bind的服务主要有一下几类。
    End_Device_Bind_req       ((uint16)0x0020)
    Bind_req                            ((uint16)0x0021)
    Unbind_req                       ((uint16)0x0022)
     Bind_rsp                          (Bind_req | ZDO_RESPONSE_BIT)
    End_Device_Bind_rsp        (End_Device_Bind_req | ZDO_RESPONSE_BIT)
    Unbind_rsp                         (Unbind_req | ZDO_RESPONSE_BIT)
我借由GenericApp中 End_Device_Bind_req  服务请求来一步步说明bind蛋疼的传来传去的流程。
   假设一个bind节点1，它要发出End_Device_Bind_req请求。这个是在 GenericApp_HandleKeys发出的
  if ( keys & HAL_KEY_SW_2 )
    {
      HalLedSet ( HAL_LED_4, HAL_LED_MODE_OFF );

      // Initiate an End Device Bind Request for the mandatory endpoint
      dstAddr.addrMode = Addr16Bit;
      dstAddr.addr.shortAddr = 0x0000; // Coordinator
      ZDP_EndDeviceBindReq( &dstAddr, NLME_GetShortAddr(), 
                            GenericApp_epDesc.endPoint,
                            GENERICAPP_PROFID,
                            GENERICAPP_MAX_CLUSTERS, (cId_t *)GenericApp_ClusterList,
                            GENERICAPP_MAX_CLUSTERS, (cId_t *)GenericApp_ClusterList,
                            FALSE );
    }

在ZIGBEE SPECIFICATION有如下的描述
The End_Device_Bind_req is generated from a Local Device wishing to perform End Device Bind with a Remote Device. The                          End_Device_Bind_req is generated, typically based on some user action like a button press. The destination addressing on 
this command shall be unicast, and the destination address shall be that of the  ZigBee Coordinator.
就是说这个End_Device_Bind_req 请求是发给我们的 Coordinator，代码也是这样写的。
ZDP_EndDeviceBindReq具体内容我就不贴出来了，这个函数很简单就是发送一个End_Device_Bind_req格式帧给Coordinator，帧格式为
LocalCoordinator（本地nwk地址） + SrcExtAddr (本地ieee地址）+ ep（请求bind的endpoint） + ProfileID +  NumInClusters（簇的个数） + NumOutClusters（簇列表）

就这样这个End_Device_Bind_req请求到了Coordinator，接收部分我不想多说了，要说又是一大堆了。但要注意的是Coordinator的End_Device_Bind_req请求处理函数不是在CONST zdpMsgProcItem_t zdpMsgProcs[]数组，我们不能像Match_Desc_req那样轻松的借由AF_INCOMING_MSG_CMD进入 ZDP_IncomingData调用服务函数的。相比的要绕个弯子，我们先要注册一下。
void ZDApp_RegisterCBs( void )
{
#if defined ( ZDO_IEEEADDR_REQUEST ) || defined ( REFLECTOR )
  ZDO_RegisterForZDOMsg( ZDAppTaskID, IEEE_addr_rsp );
#endif
#if defined ( ZDO_NWKADDR_REQUEST ) || defined ( REFLECTOR )
  ZDO_RegisterForZDOMsg( ZDAppTaskID, NWK_addr_rsp );
#endif
#if ZG_BUILD_COORDINATOR_TYPE
  ZDO_RegisterForZDOMsg( ZDAppTaskID, Bind_rsp );
  ZDO_RegisterForZDOMsg( ZDAppTaskID, Unbind_rsp );
  ZDO_RegisterForZDOMsg( ZDAppTaskID, End_Device_Bind_req ); //注册了End_Device_Bind_req 服务
#endif
#if defined ( REFLECTOR )
  ZDO_RegisterForZDOMsg( ZDAppTaskID, Bind_req );
  ZDO_RegisterForZDOMsg( ZDAppTaskID, Unbind_req );
#endif
}
这个注册函数和之前帖子提到的
ZDO_RegisterForZDOMsg( GenericApp_TaskID, End_Device_Bind_rsp );
ZDO_RegisterForZDOMsg( GenericApp_TaskID, Match_Desc_rsp );
功能一样。
End_Device_Bind_req 服务调用分为2步，首先在ZDP_IncomingData中的ZDO_SendMsgCBs标记ZDO_CB_MSG然后通过osal调用ZDApp_ProcessMsgCBs真正的完成。
ZDApp_ProcessMsgCBs这个函数之后我们会多次打交道，我在这只贴相出于End_Device_Bind_req有关的部分
switch ( inMsg->clusterID )
  {.........
case End_Device_Bind_req:
      if (ZG_DEVICE_COORDINATOR_TYPE)
      {
        ZDEndDeviceBind_t bindReq;
        ZDO_ParseEndDeviceBindReq( inMsg, &bindReq );
        ZDO_MatchEndDeviceBind( &bindReq );

        // Freeing the cluster lists - if allocated.
        if ( bindReq.numInClusters )
          osal_mem_free( bindReq.inClusters );
        if ( bindReq.numOutClusters )
          osal_mem_free( bindReq.outClusters );
      }
      break;
强调只有COORDINATOR才能处理End_Device_Bind_req请求吧，与我们之前发送部分是吻合的。
还有个别的体会的可以与本人联系

posted @ 2011-04-27 22:07 雪帕 阅读(663) 评论(0)  编辑

【转自小峰博客】协调器的启动【自动模式】

首先请让我向大家介绍下强人小峰，看完他写的多篇博客感悟颇多哦！

可以看到调用了ZDO_StartDevice( (uint8)ZDO_Config_Node_Descriptor.LogicalType,                  devStartMode,DEFAULT_BEACON_ORDER, DEFAULT_SUPERFRAME_ORDER );
这里设备网络状态参数:
ZDO_Config_Node_Descriptor.LogicalType = NODETYPE_COORDINATOR
devStartMode = MODE_HARD
且协调器编译了ZDO_COORDINATOR
****************
void ZDO_StartDevice( byte logicalType, devStartModes_t startMode, byte beaconOrder, byte superframeOrder )
{
  ZStatus_t ret;

  ret = ZUnsupportedMode;

#if defined(ZDO_COORDINATOR) 
  if ( logicalType == NODETYPE_COORDINATOR )
  {
    if ( startMode == MODE_HARD )  //MODE_HARD 
    {
      devState = DEV_COORD_STARTING;  //Started as Zigbee Coordinator
      //建网
      ret = NLME_NetworkFormationRequest( zgConfigPANID, zgDefaultChannelList,
                                          zgDefaultStartingScanDuration, beaconOrder,
                                          superframeOrder, false );
    }
    else if ( startMode == MODE_RESUME )  //MODE_RESUME 
    {
      // Just start the coordinator
      devState = DEV_COORD_STARTING;
      ret = NLME_StartRouterRequest( beaconOrder, beaconOrder, false );
    }
    else  //错误，未知启动模式
    {
#if defined( LCD_SUPPORTED )
      //HalLcdWriteScreen( "StartDevice ERR", "MODE unknown" );
      ClearScreen();
      Print8(HAL_LCD_LINE_1,10,"StartDevice ERR",1);
      Print8(HAL_LCD_LINE_2,10,"MODE unknown",1);
#endif
    }
  }
#endif  // !ZDO_COORDINATOR

//#if !defined ( ZDO_COORDINATOR ) || defined( SOFT_START )
  
  if ( logicalType == NODETYPE_ROUTER || logicalType == NODETYPE_DEVICE )
  {
    if ( (startMode == MODE_JOIN) || (startMode == MODE_REJOIN) )
    {
      devState = DEV_NWK_DISC;  //Discovering PAN's to join

  #if defined( MANAGED_SCAN )
      ZDOManagedScan_Next();
      ret = NLME_NetworkDiscoveryRequest( managedScanChannelMask, BEACON_ORDER_15_MSEC );
  #else
      ret = NLME_NetworkDiscoveryRequest( zgDefaultChannelList, zgDefaultStartingScanDuration );
  #endif
    }
    else if ( startMode == MODE_RESUME )  //MODE_RESUME 恢复
    {
      if ( logicalType == NODETYPE_ROUTER )
      {
        ZMacScanCnf_t scanCnf;
        devState = DEV_NWK_ORPHAN;

        /* if router and nvram is available, fake successful orphan scan */
        scanCnf.hdr.Status = ZSUCCESS;
        scanCnf.ScanType = ZMAC_ORPHAN_SCAN;
        scanCnf.UnscannedChannels = 0;
        scanCnf.ResultListSize = 0;
        nwk_ScanJoiningOrphan(&scanCnf);

        ret = ZSuccess;
      }
      else
      {
        devState = DEV_NWK_ORPHAN; //孤儿
        ret = NLME_OrphanJoinRequest( zgDefaultChannelList,
                                      zgDefaultStartingScanDuration );
      }
    }
    else
    {
#if defined( LCD_SUPPORTED )
     // HalLcdWriteScreen( "StartDevice ERR", "MODE unknown" );
      Print8(HAL_LCD_LINE_1,10,"StartDevice ERR",1);
      Print8(HAL_LCD_LINE_2,10,"MODE unknown",1);
#endif
    }
  }
//#endif  //!ZDO COORDINATOR || SOFT_START

  if ( ret != ZSuccess )
    osal_start_timerEx(ZDAppTaskID, ZDO_NETWORK_INIT, NWK_RETRY_DELAY );
}
****************
通过参数可知协调器调用NLME_NetworkFormationRequest( zgConfigPANID, zgDefaultChannelList,
                                          zgDefaultStartingScanDuration, beaconOrder,
                                          superframeOrder, false )
进行网络的组建.
而对NLME_NetworkFormationRequest()的调用会产生一个回调函数ZDO_NetworkFormationConfirmCB()(见主要函数说明3),来看下：
****************
void ZDO_NetworkFormationConfirmCB( ZStatus_t Status )
{
#if defined(ZDO_COORDINATOR)
  nwkStatus = (byte)Status;

  if ( Status == ZSUCCESS )
  {
    // LED on shows Coordinator started
    HalLedSet ( HAL_LED_3, HAL_LED_MODE_ON );

    // LED off forgets HOLD_AUTO_START
    HalLedSet (HAL_LED_4, HAL_LED_MODE_OFF);

#if defined ( ZBIT )
    SIM_SetColor(0xd0ffd0);
#endif

    if ( devState == DEV_HOLD )
    {
      // Began with HOLD_AUTO_START
      devState = DEV_COORD_STARTING;
    }
  }
#if defined(BLINK_LEDS)
  else
    HalLedSet ( HAL_LED_3, HAL_LED_MODE_FLASH );  // Flash LED to show failure
#endif

  osal_set_event( ZDAppTaskID, ZDO_NETWORK_START );
#endif  //ZDO_COORDINATOR
}
****************
如果Status返回ZSUCCESS,建立网络成功,通过一些灯亮来来指示;不成功则通过闪烁灯来指示.最后触发任务ZDAppTaskID的ZDO_NETWORK_START事件,看下对ZDO_NETWORK_START的处理:
****************
#if defined (RTR_NWK)
  if ( events & ZDO_NETWORK_START )
  {
    ZDApp_NetworkStartEvt();

    // Return unprocessed events
    return (events ^ ZDO_NETWORK_START);
  }
****************
调用了ZDApp_NetworkStartEvt()
****************
void ZDApp_NetworkStartEvt( void )
{
  if ( nwkStatus == ZSuccess )//网络建立成功
  {
    // Successfully started a ZigBee network
    if ( devState == DEV_COORD_STARTING )
    {
      devState = DEV_ZB_COORD;
    }

    osal_pwrmgr_device( PWRMGR_ALWAYS_ON );
    osal_set_event( ZDAppTaskID, ZDO_STATE_CHANGE_EVT );
  }
  else //网络建立不成功,则增加能量阀值重新建网.
  {
    // Try again with a higher energy threshold !!
    if ( ( NLME_GetEnergyThreshold() + ENERGY_SCAN_INCREMENT ) < 0xff )
    {
      NLME_SetEnergyThreshold( (uint8)(NLME_GetEnergyThreshold() + ENERGY_SCAN_INCREMENT) );
      osal_set_event( ZDAppTaskID, ZDO_NETWORK_INIT ); //重新初始化建立网络
    }
    else
    {
      // Failed to start network. Enter a dormant state (until user intervenes)
      devState = DEV_INIT;
      osal_set_event( ZDAppTaskID, ZDO_STATE_CHANGE_EVT );
    }
  }
}
****************
如果协调器建立网络成功,则触发ZDAppTaskID的ZDO_STATE_CHANGE_EVT事件.看下对 ZDO_STATE_CHANGE_EVT的处理:
****************
  if ( events & ZDO_STATE_CHANGE_EVT )
  {
    ZDO_UpdateNwkStatus( devState );

    // Return unprocessed events
    return (events ^ ZDO_STATE_CHANGE_EVT);
  }
****************
调用了ZDO_UpdateNwkStatus( devState ),网络状态改变,这个函数会更新和发送信息通知每个注册登记过的应用终端.
****************
void ZDO_UpdateNwkStatus( devStates_t state )
{
  // Endpoint/Interface descriptor list.
  epList_t *epDesc = epList;
  byte bufLen = sizeof(osal_event_hdr_t);
  osal_event_hdr_t *msgPtr;

  ZDAppNwkAddr.addr.shortAddr = NLME_GetShortAddr();
  (void)NLME_GetExtAddr();  // Load the saveExtAddr pointer.

  while ( epDesc )
  {
    if ( epDesc->epDesc->endPoint != ZDO_EP )
    {
      msgPtr = (osal_event_hdr_t *)osal_msg_allocate( bufLen );
      if ( msgPtr )
      {
        msgPtr->event = ZDO_STATE_CHANGE; // Command ID
        msgPtr->status = (byte)state;

        osal_msg_send( *(epDesc->epDesc->task_id), (byte *)msgPtr ); //发往应用任务
      }
    }
    epDesc = epDesc->nextDesc;
  }
}
****************
对SampleApp的协调器来说，这里触发应用任务SampleApp_TaskID的ZDO_STATE_CHANGE事件,看下对ZDO_STATE_CHANGE的处理:
****************
        case ZDO_STATE_CHANGE:   
          SampleApp_NwkState = (devStates_t)(MSGpkt->hdr.status); //获取设备当前状态
          if ( (SampleApp_NwkState == DEV_ZB_COORD)
              || (SampleApp_NwkState == DEV_ROUTER)
              || (SampleApp_NwkState == DEV_END_DEVICE) )
          {
            // Start sending the periodic message in a regular interval.
            osal_start_timerEx( SampleApp_TaskID,
                              SAMPLEAPP_SEND_PERIODIC_MSG_EVT,
                              SAMPLEAPP_SEND_PERIODIC_MSG_TIMEOUT );
          }
          else
          {
            // Device is no longer in the network
          }
          break;
****************
可以看到当协调器建立网络成功,通过回调函数触发应用任务的ZDO_STATE_CHANGE事件,最终开启定时器发送周期信息.

3、
协调器(自启动模式)—以SampleApp的协调器为例,并假设初始化成功,网络建立成功.
程序大致流程:

main()->osal_init_system()->osalInitTasks()->ZDApp_Init()->ZDOInitDevice()->ZDApp_NetworkInit->触发ZDAppTaskID的ZDO_NETWORK_INIT->ZDO_StartDevice()->NLME_NetworkFormationRequest()->网络建立成功ZDO_NetworkFormationConfirmCB->触发ZDAppTaskID的ZDO_NETWORK_START->ZDApp_NetworkStartEvt()->触发ZDAppTaskID的ZDO_STATE_CHANGE_EVT->ZDO_UpdateNwkStatus()->触发SampleApp_TaskID的ZDO_STATE_CHANGE->开户周期信息发送的定时器.

4、注:
(1)自启动模式下SampleApp的终端和路由器总体流程基本一致.

(2)
以SampleApp为例,ZDO_StartDevice()函数的两个重要参数比较:
终端:
ZDO_Config_Node_Descriptor.LogicalType = NODETYPE_DEVICE
devStartMode = MODE_JOIN
路由器:
ZDO_Config_Node_Descriptor.LogicalType = NODETYPE_ROUTER
devStartMode = MODE_JOIN
协调器:
ZDO_Config_Node_Descriptor.LogicalType = NODETYPE_COORDINATOR
devStartMode = MODE_HARD

***************************************
***************************************

posted @ 2011-04-27 10:02 雪帕 阅读(889) 评论(0)  编辑

ZigBee学习之——ZStack API解读

申明：这是转载一位高手的博客哦！！

posted @ 2011-04-27 09:55 雪帕 阅读(1394) 评论(0)  编辑

zstack 第一个例子

看了好长一段时间的原理，终于手痒了，开动了第一个例子，感谢大家来敢看我的博客！！

1、        协议栈构架
首先打开程序代码，找到IAR工程 ，打开后可以看到TI ZStack的大体框架,如下图所示:

§ App：应用层目录，这也是用户创建各种不同工程的区域；
§ HAL：硬件层目录，包括着与硬件相关的配置及操作函数；
§ MAC：MAC层目录，包括着MAC层配置参数文件及MAC LIB库的函数接口文件；
§ MT：包括基于AF层的调试函数文件，主要包括串口等通信函数；§ NWK：网络层目录，包括着网络层配置参数文件及MAC LIB库的函数接口文件；
§ OSAL：系统目录，包括协议栈系统文档；
§ Profile：AF层目录，包括AF层处理函数文件；
§ Security：安全层目录，安全层处理函数，比如加密函数等;
§ Services：地址处理函数目录，包括着地址模式的定义及地址处理函数文档；Tools：工程配置目录，包括协议栈等配置文档；
§ ZDO ZDO ZDO ZDO：层目录，包括层处理函数文档；
§ ZMac：MAC层目录，包括MAC层参数配置及MAC层LIB库函数回调处理函数
§ ZMain：主函数目录，包括入口函数及硬件配置文件；
§ Output：输出文件目录，这是EW8051IDE自动生成的；

2、        程序的编译和下载
（1）        项目属性设置
选择菜单Project->Options、右击菜单options或者通过热键（ALT+F7）打开工程属性设置。

也可以鼠标右击workspace中的工程名，如下图：

打开属性设置后如图：

一般来说，如果是在TI的协议栈的进行修改，里面的设置就不用修改。如果要具体了解各参数，请参照IAR文档。
这里值得注意的是chipcon下的Download的标签，如果第一次用建议像如图那样选择，这样是将整个FALSH擦除后再Download，写完后最好用

软件来更改芯片的IEEE地址，否则可能带来你的程序无法运行。

具体见Zmain.c函数中的如下程序段：
led = HAL_LED_MODE_OFF;
  
  while ( HAL_KEY_SW_5 == HalKeyRead() )
  {
    MicroWait( 62500 );
    HalLedSet( HAL_LED_1, led^=HAL_LED_MODE_ON );  // Toggle the LED
    MicroWait( 62500 );
  }

  HalLedSet( HAL_LED_1, HAL_LED_MODE_OFF );

如果你使用的硬件平台没有对这个按键5进行设置，或者就没有这个按键5，这段将过不去，LED1灯将一直闪。
如果你的系统没有按键，建议将上面的语句注释掉。
（2）        编译与烧写
选择Project->Debug或者热键（Ctrl+D）给开发板上的Zigbee模块下载程序。
也可以直接点IAR的如下图标来编译和下载程序 ，最后一个是编译并下载；
同时也可以在workspace中的工程名上点击鼠标右键来选择编译。
下图显示为DEBUG时的选项：

在调试程序时，DEBUG还是非常有用的，它能告诉你程序运行到哪了，程序为什么没有出现你预期的结果等，因此，选择一个仿真器还是有用的，并且有些仿真器加上一个节点就可以充当packet sniffer工具，对空中的包能进行实时跟踪。下图是在宁波中科仿真器抓到的本例子的数据包，以后会对这些包结构做一定解析，如果也可以参考ZigBee协议栈文档，上面对这些包结构有详细的说明。

从图中的RSSI中可以看到节点的性能，负数越接近0表明节点性能越好，通信距离越长，并且协调器已经给一个终端节点分配了短地址0x796F（该地址可以通过计算得到，见IEEE 802.15.4文档）。
3、        实验程序简单分析
在本实验中用户涉及的程序主要有OSAL_SendTest.c，SendTest.c，SendTest.h。其他程序协议栈程序只做简单修改就行。比如我使用的是GAINST-CC2430需要修改一下串口函数等。因为硬件平台的差异性，大家可以根据实际进行修改。下面主要介绍上面提到的三个函数。
OSAL_SendTest.c函数是协议栈操作系统处理函数，这个函数实现对本实验中需要的任务的添加，具体函数如下：
osalTaskAdd( nwk_init, nwk_event_loop, OSAL_TASK_PRIORITY_MED );
osalTaskAdd( APS_Init, APS_event_loop, OSAL_TASK_PRIORITY_LOW );
osalTaskAdd( ZDApp_Init, ZDApp_event_loop, OSAL_TASK_PRIORITY_LOW );
osalTaskAdd( SendTest_Init, SendTest_ProcessEvent, OSAL_TASK_PRIORITY_LOW );

最后一条语句是添加本实验任务的。osalTaskAdd（）函数的参数请参照OSAL API_F8W-2003-0002_.PDF文档。
SendTest.c是本实验用户程序的具体实现。下面来分析一下该程序。
首先，本程序不考虑协议栈绑定等相关内容，在程序中屏蔽了绑定，实验数据只是从终端节点传送到协调器节点，对于ZIGBEE网络协调器节点的短地址始终为0x0000，因此在用发送函数时，目的地址写上0x0000就能传到协调器。
其次，两个设备的 endPoint要保持一致，否则将不能通信。在程序中将SendTest_DstAddr.endPoint = SendTest_ENDPOINT;（SendTest_ENDPOINT=10）。
程序实现结果是：协调器的串口上输出如图内容：

注意，要使用该串口助手才能显示中文，其他的串口可能不支持。
只有在终端节点加入网络后才能发送数据给协调器，一旦网络中断数据就不再发，这个机制是通过判断网络状态来实现的，代码如下：
if ( (SendTest_NwkState == DEV_END_DEVICE) ) //只在设备为终端节点时，才发送数据
          {
            // Start sending "the" message in a regular interval.
            osal_start_timer( SendTest_SEND_MSG_EVT,
                              SendTest_SEND_MSG_TIMEOUT );
          }
上面语句中SendTest_SEND_MSG_EVT是一个事件，只在定时器时间到才触发该事件，在程序中设置
#define SendTest_SEND_MSG_TIMEOUT   1000
也就是在网络建成后每一秒向协调器发送数据。
对于操作系统的介绍请参考文档，以后我也会就这个做些介绍。
SendTest_ProcessEvent函数为操作系统的一任务（上面已经介绍了怎么加入任务），总是被周期性轮询。当检测到一个event就执行相关程序。
在一个任务中有16个事件，用16位来表示，每一位代表一个事件，其中0x8000为系统事件SYS_EVENT_MSG，任务还和task_id有关。
MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( SendTest_TaskID );
程序段是将收到的消息存放到MSGpkt指定的区域中。
while ( MSGpkt )//消息不为空
{ switch ( MSGpkt->hdr.event )
      {

        case KEY_CHANGE://按键状态改（本实验不涉及）
          SendTest_HandleKeys( ((keyChange_t *)MSGpkt)->state, ((keyChange_t *)MSGpkt)->keys );
          break;

        case AF_DATA_CONFIRM_CMD://AF层数据发送完成后确认报告
          // This message is received as a confirmation of a data packet sent.
          // The status is of ZStatus_t type [defined in ZComDef.h]
          // The message fields are defined in AF.h
          afDataConfirm = (afDataConfirm_t *)MSGpkt;
          sentEP = afDataConfirm->endpoint;
          sentStatus = afDataConfirm->hdr.status;
          sentTransID = afDataConfirm->transID;
          (void)sentEP;
          (void)sentTransID;
          HAL_TOGGLE_LED1();//加入LED1来指示数据发送出
          // Action taken when confirmation is received.
          if ( sentStatus != ZSuccess )
          {
            // The data wasn't delivered -- Do something
          }
          break;

        case AF_INCOMING_MSG_CMD://新的报文来
          HAL_TOGGLE_LED1();//加入LED1来指示新报文来
          SendTest_MessageMSGCB( MSGpkt );//新报文回调函数
          break;

        case ZDO_NEW_DSTADDR://ZDO终端地址改变，这个是在加入绑定后引起的，本实验不涉及
          ZDO_NewDstAddr = (ZDO_NewDstAddr_t *)MSGpkt;

          dstEP = ZDO_NewDstAddr->dstAddrDstEP;
          dstAddr = &ZDO_NewDstAddr->dstAddr;
          SendTest_DstAddr.addrMode = (afAddrMode_t)dstAddr->addrMode;
          SendTest_DstAddr.endPoint = dstEP;

          SendTest_DstAddr.addr.shortAddr = dstAddr->addr.shortAddr;
          break;

        case ZDO_STATE_CHANGE://网络状态改变，在这里启动第一次数据传输
          SendTest_NwkState = (devStates_t)(MSGpkt->hdr.status);
          if ( (SendTest_NwkState == DEV_END_DEVICE) ) //只在设备为终端节点时，才发送数据
          {
            // Start sending "the" message in a regular interval.
            osal_start_timer( SendTest_SEND_MSG_EVT,
                              SendTest_SEND_MSG_TIMEOUT );
          }//这个在上面已经有介绍
          break;

        default:
          break;
      }

      // Release the memory
      osal_msg_deallocate( (uint8 *)MSGpkt );

      // Next
      MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( SendTest_TaskID );
}


if ( events & SendTest_SEND_MSG_EVT )//如果事件为消息传送事件
  {
    // Send "the" message
    SendTest_SendTheMessage();//调用消息发送函数

    // Setup to send message again
    if ( (SendTest_NwkState == DEV_END_DEVICE) )//解释同前
    osal_start_timer( SendTest_SEND_MSG_EVT,
                      SendTest_SEND_MSG_TIMEOUT );

    // return unprocessed events
    return (events ^ SendTest_SEND_MSG_EVT);
  }
消息回调函数实现：
void SendTest_MessageMSGCB( afIncomingMSGPacket_t *pkt )
{
  switch ( pkt->clusterId )
  {
    case SendTest_CLUSTERID:
      // "the" message
#if defined( LCD_SUPPORTED )
      HalLcdWriteScreen( (char*)pkt->cmd.Data, "rcvd" );
#elif defined( WIN32 )
      WPRINTSTR( pkt->cmd.Data );
#endif
      HalUARTWrite( HAL_UART_PORT_1,(pkt->cmd).Data, (pkt->cmd).DataLength);//将接收到的数打印到串口上
      break;
  }
}
对于串口的初始化在SendTest_Init函数中，上面的红色显示函数就是将收到的数据信息打印在串口终端上。
下面介绍一下，发送函数AF_DataRequest
该函数用于发送数据
函数声明：
afStatus_t AF_DataRequest( afAddrType_t *dstAddr, endPointDesc_t *srcEP,
uint16 cID, uint16 len, uint8 *buf, uint8 *transID,
uint8 options, uint8 radius );
具体参数：
dstAddr：目的地址指针，其中的地址模式是：afAddrNotPresent（用于绑定）、afAddrGroup（传送到一组目的节点）afAddrBroadcast（广播发送）、afAddr16Bit（直接发送），在本实验中afAddr16Bit地址模式，在SendTest_Init初始化中将SendTest_DstAddr.addrMode 设置为(afAddrMode_t)Addr16Bit;
srcEP：发送的endpoint的Endpoint描述的指针
cID：Cluster ID，实验中使用SendTest_CLUSTERID
len：发送数据包长度，该长度不包括ZIGBEE包中的帧头和帧尾，只是用户数据的长度
buf：用户发送数据区指针
transID：传输序号指针，该序号将随发送的次数增加而增加
options：具体参数参照下表：

Radius：最大跳数，协议栈默认值为10，可以根据实际情况修改，见nwk.h文件中
// the default network radius set twice the value of <nwkMaxDepth>
#define DEF_NWK_RADIUS 10

终于写完了，呵呵呵有点辛苦但是有收获哦

posted @ 2011-04-27 09:48 雪帕 阅读(3250) 评论(0)  编辑

TI CC2480 -- Z-Accel介绍

 

 

 

posted @ 2011-04-27 09:32 雪帕 阅读(295) 评论(0)  编辑

【转自小峰博客】zigbee串口透明传输

 

这是本人看到的转载！！！

posted @ 2011-04-27 09:21 雪帕 阅读(1081) 评论(0)  编辑

Zigbee2006, 2007, pro各个版本的区别

Zigbee2006, 2007, pro各个版本的区别

 

　　ZigBee是ZigBee联盟建立的技术标准，它是一种工作在900MHZ和2.4GHZ频段的新兴无线网络技术，具有中等通讯距离（10米到数百米），比较灵活经济的通讯速率（40Kbps到250Kbps），并且有星状，网状（MESH），树状等多种网络拓扑，低的功耗等特点，所以在当今无线通讯技术和无线网络技术领域中占有比较重要的地位。
 
　　第一个ZigBee协议栈规范于2004年12月正式生效，称为ZigBee 1.0或ZigBee 2004。
 
　　第二个ZigBee协议栈规范于2006年12月发布，称为ZigBee 2006规范，主要是用“群组库（cluster library）”替换了ZigBee 2004中的MSG/KVP结构。最为重要的新的ZigBee 2006协议栈将不兼容原来的ZigBee 2004技术规范，对于已经投入ZigBee 2004的厂商而言，这是一个大悲剧。例如Jennic公司将ZigBee2004协议栈固化在ROM中（JN5121/JN5139）。将无法和ZigBee 2006以后的协议栈兼容。ZigBee 2006协议栈，将是ZigBee兼容的一个战略分水岭，从这里开始，ZigBee将实现完全向后兼容性。
 
　　2007年10月发布了ZigBee 2007规范，ZigBee 2007规范定于了两套高级的功能指令集（feature set）：分别是ZigBee功能命令集和ZigBee Pro功能命令集。（ZigBee 2004和2006都不兼容这两套新的命令集）。ZigBee 2007包含两个协议栈模板（profile）,一个是ZigBee协议栈模板(Stack Profile 1)，它是2006年发布的，目标是消费电子产品和灯光商业应用环境，设计简单，使用在少于300个节点的网络中。另一个是ZigBee Pro协议栈模板 (Stack Profile 2)，它是在2007年发布，目标是商业和工业环境，支持大型网络，1000个以上网络节点，相应更好的安全性。ZigBee Pro提供了更多的特性，比如：多播、多对一路由和SKKE（Symmetric-key key establishment）高安全，但ZigBee（协议栈模板1）在内存和flash中提供了一个比较小的区域。两者都提供了全网状网络与所有的ZigBee应用模板工作。
 
　　ZigBee 2007 是向后完全兼容ZigBee 2006设备。ZigBee 2007设备可以加入一个ZigBee 2006网络，并能再ZigBee 2006网络中运行，反之亦然。
由于路由选择不同，ZigBee Pro设备必须变成非路由ZigBee End-Devices（ZEDs）设备才可加入ZigBee 2006或ZigBee 2007网络。同样ZigBee 2006或ZigBee 2007设备必须变成ZEDs才可加入ZigBee Pro网络。在这些设备上的应用程序工作是相同的，它们不管在这些设备上的协议栈模板。
下面的图表从高层次进行比较，列出2004、2006及2007/PRO ZigBee规范之间的异同。
 

比较图：

 

		2004	2006	2007	PRO
Interference avoidance 避免干扰	Support for ongoing interference detection under operational conditions and wholesale adoption of a new operating RF channel and/or Network ID. 在可操作条件下一个新的RF信道或/和网络ID被大量采用时，支持持续干扰检测。			√	√
Automated/distributed address management 自动/分配地址管理	Device addresses automatically assigned using a hierarchical, distributed scheme. 使用分层、分布式的方案自动分配设备地址。	√	√	√
Device addresses automatically assigned using a stochastic scheme.使用随机方案自动为设备分配地址。				√
Group addressing 组寻址	Devices can be assigned to groups, and whole groups can be addressed with a single frame; thereby reducing network traffic for packets destined for groups.将设备分配到组，组中的各设备可以接收同一个帧，这样送往组的数据包减少，从而减少了网络流量。		√	√	√
Centralized data collection 集中式数据收集	Many-to-one routing allows the whole network to discover the aggregator in one pass.多对一路由允许整个网络在一个通道上发现汇集器。				√
Source routing allows the aggregator to respond to all senders in an economical manner. 源路由允许汇集器以一种经济的方式对所有发件人回应。				√
Security 安全	Trust Center can run on any device in the network.信托中心可以在网络中的任何设备上运行。				√
"High Security" mode available, which is selectable by Trust Center policy, and requires Application Layer Link keys; peer-entity authentication; and peer-to-peer key establishment using Master Keys.可用“高安全”模式，它是信托中心可选择的策略，并且需要应用层链接键；身份验证对等实体；使用主键建立端到端的键。				√
Network scalability网络的可扩展性	Network scales up to the limits of the addressing algorithm. Typically, networks with tens to hundreds of devices are supported.网络的规模受寻址算法的限制。通常，网络支持几十甚至几百个设备。	√	√	√
An addressing algorithm that relaxes the limits on network size. Networks with hundreds to thousands of devices are supported. 放松网络规模限制的寻址算法，可支持成百成千的设备。				√
Message size 消息尺寸	< 100 bytes. Exact size depends on services employed, such as security.小于100B。确切的大小取决于服务，比如安全的服务。	√	√
Large messages, up to the buffer capacity of the sending and receiving devices, are supported using Fragmentation and Reassembly.应用分割和重组可支持大量消息（大到发送设备和接收设备的缓冲区容量）的收发。			√	√
Standardized commissioning 标准化调试	Standardized startup procedure and attributes support the use of commissioning tools in a multi-vendor environment.标准化的启动过程和属性支持调试工具在多厂商环境中的使用。		√	√	√
Robust mesh networking 健壮的mesh网络	Every device keeps track of its "neighborhood"; thereby further improving reliability and robustness. 每个设备保持跟踪它的邻居，从而进一步提高了可靠性和健壮性。				√
Cluster Library support 簇库的支持	The ZigBee Cluster Library, as an adjunct to the stack, standardizes application behavior across profiles and provides an invaluable resource for profile developers. 作为附属物加到堆栈中的 ZigBee簇库，通过profile标准化应用程序行为，并为profile开发人员提供一个无价的资源。		√	√	√

各ZigBee版本功能比较

版本	ZigBee04	ZigBee06	ZigBee07
指令集	无	无	ZigBee	ZigBee PRO
无线射频标准	802.15.4	802.15.4	802.15.4	802.15.4
地址分配		CSKIP	CSKIP	随机
拓扑	星状	树状、网状	树状、网状	网状
大网络	不支持	不支持	不支持	支持
自动跳频	是，3个信道	否	否	是
PAN ID冲突解决	支持	否	可选	支持
数据分割	支持	否	可选	可选
多对一路由	否	否	否	支持
高安全	支持	支持，1密钥	支持，1密钥	支持，多密钥
应用领域	消费电子(少量节点)	住宅(300个节点以下)	住宅(300个节点以下)	商业(1000个节点以上)

ZigBee2007两功能指令集比较

指令集	ZigBee2007
ZigBee	ZigBee PRO
地址分配	树状	随机
拓扑	树状、网状	网状
路由算法改进	无(同ZigBee06)	多对一，一对多，源路由等
非对称链路处理	否	支持
自动跳频	可选	支持
PAN ID冲突解决	否	支持
安全	住宅级别	标准
应用层安全	可选	可选
高安全模式	否	可选
调试指令集	支持	支持
安全调试	否	支持
多集团广播	支持	支持
分割传输	否	支持

　　ZigBee Pro在应用层功能部分，新增分割传输(Fragmented Transmission)功能，就是当超过有效载荷资料(Payload)长度的限制时，可以使用分割组装(Fragment & Assemble)的功能传送长度较长的数据。这里的分割处理方式类似传输控制协议(TCP)的分割方式，先设定区块(Block)数，接着系统便会按照的Blocks数分段传送封包，直到完整的封包送完为止。

posted @ 2011-04-27 09:17 雪帕 阅读(917) 评论(0)  编辑

ZStack-CC2530-2.3.0-1.4.0按键处理

今天看了ZStack-CC2530-2.3.0-1.4.0按键处理这部分，参考的是小峰的日志，讲的非常详细，地址如下：
    http://wjf88223.blog.163.com/blog/static/35168001201041294613991/
     我从中把查询法和中断发的大概流程截取了下，看起来没那么复杂， 没我的什么见解哦。
1,查询法函数调用流程如下:        
      HalKeyConfig()配置一定时器为轮询按键作准备——>时间一到触发系统任务事件调用Hal_ProcessEvent()—— >调用HalKeyPoll()得到按键值——>调用OnBoard_KeyCallback()进一步处理——调用OnBoard_SendKeys()构造消息包，准备触发应用按键事件【注意这个应用之前必须通过RegisterForKeys()注册接收按键事件的任务ID】——>调用osal_msg_send()向系统发送消息——>调用osal_set_event()设置事件发生标志——>调用SampleApp_ProcessEvent()处理事件——>最终调用SampleApp_HandleKeys()处理具体按键事件
2,中断法函数调用流程如下:        
     HalKeyConfig()进行按键中断配置——>按键引起中断进入中断函数HAL_ISR_FUNCTION()(该函数在hal_key.c中)——>调用halProcessKeyInterrupt()对按键中断进行下一步处理：清除中断标志，启动一定时器——>时间一到触发系统任务事件调用Hal_ProcessEvent()——> 调用HalKeyPoll()得到按键值——>调用OnBoard_KeyCallback()进一步处理——>调用OnBoard_SendKeys()构造消息包，准备触发应用按键事件【注意这个应用之前必须通过RegisterForKeys()注册接收按键事件的任务ID】——>调用osal_msg_send()向系统发送消息——>调用osal_set_event()设置事件发生标志——>调用SampleApp_ProcessEvent()处理事件——>最终调用SampleApp_HandleKeys()处理具体按键事件
3,两种方法相似之处: 
    都是经过了两次触发系统事件（第一次通过osal_start_timerEx()启动一个软定时器触发，第二次通过osal_msg_send()发送系统消息触发），分别调用相应任务事件处理函数，第一次是HAL层的Hal_ProcessEvent()来查询按键得到键值，一系列处理，第二次是APP层的SampleApp_ProcessEvent()把传送过来的按键事件进行最终处理
        osal_start_timerEx()------触发------> Hal_ProcessEvent()
        osal_msg_send()--------触发--------->SampleApp_ProcessEvent()
4,两种方法不同之处:    
    从上面对按键查询法和中断法的总结，可以看到中断法就比查询法大致多出两步：进入中断函数HAL_ISR_FUNCTION()与调用调用halProcessKeyInterrupt()，后面都是开始开启一软定时器触发相同事件HAL_KEY_EVENT，然后……………………。
5,自己添加应用:
   如果硬件配置按协议栈默认来配置，那基本只要完成这两件事情：(1)、在自己的应用中注册按键：RegisterForKeys(MyAPP_TaskID),这样用户应用就得接收到所有按键事件(2)、在自己的应用任务事件处理函数中配置具体处理函数：比如SampleApp中按SW1,发送闪烁信息给组1，按SW2,进/退组1.（该操作是在SampleApp_HandleKeys()函数中）