我们前面分析过,不论ANCHOR 还是TAG,前面变量的初始化基本都是一样的,只是状态机必须明确区分不同的设备类型。我们从开始看TAG。由于初始化TAG的 testAppState一样初始化为TA_INIT。
INST_STATES testAppState ; int instance_init_s(int mode) TA_INIT |
case TA_INIT : // printf("TA_INIT") ; switch (inst->mode) { case TAG: { int mode = 0; dwt_enableframefilter(DWT_FF_DATA_EN | DWT_FF_ACK_EN); //allow data, ACK frames; inst->frameFilteringEnabled = 1 ; dwt_setpanid(inst->panid); dwt_seteui(inst->eui64); #if (USING_64BIT_ADDR==0) //the short address is assigned by the anchor #else //set source address into the message structure memcpy(&inst->msg.sourceAddr[0], inst->eui64, ADDR_BYTE_SIZE_L); #endif //change to next state - send a Poll message to 1st anchor in the list inst->mode = TAG_TDOA ; inst->testAppState = TA_TXBLINK_WAIT_SEND; memcpy(inst->blinkmsg.tagID, inst->eui64, ADDR_BYTE_SIZE_L); mode = (DWT_LOADUCODE|DWT_PRESRV_SLEEP|DWT_CONFIG|DWT_TANDV); if((dwt_getldotune() != 0)) //if we need to use LDO tune value from OTP kick it after sleep { mode |= DWT_LOADLDO; } if(inst->configData.txPreambLength == DWT_PLEN_64) //if using 64 length preamble then use the corresponding OPSet { mode |= DWT_LOADOPSET; } #if (DEEP_SLEEP == 1) if (inst->sleep_en) dwt_configuresleep(mode, DWT_WAKE_WK|DWT_WAKE_CS|DWT_SLP_EN); //configure the on wake parameters (upload the IC config settings) #endif } break; |
dwt_enableframefilter(DWT_FF_DATA_EN | DWT_FF_ACK_EN); //allow data, ACK frames; inst->frameFilteringEnabled = 1 ; |
控制滤波器,只接受DATA 和ACK数据,并且将frameFilteringEnabled 设置为1. 主要这个不TAG的frameFilteringEnabled,与前面的ANCHOR的frameFilteringEnabled 是一个东西,但是赋值分为两个,因为是两份代码分别跑在两个模块中。
dwt_setpanid(inst->panid); dwt_seteui(inst->eui64); |
Panid 和 64位地址设定,与ANCHOR一样。
#if (USING_64BIT_ADDR==0) //the short address is assigned by the anchor #else //set source address into the message structure memcpy(&inst->msg.sourceAddr[0], inst->eui64, ADDR_BYTE_SIZE_L); #endif |
由于短地址还没有,所以msg.sourceAddr目前只能是64位长地址。
inst->mode = TAG_TDOA ; |
这个mode之前没有用过,我们先记录下,以后肯定会用到TAG_TDOA
inst->testAppState = TA_TXBLINK_WAIT_SEND; |
这个testAppState记录上,下次进去testapprun_s 找作案现场用
memcpy(inst->blinkmsg.tagID, inst->eui64, ADDR_BYTE_SIZE_L); |
又一个变量被设置,我们先记录,后面用的时候查看, 这里保存了TAG的长地址
mode = (DWT_LOADUCODE|DWT_PRESRV_SLEEP|DWT_CONFIG|DWT_TANDV); if((dwt_getldotune() != 0)) //if we need to use LDO tune value from OTP kick it after sleep { mode |= DWT_LOADLDO; } if(inst->configData.txPreambLength == DWT_PLEN_64) //if using 64 length preamble then use the corresponding OPSet { mode |= DWT_LOADOPSET; } |
mode是个变量,给这个mode 赋了很多值
#if (DEEP_SLEEP == 1) if (inst->sleep_en) dwt_configuresleep(mode, DWT_WAKE_WK|DWT_WAKE_CS|DWT_SLP_EN); //configure the on wake parameters (upload the IC config settings) #endif } break; |
如果我们没有使用sleep,前面mode都感觉没有用了,mode主要作用是告诉chip醒来以后需要恢复那些量,我们先不具体分析了。现在break了,和ANCHOR一样,返回值为0,符合while条件会再次跳入到testapprun_s。
我们根据上面的testAppState = TA_TXBLINK_WAIT_SEND;再次找作案现场
case TA_TXBLINK_WAIT_SEND : { int flength = (BLINK_FRAME_CRTL_AND_ADDRESS + FRAME_CRC); //blink frames with IEEE EUI-64 tag ID inst->blinkmsg.frameCtrl = 0xC5 ; inst->blinkmsg.seqNum = inst->frame_sn++; dwt_writetxdata(flength, (uint8 *) (&inst->blinkmsg), 0) ; // write the frame data dwt_writetxfctrl(flength, 0); //using wait for response to do delayed receive inst->wait4ack = DWT_RESPONSE_EXPECTED; dwt_setrxtimeout((uint16)inst->fwtoTimeB_sy); //units are symbols //set the delayed rx on time (the ranging init will be sent after this delay) dwt_setrxaftertxdelay((uint32)inst->rnginitW4Rdelay_sy); //units are 1.0256us - wait for wait4respTIM before RX on (delay RX) dwt_starttx(DWT_START_TX_IMMEDIATE | inst->wait4ack); //always using immediate TX and enable dealyed RX inst->instToSleep = 1; //go to Sleep after this blink inst->testAppState = TA_TX_WAIT_CONF ; // wait confirmation inst->previousState = TA_TXBLINK_WAIT_SEND ; inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; //will use RX FWTO to time out (set below) } break ; // end case TA_TXBLINK_WAIT_SEND |
其中如下几步是DWM1000 代码中发送数据的基本流程
dwt_writetxdata(flength, (uint8 *) (&inst->blinkmsg), 0) ; dwt_writetxfctrl(flength, 0); dwt_setrxtimeout((uint16)inst->fwtoTimeB_sy); //units are symbols dwt_setrxaftertxdelay((uint32)inst->rnginitW4Rdelay_sy); dwt_starttx(DWT_START_TX_IMMEDIATE | inst->wait4ack); |
发送了一个数据包,数据包的内容为
inst->blinkmsg.frameCtrl = 0xC5 ; inst->blinkmsg.seqNum = inst->frame_sn++; |
其中还求必须有回应
//using wait for response to do delayed receive inst->wait4ack = DWT_RESPONSE_EXPECTED; |
发送完延时打开接收器(设定rx接收timeout以及打开接收器的时间)
dwt_setrxtimeout((uint16)inst->fwtoTimeB_sy); //units are symbols dwt_setrxaftertxdelay((uint32)inst->rnginitW4Rdelay_sy); |
设定了一些变量,有些还是很重要的。
inst->instToSleep = 1; //go to Sleep after this blink inst->testAppState = TA_TX_WAIT_CONF ; // wait confirmation inst->previousState = TA_TXBLINK_WAIT_SEND ; inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; //will use RX FWTO to time out (set below) |
同样根据inst->testAppState = TA_TX_WAIT_CONF ; 找下次进去testapprun_s 的作案现场。
到现在为止,我们分析代码发现,ANCHOR在等TAG发数据,现在TAG给它发送了,ANCHOR应该会收到数据了,而TAG依然会接着执行。 我们先看TAG,然后在看ANCHOR。 记住目前的状态是ANCHOR准备接收数据了。
接着看TAG,退出testapprun_s时,done为INST_DONE_WAIT_FOR_NEXT_EVENT;
if(done == INST_DONE_WAIT_FOR_NEXT_EVENT_TO) //we are in RX and need to timeout (Tag needs to send another poll if no Rx frame) { if(instance_data[instance].mode == TAG_TDOA) { instance_data[instance].instancetimer += instance_data[instance].tagBlinkSleepTime_ms; //set timeout time instance_data[instance].instancetimer_en = 1; //start timer } instance_data[instance].stoptimer = 0 ; //clear the flag - timer can run if instancetimer_en set (set above) instance_data[instance].done = INST_NOT_DONE_YET; |
看后面的注释,目前TAG发送一笔Blink信号后,确实有个延时打开接收器的动作,所以说确实现在是RX状态。
if(done == INST_DONE_WAIT_FOR_NEXT_EVENT_TO) //we are in RX and need to timeout |
我们再看看INST_DONE_WAIT_FOR_NEXT_EVENT_TO 这个宏定义,可以看出需要等待一个timeout,就知道if判断里面是开启定时器,等待一段时间了
#define INST_DONE_WAIT_FOR_NEXT_EVENT_TO 2 //this signifies that the current event has been processed and that instance is waiting for next one with a timeout //which will trigger if no event coming in specified time |
我们再来分析定时器代码,因为我们前面分析,TAG现在的mode是TAG_TDOA,所以摘录出其对应的代码
if(instance_data[instance].mode == TAG_TDOA) { instance_data[instance].instancetimer += instance_data[instance].tagBlinkSleepTime_ms; //set timeout time instance_data[instance].instancetimer_en = 1; //start timer } instance_data[instance].stoptimer = 0 ; //clear the flag - timer can run if instancetimer_en set (set above) instance_data[instance].done = INST_NOT_DONE_YET; |
我们标注颜色的两个变量,我们搜索一下之前是否有初始化
uint32 instancetimer; // e.g. this timer is used to timeout Tag when in deep sleep so it can send the next poll message int tagBlinkSleepTime_ms; instancesettagsleepdelay 1000 |
我们没有看到instancetimer的初始化,我们暂时考虑它为0,但是tagBlinkSleepTime_ms 是1000,所以通过第一句赋值语句instancetimer 等于1000了。
其它几个变量instancetimer_en和stoptimer 立马会用到,注意一下done此时被赋值为INST_NOT_DONE_YET,这里也记录一下,后面看怎么走了。
接着看代码
if((instance_data[instance].instancetimer_en == 1) && (instance_data[instance].stoptimer == 0)) |
这个if里面两个变量判定与刚才完全一样,所以立马用到了它们,而且满足条件,接着看if里面的内容
if(instance_data[instance].instancetimer < portGetTickCount()) { event_data_t dw_event; instance_data[instance].instancetimer_en = 0; dw_event.rxLength = 0; dw_event.type = DWT_SIG_RX_TIMEOUT; dw_event.type2 = 0x80 | DWT_SIG_RX_TIMEOUT; //printf("PC timeout DWT_SIG_RX_TIMEOUT\n"); instance_putevent(dw_event); } |
If条件里变量instancetimer 是我们刚刚计算赋值的,而portGetTickCount()函数我们之前没有遇到过,简单看下
#define portGetTickCount() portGetTickCnt() unsigned long portGetTickCnt(void) { return time32_incr; } |
我们看到这里,它返回一个time32_incr. 看到这里绝对这个变量没有初始化,假定是0,那就错误了。 这里肯定是有个定时器了,time32_incr是一个全局变量,在timer中断里增加。 所以portGetTickCnt() 返回一个实时时间量,再看我们之前的instancetimer认为是
instance_data[instance].instancetimer += instance_data[instance].tagBlinkSleepTime_ms; 现在感觉instance_data[instance].instancetimer应该也是一个在定时器累加的全部量,不然两者没有可比性,没法有相对延时的概念。
简单看下time32_incr 一些像代码。
void SysTick_Handler(void) { time32_incr++; #ifdef FILESYSTEM_ENABLE fsd_service(); #endif } |
通过下面的语句判断定时时间是否到了
if(instance_data[instance].instancetimer < portGetTickCount()) |
里面的语句,就是产生一个事件,事件type为DWT_SIG_RX_TIMEOUT,通过instance_putevent(dw_event)加入到事件列表,我们之前是通过peek查看是否有事件。
这几个event 相关的函数暂时不会影响我们分析大局,先暂时不看它们了。
instancetimer_en 设置为0,标志着停止计时。
instance_data[instance].instancetimer_en = 0 |
虽然我们把TAG代码中的instance_run中的代码全部分析完了,但是其实TAG实际跑代码不是这样的。正确的顺序应该是,接着我们刚才设定定时器à 查看定时器是否到期(没有到期)à返回Main 函数(我们分析过ANCHOR,除了打印信息,没有实质内容)à重新 instance_runà……定时器到期,设定event事件。
其中……可能重复了很多次,我们需要再看看里面怎么执行的,是否还会增加定时器等等,我们逐一再看看,这段时间是TAG发送完blink后打开接收器等待ANCHOR应答的时间段,虽然实际上时间可能1s不到,但是我们分析代码可能需要几个小时甚至更长。 接着看第二次进入instance_run。
int done = INST_NOT_DONE_YET; int message = instance_peekevent(); //get any of the received events from ISR while(done == INST_NOT_DONE_YET) { //int state = instance_data[instance].testAppState; done = instance_localdata[instance].testapprun_fn(&instance_data[instance], message) ; // run the communications application //we've processed message message = 0; } |
注意和这里,因为我们假定是时间没有到,所以peekevent应该还是啥也没有,所以message返回的还是0. 所以我们会再次进入testapprun_s。 我们需要找上次testAppState,
inst->testAppState = TA_TX_WAIT_CONF ; // wait confirmation inst->previousState = TA_TXBLINK_WAIT_SEND ; |
东西记不住1是返回去看代码,而是用笔记录,我们之前分析有记录。直接在testapprun_s 找相应的case
case TA_TX_WAIT_CONF : //after tx,waif for comfirm |
这里代码不少,我们需要根据if删减一下,这里事件TA_TX_WAIT_CONF,其实就是等待是否有应答,因为TAG 在发送blink信号的时候明确提出需要应答
{ event_data_t* dw_event = instance_getevent(11); //get and clear this event //NOTE: Can get the ACK before the TX confirm event for the frame requesting the ACK //this happens because if polling the ISR the RX event will be processed 1st and then the TX event //thus the reception of the ACK will be processed before the TX confirmation of the frame that requested it. if(dw_event->type != DWT_SIG_TX_DONE) //wait for TX done confirmation { if(dw_event->type == DWT_SIG_RX_TIMEOUT) //got RX timeout - i.e. did not get the response (e.g. ACK) { //printf("RX timeout in TA_TX_WAIT_CONF (%d)\n", inst->previousState); //we need to wait for SIG_TX_DONE and then process the timeout and re-send the frame if needed inst->gotTO = 1; } inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; break; } inst->done = INST_NOT_DONE_YET; if(inst->previousState == TA_TXFINAL_WAIT_SEND)// 不满足 { …… } else if (inst->gotTO) //timeout { //printf("got TO in TA_TX_WAIT_CONF\n"); inst_processrxtimeout(inst); inst->gotTO = 0; inst->wait4ack = 0 ; //clear this break; } else { inst->txu.txTimeStamp = dw_event->timeStamp; if(inst->previousState == TA_TXPOLL_WAIT_SEND) // 不满足 { …… } inst->testAppState = TA_RXE_WAIT ; // After sending, tag expects response/report, anchor waits to receive a final/new poll //fall into the next case (turn on the RX) message = 0; } } |
我们先一部分一部分的分析
if(dw_event->type != DWT_SIG_TX_DONE) //wait for TX done confirmation { if(dw_event->type == DWT_SIG_RX_TIMEOUT) //got RX timeout - i.e. did not get the response (e.g. ACK) { //printf("RX timeout in TA_TX_WAIT_CONF (%d)\n", inst->previousState); //we need to wait for SIG_TX_DONE and then process the timeout and re-send the frame if needed inst->gotTO = 1; } inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; break; } |
DWT_SIG_TX_DONE 这个事件应该是发送一帧数据后,DWM1000 中断里产生的,我们刚才在TAG发送了一帧数据,所以如果DWM1000 处理完了,应该会put event,事件type是DWT_SIG_TX_DONE。 好,那我们假设,下发数据后,DWM1000 还没有发送出去,我们代码已经执行到这里了,确实满足这个判断。 继续执行里面的
if(dw_event->type == DWT_SIG_RX_TIMEOUT) |
DWT_SIG_RX_TIMEOUT, 这个事件我们之前见过,是定时器溢出触发的的,我们刚才假定DWM1000 很快执行到这里,所以没有溢出,不满足条件。直接执行了。
inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; break; |
和TAG 上次退出时一样。一样分别是有如下几个关键变量没有修改
inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; inst->testAppState = TA_TX_WAIT_CONF ; // wait confirmation inst->previousState = TA_TXBLINK_WAIT_SEND ; |
因为这个时候定时器已经开启了,我们看看TAG此时退出到run里会执行那些。
if(done == INST_DONE_WAIT_FOR_NEXT_EVENT_TO) //we are in RX and need to timeout (Tag needs to send another poll if no Rx frame) { if(instance_data[instance].mode == TAG) //Tag (is either in RX or sleeping) { …… } if(instance_data[instance].mode == TAG_TDOA) { instance_data[instance].instancetimer += instance_data[instance].tagBlinkSleepTime_ms; //set timeout time instance_data[instance].instancetimer_en = 1; //start timer } instance_data[instance].stoptimer = 0 ; //clear the flag - timer can run if instancetimer_en set (set above) instance_data[instance].done = INST_NOT_DONE_YET; } |
再次给instancetimer它赋值,我们之前所instancetimer 是个动态量,分析有误。。。。。
###############》 其实定时时长没有变,所以还是和原来等待时间一样,后面持续在看是否溢出。==è重新分析instancetimer。
好,这是一种假设,另一种假设,依然针对下面这几行代码。
if(dw_event->type != DWT_SIG_TX_DONE) //wait for TX done confirmation { if(dw_event->type == DWT_SIG_RX_TIMEOUT) //got RX timeout - i.e. did not get the response (e.g. ACK) { //printf("RX timeout in TA_TX_WAIT_CONF (%d)\n", inst->previousState); //we need to wait for SIG_TX_DONE and then process the timeout and re-send the frame if needed inst->gotTO = 1; } inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; break; } |
我们分析代码可以知道,当没有发送完一直在等待事件DWT_SIG_TX_DONE,加入一种情况,DWM1000 坏掉了或者中断配置有问题,这个事件一直等不到,那么,上面的循环一直执行到定时器溢出。会满足后面的if(dw_event->type == DWT_SIG_RX_TIMEOUT),判断里面讲inst->gotTO = 1。 这个分支代码也很长了,因为我们可能需要在instance_run获取些信息了。 暂时不考虑怎么极端的情况。先预留一个DWM1000配置有误或者损坏TX后执行情况代码分析。
好了,我们假定DWM1000 一切正常,所以过了一段时间,收到了DWT_SIG_TX_DONE,那就不满足如下if条件,直接往后看吧。
if(dw_event->type != DWT_SIG_TX_DONE) //wait for TX done confirmation |
inst->done = INST_NOT_DONE_YET; if(inst->previousState == TA_TXFINAL_WAIT_SEND) { …… } else if (inst->gotTO) //timeout { …… } else { inst->txu.txTimeStamp = dw_event->timeStamp; if(inst->previousState == TA_TXPOLL_WAIT_SEND) { …… } inst->testAppState = TA_RXE_WAIT ; // After sending, tag expects response/report, anchor waits to receive a final/new poll //fall into the next case (turn on the RX) message = 0; } } //break ; // end case TA_TX_WAIT_CONF |
把不满足条件的代码注释掉,发现实际上当TAG发送完blink后这里只是简单的给几个重要的变量赋值,好好记录一下,根据经验这个很重要
inst->done = INST_NOT_DONE_YET; inst->testAppState = TA_RXE_WAIT ; |
一个全局变量txu.txTimeStamp赋值,这个初始化的时候没有动过,所以是0. 其中dw_event->timestamp 这个应该是DWM1000 在发送数据的时候MARK的时间,因为需要知道接收发送数据的时间换算距离。 其实发送blink 的时间应该没有什么意义,我们暂时不考虑,用到在回来看。
后面有个比较诡异的地方,没有break,直接会执行后面的case
//break ; // end case TA_TX_WAIT_CONF |
后面的case是TA_RXE_WAIT,我们在ANCHOR分析过,它是打开接收器,在TA_RXE_WAIT后面重要变量被修改了
inst->testAppState = TA_RX_WAIT_DATA; |
我们根据上面代码分析经验,我们简要瞅一眼TA_RX_WAIT_DATA。
case TA_RX_WAIT_DATA : //already recive a message // Wait RX data //printf("TA_RX_WAIT_DATA %d", message) ; switch (message) { |
在TA_RX_WAIT_DATA 会根据message执行不同的代码,我们前面分析了,如果没有event或者一些没有message 的event产生时,TA_RX_WAIT_DATA其实啥都不执行。也就是只有就收到无线信号时,message里面才是一个真实的数据。
分析到这里,TAG也在等ANCHOR的数据了。
我们回顾一下,ANCHOR启动后直接开始接收器等到TAG发送数据,分析TAG,TAG先发送一笔blink给ANCHOR,AHCHOR怎么回复blink我们还没有分析,TAG此时正在等ANCHOR的回复了,卡在这里了,我们下一节的内容主要分析ANCHOR接收blink以及回复blink。
遗留问题:TAG开了一个定时器,最后是取消了还是溢出了?