zigbee 终端入网
大家好，这是（只有终端和协调器）终端入网的图，终端POLL_RATE为0，-DRFD_RCVC_ALWAYS_ON = TRUE，程序休眠是根据标志位强制休眠
当入网时，会在 1 等待的时间比较长（有时短），我在SampleeApp.c中的事件处理函数中的 case ZDO_STATE_CHANGE中加入休眠标志，发现在 1 步骤那，可能程序就休眠了，于是没有第 2 步 和第 3 步了，这样问题就出现了，调用那个…DataRequest()发送函数，数据发送不出去，但是函数返回成功，重新调用ZDOInitDevice(0)也不能入网
请问：后面两步是干什么的？
后面两步在程序里面 的什么地方？
休眠标志置位 应该在什么地方设置呢？
有知道的么？
大家可以给说一下可能的原因啊
没人指点下么？
你好，能否把你的抓包文件保存下来，用附件上传。
Hello VV,
图中 2中的终端发的数据是在函数 ZDP_DeviceAnnce（）发送的，通过在函数中加入串口输出函数发现，串口串口显示数据已发出，但抓包，待一会儿才 抓到发出去的数据，就是等到 协调器的网络状态包（就是那个 NWK Unknown Command，15s发一次）发出来以后，才能抓到，而且2，3几乎同一时间抓到，是不是AF_DataRequest()函数隐含有交互等待的部分？
从整个抓包过程来看，工作应该是正常的呀，
我看到节点和协调器在发出Device Announce以后，节点向协调器发了一条数据在Rx18，payload 是
06 10 2A 00 0A 05 00 00 00 12 4B 00 01 65 EA B0对吗？
Hi,VV
这个图是正常的图啊
我的终端在入网时，会在第一个图人 1 处等待（有时长有时短）
但这时候，我终端休眠了，后面图中的 2 和 3 就没有了
我的是强制休眠的，是在ZDO_STATE_CHANGE之后 置位休眠标志，这样，循环协议栈时检测到我人休眠标志就强制休眠了
问题是：很可能会在图1 处休眠啊，那就没有图2 图3 的那两条交互命令了啊，没有后面这两条交互命令，调用AF_DataRequest发送数据发送不出去，但是返回值却是成功的，调用ZDOInitDevice(0)也不能再入网了
我最终想知道的是，应该在什么地方 置位休眠标志呢
Jiao
我觉得你如果要开机就休眠，那只要等到应用层初始化完成就可以去休眠了，跟入网没有关系。
在唤醒的时候再入网发送数据。
hi,Winter Two:
我的流程是，上电时先入网，如果入网成功或入网失败（限制入网6次），才休眠的
我的在数码管显示，入网等情况下是不休眠的（清休眠标志），只有在数码管显示完成、入网成功后，入网失败后，再设置休眠标志
我的问题是 到底哪里 是入网成功后呢？
我分别在ZDO_JoinConfirmCB（）和ZDO_STATE_CHANGE中添加过休眠标志，但是有时候会在图 1 处，休眠了，那终端就没有后两条交互了
Hi，VV,
这个问题有了新进展
我发现是因为spi的问题，我的spi用的是 P0_3,P0_4,P0_5,spi接了SST FLASH和RTC时钟芯片，
SST FLASH（P0_3,P0_4,P0_5，P1_3,P2_3） RTC时钟芯片( P0_3,P0_4,P0_5,P0_6)
一旦初始化spi,终端就会在图中1处等待协调器的网络状态包
如果屏蔽掉spi，终端就不会等待协调器的网络状态包了，就直接发图中2处的数据
请问：spi可能会在什么地方影响入网的呢？
P0.3~P0.5在协议栈里面用作串口了，你把相关功能屏蔽掉，试下！
Hi VV,
哦，忘记说了，协议栈里边，我串口已经改过了，串口用的是（P_4,P1_5），程序运行良好，rtc、sst存储、串口都能正常工作
rtc，sst共用spi,我想不通spi和入网有什么关系，是不是入网过程中，有p0口引脚的判断或使用？
不好意思，我问下你实现这个目的是为了什么？为了不让节点无休止的去搜网吗？
Hi VV,
我这个流程就是 休眠—— 定时唤醒采集数据（数据够了发送给协调器）--休眠（需要低功耗的） 这样循环
这样，开始上电时能入网限制为6次，入不上就休眠了，不在网的话以后能定时入网等等功能
还能通过无线设定终端的PAN ID,发射功率啊等等一些参数
大体这样
现在这个问题有了新进展，在mac_radio.c 文件中的MAC_INTERNAL_API void macRadioUpdateTxPower(void)函数中，我修改的发射功率，先从e方中读数，spi接口的，根据数值给reqTxPower赋功率值
只要把switch这块屏蔽掉，抓包就看到不会等协调器的网络状态包了
把switch这块屏蔽掉，直接给reqTxPower 赋值，如：reqTxPower =0x95; ，也不会看到等协调器的状态包
反正只要有switch这块，就会等协调器的网络状态包，实在不知道是什么原因
MAC_INTERNAL_API void macRadioUpdateTxPower(void)
{ halIntState_t s;
/**********************修改发射功率************************/
switch(SPI_RTCEE_Byte_Read(LAUNCH_WATT_ADDR))
{ case 0: reqTxPower =0x05;break; //-22dBm
case 1: reqTxPower =0x15;break;
case 2: reqTxPower =0x25;break;
case 3: reqTxPower =0x35;break;
case 4: reqTxPower =0x45;break;
case 5: reqTxPower =0x55;break;
case 6: reqTxPower =0x65;break;
case 7: reqTxPower =0x75;break;
case 8: reqTxPower =0x85;break;
case 9: reqTxPower =0x95;break;
case 10: reqTxPower =0xa5;break;
case 11: reqTxPower =0xb5;break;
case 12: reqTxPower =0xc5;break;
case 13: reqTxPower =0xd5;break;
case 14: reqTxPower =0xe5;break;
case 15: reqTxPower =0xf5;break;
default: //HalUARTWrite(0,"Wrong Power Pra!\n",18);
reqTxPower =0xe5;
}
/* * If the requested power setting is different from the actual radio setting,
* attempt to udpate to the new power setting. */
HAL_ENTER_CRITICAL_SECTION(s);
if (reqTxPower != macPhyTxPower) {
/* * Radio power cannot be updated when the radio is physically transmitting.
* If there is a possibility radio is transmitting, do not change the power
* setting. This function will be called again after the current transmit * completes. */
if (!macRxOutgoingAckFlag && !MAC_TX_IS_PHYSICALLY_ACTIVE())
{ /* * Set new power level; update the shadow value and write * the new value to the radio hardware. */
macPhyTxPower = reqTxPower;
MAC_RADIO_SET_TX_POWER(macPhyTxPower);
} }
HAL_EXIT_CRITICAL_SECTION(s);
抓包就看到不会等协调器的网络状态包了，是什么意思？
Hi VV
等待网络状态包的图
不等待协调器网络状态包的图
Hi VV,
这个问题确定是不能在macRadioUpdateTxPower（）这个函数中读spi，读spi的话就会有上述问题，还不知道原因
这样的话，也有其他解决办法了：就是在其他地方读spi e方中的数据到一个全局变量，然后在这个函数中用这个全局变量就能解决问题了
昨天看了一天关于发射功率的协议栈代码，没太看懂啊
为什么不能提前读好，然后去设置呢？
ZMacSetTransmitPower( ZMacTransmitPower_t level )
Hi VV，
嗯，现在改成这样了
以前直接读，提前读出来用的话，就只能用全局变量了，不过全局变量能少用还是尽量少用啊
少用，可以减小占用的ram，而且主要是，全局变量多了，自己就想不过了，容易乱，尤其是程序量越来越大的时候
就是一个8位的变量，应该不会占用很多空间吧