You are not logged in.
I found that the long packet mode was no longer in the reference design v4.0, so I'm trying to implement it by myself. But I don't understand how to fill some data into MAC frame. I checked EthernetCallback() as example but didn't find any statement to do that. I'm quite confused. Can I just assign value to the address that txBuffer.data points to, such as txBuffer.data[0] = 1?
Any suggestion or hint will be appreciated.
Thanks a lot!
Offline
Are you trying to just transmit arbitrary data to the receiving node? If so, you actually don't need to include your own data into the payload of the transmit Macframe. Simply specifying the length to be long (say, N = 1400 bytes) will make the PHY transmitter send a long packet. Whatever bytes that were previously in the packet buffer will be sent. Even if they are all zero, the scrambler inside the transmitter will randomize what is actually sent (helping to avoid peak-to-average-power issues in OFDM).
The easiest way to do this would be something like this in the while loop at the bottom of the main function:
Macframe myPacket;
myPacket.header.length = 1400;
myPacket.header.pktType = DATAPACKET;
myPacket.header.fullRate = QPSK;
memcpy(myPacket.header.srcAddr,myAddr,6);
memcpy(myPacket.header.destAddr,routeTable[(myID+1)%2].addr,6);
while(1) {
usleep(B);
warpmac_sendOfdm(&myPacket);
}If you disable ethernet interrupts, this block of code will send a 1400 byte data packet every B microseconds.
If you need a custom payload that isn't random, you will have to copy it into the PHY's packet buffers. You can do this in the same way that emacRx_int_handler in WARPMAC.c does it. Basically, the address of payload buffer in the PHY can be acquired by:
warpphy_getBuffAddr(0)+24
Where the 24 is the length of the header (since you don't want to overwrite that) and the transmit buffer index is assumed to be 0 (which is the case for all data packets in the current reference design).
Offline
I also have a question regarding the code in warpmac.c:
void warpmac_sendEthernet(Macframe* packet){
unsigned int length;
length = (packet->header.length)-4;
XEmac_FifoSend(&Emac, (void *)(warpphy_getBuffAddr(controlStruct.rxBuffIndex)+NUM_HEADER_BYTES), length);
//rxPacket->isNew=1;
}I found the packet->header.length has already been taken care of in rxPhyGood() using
rxPacket->header.length = rxPacket->header.length - NUM_HEADER_BYTES - 4;
Should we adjust the buffer address & length here?
Offline
The second argument to XEmac_FifoSend() specifies the address of the first payload byte for a new Ethernet packet. This is documented in the EMAC driver API, in $EDK/sw/XilinxProcessorIPLib/drivers/emac_v1_00_e/doc/.
The full wireless packet is stored at warpphy_getBuffAddr(controlStruct.rxBuffIndex), so the EMAC DMA should skip the first NUM_HEADER_BYTES bytes to avoid sending the wireless MAC header over the Ethernet link.
The third argument to XEmac_FifoSend() is the number of payload bytes in the new Ethernet packet. The variable 'length' already excludes the wireless header and checksum bytes.
Offline
Sorry I did not make my question clear.
I am reading the CSMAMAC.c code. I figured after the line I quoted from rxPhyGood(), the header.length should be only for the payload without checksum. But when it is passed to warpmac_sendEthernet(), it is again deducted by 4. Does this make it short?
My other question is "(void *)(warpphy_getBuffAddr(controlStruct.rxBuffIndex)+NUM_HEADER_BYTES)" should be the address of checksum. Did I get it wrong? Thanks a lot for your help.
Offline
I got a similar question for the EMAC -> OFDM.
After emacRx_int_handler(void *Callback)
XEmac_FifoRecv(EmacPtr, (void *)(warpphy_getBuffAddr(controlStruct.txBuffIndex)+NUM_HEADER_BYTES), &length);
The length should be for checksum and payload, right? But in warpmac_sendOfdm(Macframe* packet), we have
numFullRate = ((packet->header.length + 4 + (6*packet->header.fullRate-1))/(6*packet->header.fullRate)) * (sisoMode+1); //Update the PHY header length to include the MAC header bytes and full-packet checksum packet->header.length = NUM_HEADER_BYTES + 4 + packet->header.length;
Is the final packet->header.length larger than it should be?
I don't think the code is wrong since it works well on the machine, but your explanation can help me a great deal in understanding the design. Thanks!
Last edited by DQ A (2008-Mar-07 02:38:11)
Offline