Is there any support for fragmented outgoing UDP datagrams? I see a #define in FreeRTOS IPCOnfig.h, but nothing more.

Hi Andrew,

In the earlier +UDP library ( freertos.org/udp ) there was limited support for fragmentation.

The define ipconfigCAN_FRAGMENT_OUTGOING_PACKETS is still seen in some comment in +TCP, but that should have been removed. Support for packet fragmentation was stopped because it adds a lot of complexity, and people use it rarely (we thought).

If your project only uses UDP you might want to consider using +UDP:

FreeRTOSVx.x.x/FreeRTOS-Plus/Source/FreeRTOS-Plus-UDP

Can you tell why fragmentation would be interesting or useful? What does your platform look like, CPU and memories?

Regards.

I will look at this source and try to merge it into what I have. The fragmentation of outgoing packets is a requirement. I am sure that I can't avoid it. We are transferring a large datagram that needs to be assembled by the listener as a single coherent datagram. The size will require a parsing into fragmented packets, since the largest MTU is 1500 bytes.

The hardware is a Xilinx Zynq with standard memory. (~0.5GB).

heinbali01,

Thanks.

Regards, Andrew

There is a problem with the +UDP code. Fragmented packets are not sent. This cause is that In the beginning of emacpssendmessage there is a call to xValidLength. This tests the pxNetworkBuffer-> xDataLength. The length is 0x5F8 when a fragmented packet is sent and the max is 0x5F2. The size pass to the IP task is 0x5CE. This is the paload plus the size of a IP header and a UDP header. Later another 28 is added for the size of the headers. I'm confused. Is the code trustworthy? The buffer is passed to the IP task via xStackTxEvent.pvData = pxNetworkBuffer; The headers are part of this, right? Why tell the emac HW an inflated length?

Never mind = It was an error in my code - thanks.