I’m sorry that I kept silent for so long, but it’s summer holiday time here 🙂
The reason to have the pointer located before the network buffer is the zero-copy option for UDP. A UDP payload buffer can be translated to a network buffer and vice versa with these complementary functions:
toNetworkBuffer( void *pvBuffer )
t *pcNetworkBuffer_to_UDPPayloadBuffer( NetworkBufferDescriptor_t *pxNetworkBuffer )
You are right that for some platforms
, the extra 4 bytes in front of the network buffer are not essential. And so this declaration:
#define ipBUFFERPADDING ( 8u + ipconfigPACKET
may sometimes be replaced with:
#define ipBUFFERPADDING ( 4u + ipconfigPACKET
I don’t mind allowing
to get overridden by a new item called
if( ipconfigBUFFER_PADDING != 0 )
#define ipBUFFER_PADDING ipconfigBUFFER_PADDING
#define ipBUFFER_PADDING ( 8u + ipconfigPACKET_FILLER_SIZE )
The following code was introduced just to avoid an exception:
/* Here a pointer was placed to the network descriptor,
As a pointer is dereferenced, make sure it is well aligned */
if( ( ( ( uint32_t ) pucBuffer ) & ( sizeof( pucBuffer ) – 1 ) ) == 0 )
We were in doubt about either using the live test or use a
may also be called from user space, we decided to have the above test.
As Richard wrote, the “more than 4-byte” alignment is required by some DMA’s.
The extra 2 bytes
were indeed introduced to get a proper 32-byte alignment for all 32-bit fields in the IP- and protocol headers. Many EMAC’s have an option that says: “skip the first 2 bytes” (as you mentioned).
FreeRTOS+TCP is still being developed further: it will soon have the possibility to use IPv6 headers, and also allow for multiple interfaces (EMAC’s). We’re still looking for more users who want to test the new (still experimental) version.
If you want to use IPv6, the extra 4 bytes will also get a purpose: store the IP-type in case of a IPv4 packet.