heinbali01 wrote on Thursday, September 19, 2019:
What you want is certainly possible, I think, as long as you use the UDP protocol. You will need to make some modification to 2 network buffer functions.
I would recommend start using
BufferAllocation_2.c because it is more flexible regarding the buffer allocation. You can have buffers allocated with
pvPortMalloc(), while other Network Buffers could point to the shared video memory.
You will need a function that determines the origin of the memory, something like:
BaseType_t xIsVideoMemory( uint32_t ulAddress )
return ( ulAddress >= VIDEO_START ) && ( ulAddress < VIDEO_START + VIDEO_LENGTH )
Now when releasing a buffer, the driver knows exactly how to release the buffer. In case of a video buffer, it will be passed to the video processor / core.
if( xIsVideoMemory( ( uint32_t ) pxDescriptor->pucEthernetBuffer ) )
release_video_memory( pxDescriptor->pucEthernetBuffer - ipBUFFER_PADDING );
vPortFree( pxDescriptor->pucEthernetBuffer - ipBUFFER_PADDING );
As you have seen, each
NetworkBufferDescriptor_t has a pointer to the actual Ethernet data, called
This pointer always points to the first byte of the network packet, i.e. the Ethernet header:
EthernetHeader_t xEthernetHeader; /* 0 + 14 = 14 */
IPHeader_t xIPHeader; /* 14 + 20 = 34 */
UDPHeader_t xUDPHeader; /* 34 + 8 = 42 */
uint8_t ucVideoData[ 1472 ];
After these 42 bytes, the video data can be written.
xEthernetHeader starts at a 4-byte aligned address + 2 bytes. This extra 2-byte offset has to do with the strange length of an Ethernet header (14 bytes).
I would make a new
pxGetNetworkBufferForVideo(), which has an extra argument: the video buffer to be sent.
Remember that the buffer starts 10 bytes (
ipBUFFER_PADDING ) before the Ethernet header. In that space you will find a pointer back to the owning
It all sounds complex, but you will get through it.
I am curious to hear how that works for you, and also about the gained efficiency.
If you want you can also send code as an attachment to your post.