You are not logged in.
In an effort to implement a new protocol, there is a need to add a new header of 18 bytes just before the payload section of the packet. I was trying to do this in warp framework. I have the following doubts:
1. I have two options in making changes to the code:
a. I change the Macframe struct and add new fields to it (such that these new fields denote the new extra header).
OR
b. I add this extra header in the "data" field of the Macframe struct.
In attempting to use option 'a', I have found that there are various places in the code, where the fact has been used that header length is '24' and the number 24 has been used. If I use option 'a', I will have to change the number 24 in such places to 24 + 18 = 42 [old header length = 24 bytes, extra header length = 18, new header length = 42]. I want to know whether the number 24 used in the following lines is denoting the header length(these are found in the file warpmac.c):
mimo_ofdmRx_setByteNums( (unsigned int)(24 + (18<<8) + (19<<16) + (14<<24) )); ------>in warpmac_init()
XEmac_FifoSend(InstancePtr, OFDM_TXRX_MIMO_RXPKTBUFFER_BASEADDR+24, length); ------> in warpmac_sendEthernet()
In attempting to use option 'b', I am unable to comprehend how to add the extra header to the "data" field. Should I do a malloc of data.length + 18 bytes and then copy the data and make packet->data point to this new malloced space? Or is there some other method I can use?
2. According to you, which one do you a find a more feasible option - 'a' or 'b' ? Kindly suggest. Thank you.
Last edited by toolbox (2007-Jun-26 17:55:49)
Offline
I can address some of your lower-level questions; Chris will be more helpful on the question of modifying the MacFrame struct.
1) The number of bytes allocated to the header must be a multiple of the number of bytes in one base rate OFDM symbol. In the standard case of QPSK modulation for base rate symbols, each using 48 subcarriers for data, this means 12 bytes per OFDM symbol. The current header occupies 2 base rate symbols. You will need to use 4, corresponding to 48 bytes of header. You will need to zero-pad the remaining 6 bytes to fill in the last symbol.
2) The mimo_ofdmRx_setByteNums function sets control values in the PHY at boot, not per packet. The value of 24 here is a parameter (unused at the moment), not the number of header bytes. You should leave this funciton call as-is.
3) OFDM_TXRX_MIMO_RXPKTBUFFER_BASEADDR+24 corresponds to the memory address of the first payload byte in the PHY's receive packet buffer- the first byte in the packet after the MAC header. This address must be 64-bit aligned for use with the PLB/DMA configuration in the leatest reference design. So an address of OFDM_TXRX_MIMO_RXPKTBUFFER_BASEADDR+48 is legal; OFDM_TXRX_MIMO_RXPKTBUFFER_BASEADDR+36 is not. This works in your case, since you'll allocate 48 bytes to the header.
Offline
(note that my comments here are not inclusive of Patrick's post... you'll still need to deal with those)
You can definitely add new elements to the Macframe struct. There is a one-to-one mapping of struct elements to bytes in the header. This mapping takes place in warpmac_sendOfdm and the reverse mapping takes place in rxPhyGood (the RX interrupt handler). You need to tack on the additional bytes to that header vector and map them appropriately to your new struct elements. Additionally, you will no longer be able to use the mimo_ofdmTx_copyPayload macro, since it is hardcoded to 24 bytes. You can just replace that macro with a modified version of the underlying call. So you would want to replace the copyPayload macro with
memcpy(OFDM_TXRX_MIMO_TXPKTBUFFER_BASEADDR+48,(src),(len))
where 48 used to be 6*sizeof(int)=24.
Offline
Thank you for the piece of information!
However, I would request you to please shed some light on how to use the option 'b', mentioned in the first posting? Do I do a malloc in ethernet_callback() so that each time a packet is received from the ethernet , the original packet is copied and the new header added and finally txBuffer->data is made to point to this new "malloced" location ? I was wondering if this can cause some problems... Is there any other method to achieve the same objective?
Offline
There is no dynamic memory allocation in the new WARPMAC. A single Tx buffer is allocated at compile time; this buffer is required for the reasons discussed in this thread.
As long as you adhere to the requirements Chris and I mentioned above, you can certainly implement the changes you described. You will need to dig into the WARPMAC code to see how memcpy and the Ethernet FIFO functions are used to construct/deconstruct packets; there is no function in place that will do all of this for you.
Offline
I tried to use option 'a', made changes wherever was mentioned in your earlier posts. In particular,
1. Changes in void warpmac_sendEthernet(Macframe* packet) in warpmac.c
2. Changes in void rxPhyGood(void *baseaddr_p) in warpmac.c
3. Changes in void rxPhyBad(void *baseaddr_p) in warpmac.c
4. Changes in int warpmac_sendOfdm(Macframe* packet) in warpmac.c
5. I have changed mimo_ofdmTx_copyPayload macro in ofdm_Tx_mimo.h in which the fact was used that header size is 24 bytes and made it 48 bytes.
However, all the packets on the receiver side end up in rxPhyBad i.e. none of the packets received are good. Could you suggest what could be the problem? Thank you.
Offline
You're the first to attempt to modify the structure of the MAC frame, so I can't offer too much specific advice. I'd suggest digging into the code to trace the full path of a packet, from Ethernet reception all the way to OFDM transmission. Also check that you updated every instance in the code where the number of bytes in the packet is used, especially in setting the PHY paramters (the ofdmTx calls).
Offline
I am unable to find the reason why all the packets received were bad, when I changed the header size,in spite of all the changes made [Kindly refer to my last post]. Could you also please look into this problem at your end? Thank you.
Offline
I am trying to build up a kind of protocol stack. Therefor I need to add a second header between the macframe-header and the payload before sending it. Unfortunately I don't know how, since I'm not really understanding how the dma works and at which point I have to insert my new header.
Toolbox, it seems that you tried to do the same. Do you succeeded? Can you tell me how or at least at which point you arrived?
Thanks,
Offline
You can use the reserved bytes in the exsiting phyHeader struct without any other code changes. If you need additional bytes, you will need to extend the header. The header must be a multiple of 12 bytes long (each base rate OFDM symbol is 12 bytes, and the header must occupy an integral number of base rate OFDM symbols). See the OFDM frame format documentation for more details.
Offline