[求助]SMAC程序里Packet的最小长度为什么是5？u1PromiscuousMode表示什么？ SMAC, Packet, 程序, 长度, 求助

在SMAC代码（Ver 4.2）里，接收到Packet以后，会有这样的判断语句：

if (gsPhyOptions.Bits.u1PromiscuousMode)
  u8MinLen = 3;
else
  u8MinLen = 5;

想问问这个gsPhyOptions.Bits.u1PromiscuousMode代表什么意义？
我看到在MCUInit()函数中的PLMEPhyReset()里，将这个gsPhyOptions.Bits.u1PromiscuousMode设置成了FALSE，也就是说Packet的默认最小长度是5个bytes，根据注释里的说明，即2个 CRC bytes，2个Code bytes，1个数据byte。那么其中的这2个Code Bytes 是作什么用的呢？

谢谢^^

[此贴子已经被作者于2007-5-2 13:51:20编辑过]

从RF transceiver过来的数据前面两个字节是空的，需要丢弃，所以在读数据的时候有效数据是从第3个字节开始的，可以看一下13192的手册就知道了

谢谢斑竹^^ 我看过13192的参考手册了，这2个code bytes确实应该丢弃。但我想不通中断函数IRQIsr()在做接收的那部分代码里，为什么经过CRC校验、判断Packet长度是否合法这两步以后，会有这几句话来判断Code byte：

/* Test the Byte Codes */
if (gsPhyOptions.Bits.u1PromiscuousMode == 0)
{
    u16Temp = SPIDrvRead2(RX_PKT); /* Get the code bytes */

    if ((u16Temp != 0xFF7E) && ((gsPhyOptions.Bits.u1PromiscuousMode == FALSE)))
    {
        /* Read the MC13192 trx register. Timer trigger off. */
        u16StatusContent = (SPIDrvRead(MODE_ADDR) & 0xFF7F);
        /* Update the trx register. */
        SPIDrvWrite(MODE_ADDR, u16StatusContent);
        /* Forces the MC13192 to enter the receive mode. */
        RTXENAssert();
        return;
    }
}

/* A valid packet has been received. */
gu8RTxMode = IDLE_MODE; /* Set the rtx_state to idle */
SPIDrvWrite(T1_HI_ADDR, 0x8000); /*
                                  * Disables TC1 and clears the 
                                  * IRQ.
                                  */
SPIDrvWrite(T1_LO_ADDR, 0x0000);
psDrvRxPacket->u8DataLength = u8DataLength;
psDrvRxPacket->u8Status = SUCCESS;
PDDataIndication(); /* Notify PHY that there is data available. */
return;

根据程序里的注释，经过/* Test the Byte Codes */这一步以后才能认为接到了合法的packet，也就是说这2个code bytes必须要是 0xFF7E 才行？

我调程序的时候，之前的CRC校验、Packet长度判断都已经通过了，只是这个Test the Byte Codes 过不去，我收到的code bytes不是 0xFF7E，所以无法执行/* A valid packet has been received. */之后的程序。所以觉得很奇怪。。

[此贴子已经被作者于2007-5-9 14:51:43编辑过]

[此贴子已经被作者于2007-5-9 14:56:39编辑过]

恩，好问题。我没有仔细看过，大家一起讨论一下，找找13192的手册上有没有说明。

已经解决这个问题啦！
虽然我接收到的code bytes不是0xFF7E，但每次都是0x5CC5，所以我把程序里的0xFF7E替换成0x5CC5就可以拉，具体原因也不是很明白。发射端我用的是从厂商购买的某个成品Zigbee模块，不是SARD版，也不是自己制作的，无法知道发射端如何设置的，可能这造成了这个差别。
在此谢谢斑竹的热心回答哦~~ //bow *^^*