TI中文支持网示例
RF_cmdPropRxSniff.startTime += WOR_WAKE_UP_INTERVAL_RAT_TICKS(WOR_WAKEUPS_PER_SECOND);
/* Schedule RX */
RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropRxSniff, RF_PriorityNormal, &callback, RF_EventRxEntryDone);
更改为非阻塞
RF_postCmd(rfHandle, (RF_Op*)&RF_cmdPropRxSniff, RF_PriorityNormal, &callback, RF_EventRxEntryDone);
在CC1310 wake on radio中使用RF_runCmd函数进入嗅探和接收程序进入阻塞，功耗很低wor。如果更换为RF_postCmd后功耗应该是全接收的功耗。这是为什么
Viki Shi：
看一下如下解释：
There is no actual "WOR commands"and the WOR example depends on the sniff command. This means to have to handle the "sniff command done" callback each time to see if you received a WOR packet or if you are to schedule a new sniffer command.We have multiple RF Driver examples showcasing the use of run/post/schedule which is different ways of issuing a radio command.RF_runCmd()is a blocking call and it will only return if event passed to the functionor any of the default events (RF_EventLastCmdDone, RF_EventLastFGCmdDone, RF_EventCmdAborted, RF_EventCmdStopped and RF_EventCmdCancelled) is set.
You can change the call to RF_postCmd()/RF_scheduleCmd() if you don't want the blocking behavior. You could then use RF_pendCmd() if you would like to block on a command for some reason (this is what runCmd is, post + pend).
In this scenario, when there was no WOR event, the command returns with "RF_EventLastCmdDone" as there is no other command in the queue. So if you want to avoid blocking the thread, you can move to using for example RF_pendCmd() and add additional events to the event mask that you want to trigger your callback. For example, adding RF_EventLastCmdDone to the event mask means you would get the callback for each "unsuccessful WOR operation"
