【DWM1000】 code 解密8一 TAG接收blink response 信号

         在分析这个部分前，目前我看到DWM1000 的资料，data可以分为blink和一般无线数据，后面有内容我们再扩充， 上面我们已经看到接收到blink触发的事件为

case SIG_RX_BLINK :

一般数据包应该触发的的是

case DWT_SIG_RX_OKAY :

表示接收到一个无线无线数据包，具体怎么解析这个数据包我们一点点分析。

好了，看TAG收到ANCHOR的blink response，这个数据包为一般数据包，具体数据内容我们前面简单列出来了，这里从TAG接收的角度一点点在分析。

 

好了，还是上代码

event_data_t* dw_event = instance_getevent(15); //get and clear this event uint8  srcAddr[8] = {0,0,0,0,0,0,0,0}; int fcode = 0; int fn_code = 0; uint8 *messageData;   inst->stoptimer = 0; //clear the flag, as we have received a message

首先是获取事件getevent，这个应该是获取到接收数据成功的事件。后面紧随其后是一下变量的生命。后面看用到这些变量再看。

switch(dw_event->msgu.frame[1])

这个msgu.frame[1] 是啥内容，我们需要回到ANCHOR发送端看了

#if (USING_64BIT_ADDR == 1)                                      inst->rng_initmsg.frameCtrl[1] = 0xCC;                                      inst->psduLength += FRAME_CRTL_AND_ADDRESS_L + FRAME_CRC; #else

我们接着摘录具体的代码

case 0xCC: // memcpy(&srcAddr[0], &(dw_event->msgu.rxmsg_ll.sourceAddr[0]), ADDR_BYTE_SIZE_L); fn_code = dw_event->msgu.rxmsg_ll.messageData[FCODE]; messageData = &dw_event->msgu.rxmsg_ll.messageData[0];

这个决定了我们从不同地方去srcAddr以及fn_code 和messageData。 后面用到这几个变量再看具体是什么内容

if(inst->mode == ANCHOR)       { ……       }       else // LISTENER or TAG      {                             fcode = fn_code;      }

接着后面看

