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.