switch(fcode)     {            case RTLS_DEMO_MSG_RNG_INIT:           {

 

原来fcode是这些家伙，我们再看看ANCHOR发送的时候fcode是什么吧

inst->rng_initmsg.messageData[FCODE] = RTLS_DEMO_MSG_RNG_INIT;

正好是第一个case，直接在拉代码看看做了什么，没看代码前，我们根据发送时的数据(短地址以及两个delay)可以大概猜出来，TAG应该是保持这些数据，因为ANCHOR那边还在等着，所以应该还会发一个数据给ANCHOR。

 

好，上代码

先修改了两个非常重要的变量，我们记一下，等一会还会用到

inst->testAppState = TA_TXE_WAIT; inst->nextState = TA_TXPOLL_WAIT_SEND ; // send next poll

 

后面就是从数据包提取短地址和两个delay

inst->tagShortAdd = messageData[RNG_INIT_TAG_SHORT_ADDR_LO]                                                        + (messageData[RNG_INIT_TAG_SHORT_ADDR_HI] << 8) ; // Get response delays from message and update internal timings accordingly resp_dly[RESP_DLY_ANC] =  messageData[RNG_INIT_ANC_RESP_DLY_LO] + (messageData[RNG_INIT_ANC_RESP_DLY_HI] << 8); resp_dly[RESP_DLY_TAG] =  messageData[RNG_INIT_TAG_RESP_DLY_LO] + (messageData[RNG_INIT_TAG_RESP_DLY_HI] << 8);

 

其中短地址被保存到结构体instance中，而两个delay目前只保存到临时变量里。

后面两个delay在代码中进行了转换，最终计算出了两个delay保存到instance中了

// Update delay between poll transmission and response reception. inst->txToRxDelayTag_sy // Update delay between poll transmission and final transmission. inst->finalReplyDelay inst->finalReplyDelay_ms

 

后面的inst->sleep_en = 0; 我们姑且认为是吧。 接着分析后面的代码

#if (USING_64BIT_ADDR == 1) memcpy(&inst->msg.destAddr[0], &srcAddr[0], ADDR_BYTE_SIZE_L); //set the anchor address for the reply (set destination address) #else

看代码，用的是64bit 地址，前面分析srcAddr其实是源地址

memcpy(&srcAddr[0], &(dw_event->msgu.rxmsg_ll.sourceAddr[0]), ADDR_BYTE_SIZE_L);

也就是ANCHOR的地址，我们可以看到执行

memcpy(&inst->msg.destAddr[0], &srcAddr[0], ADDR_BYTE_SIZE_L);

也就是destAddr[0]里面存放的ANCHOR的地址

接着看后面依然有个地址复制，我们先记录先来看看是否有用。

memcpy(&inst->relpyAddress[0], &srcAddr[0], ADDR_BYTE_SIZE_L);  //remember who to send the reply to (set destination address)

后面的代码就是几个变量的赋值了

inst->mode = TAG ; inst->instToSleep = 0; inst->instancetimer_saved = inst->instancetimer = portGetTickCount(); //set timer base

 

然后退出testapprun_s，来回分析ANCHOR 和TAG已经忘记done的状态了，我们暂且认为不需要定时器，所以回很快再次进去testapprun_s。首先列一下重要变量

inst->testAppState = TA_TXE_WAIT; inst->nextState = TA_TXPOLL_WAIT_SEND ; // send next poll inst->mode = TAG ;

然后在testapprun_s找案发现场

case TA_TXE_WAIT : //either go to sleep or proceed to TX a message        //if we are scheduled to go to sleep before next sending then sleep first.        if(((inst->nextState == TA_TXPOLL_WAIT_SEND)          || (inst->nextState == TA_TXBLINK_WAIT_SEND))          && (inst->instToSleep)  //go to sleep before sending the next poll                     )          {

根据绿色标出的地方，可以看出，满足if判断

//the app should put chip into low power state and wake up in tagSleepTime_ms time... //the app could go to *_IDLE state and wait for uP to wake it up... inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT_TO;  //don't sleep here but kick off the TagTimeoutTimer (instancetimer) inst->testAppState = TA_SLEEP_DONE;    if(inst->mode == TAG_TDOA) //once we start ranging we want to display the new range          {                             ……不满足条件          }   #if (DEEP_SLEEP == 1) 宏定义确实为1      if (inst->sleep_en) 上面我们假定这个参数为0       {              ……不满足条件        } #endif                    //DW1000 gone to sleep - report the received range                    if(inst->tof > 0) //if ToF == 0 - then no new range to report                    {                     ……                    }

后面的tof我们之前也没有遇到过，假定为0，也不满足。绕了一圈，发现其实这次进入到testapprun_s只设置两个两个重要变量

inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT_TO; inst->testAppState = TA_SLEEP_DONE;

根据之前分析，由于是INST_DONE_WAIT_FOR_NEXT_EVENT_TO，在instance_run 会开个定时器。我们认为溢出前会先进入testapprun_s，看看在TA_SLEEP_DONE 做了什么吧。接着找作案现场

case TA_SLEEP_DONE : {     event_data_t* dw_event = instance_getevent(10); //clear the event from the queue                             // waiting for timout from application to wakup IC          if (dw_event->type != DWT_SIG_RX_TIMEOUT)          {                    // if no pause and no wake-up timeout continu waiting for the sleep to be done.          inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; //wait here for sleep timeout            break;     }

可以看出如果进来发现不是TIMEOUT，一直break，所以定时器一直需要等待溢出才执行后面的代码。

……等待定时器，等待定时器……溢出。好了，我们看后面的代码

inst->done = INST_NOT_DONE_YET; inst->instToSleep = 0; inst->testAppState = inst->nextState; inst->nextState = 0; //clear inst->instancetimer_saved = inst->instancetimer = portGetTickCount(); //set timer base

有点尴尬nextState好像好久没用到，没事回头找代码

case RTLS_DEMO_MSG_RNG_INIT: {       if(inst->mode == TAG_TDOA) //only start ranging with someone if not ranging already          {              uint32 final_reply_delay_us;              uint32 resp_dly[RESP_DLY_NB];              int i;              inst->testAppState = TA_TXE_WAIT;              inst->nextState = TA_TXPOLL_WAIT_SEND ; // send next poll

 

根据done = INST_NOT_DONE_YET;退出不加载定时器，根据TA_TXPOLL_WAIT_SEND 我们再找作案现场

case TA_TXPOLL_WAIT_SEND :  //TAG:send poll message             {

这里主要是发送poll message给ANCHOR

与发送相关的代码

inst->msg.seqNum = inst->frame_sn++; setupmacframedata(inst, RTLS_DEMO_MSG_TAG_POLL); #if (USING_64BIT_ADDR==1)          inst->psduLength = TAG_POLL_MSG_LEN + FRAME_CRTL_AND_ADDRESS_L + FRAME_CRC; #else   dwt_writetxdata(inst->psduLength, (uint8 *)  &inst->msg, 0) ;  // write the frame data dwt_writetxfctrl(inst->psduLength, 0); dwt_starttx(DWT_START_TX_IMMEDIATE | inst->wait4ack);

发送具体数据包在meg中了，我们现在具体不看，ANCHOR用到在看，反正是发送了，而且还是个DWT_RESPONSE_EXPECTED

inst->wait4ack = DWT_RESPONSE_EXPECTED;

 

还设置了两个延时，tx后多久打开接收器等待应答，以及rx 的timeout

//set the delayed rx on time (the response message will be sent after this delay) dwt_setrxaftertxdelay(inst->txToRxDelayTag_sy); dwt_setrxtimeout((uint16)inst->fwtoTime_sy);

 

发送完poll message等待应答需要转状态，保存重要变量

inst->testAppState = TA_TX_WAIT_CONF ;   // wait confirmation inst->previousState = TA_TXPOLL_WAIT_SEND ; inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; //will use RX FWTO to time out (set below)

根据done，知道退出后不需要启动定时器。

之前我们就分析过TA_TX_WAIT_CONF，不过这个函数会根据previousState有很多岔路，我们接着分析它

if(dw_event->type != DWT_SIG_TX_DONE) //wait for TX done confirmation {          if(dw_event->type == DWT_SIG_RX_TIMEOUT)          {          ……没有启动定时器，所以不会执行到这里          }         inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT;     break; }

由这段代码可以看出，TAG一直不停的循环，直到等待DWT_SIG_TX_DONE，也就是DWM1000把数据包发送出去。

inst->done = INST_NOT_DONE_YET;   else  {          inst->txu.txTimeStamp = dw_event->timeStamp; if(inst->previousState == TA_TXPOLL_WAIT_SEND)           {

可以看出，满足if 判断会接着执行后面的代码，后面很多代码都是计算poll message 发送时间的。

uint64 tagCalculatedFinalTxTime ; // Embed into Final message: 40-bit pollTXTime,  40-bit respRxTime,  40-bit finalTxTime tagCalculatedFinalTxTime = (inst->txu.txTimeStamp + inst->finalReplyDelay) & MASK_TXDTS;  // time we should send the response inst->delayedReplyTime = tagCalculatedFinalTxTime >> 8;   // Calculate Time Final message will be sent and write this field of Final message // Sending time will be delayedReplyTime, snapped to ~125MHz or ~250MHz boundary by // zeroing its low 9 bits, and then having the TX antenna delay added // getting antenna delay from the device and add it to the Calculated TX Time tagCalculatedFinalTxTime = tagCalculatedFinalTxTime + inst->txantennaDelay; tagCalculatedFinalTxTime &= MASK_40BIT;   // Write Calculated TX time field of Final message memcpy(&(inst->msg.messageData[FTXT]), (uint8 *)&tagCalculatedFinalTxTime, 5); // Write Poll TX time field of Final message memcpy(&(inst->msg.messageData[PTXT]), (uint8 *)&inst->txu.tagPollTxTime, 5);

 

这几个时间我们后面在分析，我们先看代码

inst->testAppState = TA_RXE_WAIT ;   message = 0; //break ; // end case TA_TX_WAIT_CONF case TA_RXE_WAIT :  //enable rx,and  wait to recive a message

接着会执行TA_RXE_WAIT ，根据之前的分析结果，这里只是打开接收器等到数据，所以到此为止，TAG又开始等待了，等待ANCHOR回复。

 

总结一下该小段： TAG发送poll message给ANCHOR后进入等待状态，ANCHOR应该此时接收数据并回复TAG。

 

转载于:https://www.cnblogs.com/tuzhuke/p/7719491.html