gwesp wrote on Thursday, October 12, 2017:
Hi,
We’re trying to add TCP and UDP to a project. We noticed that there are huge differences in files that are required
for both, e.g. FreeRTOS_DHCP.c, including differing function signatures.
How can we resolve this situation? Is the combination of UDP and TCP supported or can you use only one
of both?
We’re evaluating FreeRTOS version 9.0.0.
Thanks and kind regards
–Gerhard Wesp
KISS Technologies GmbH
rtel wrote on Thursday, October 12, 2017:
The FreeRTOS+TCP stack available from the labs download (or the FreeRTOS
SVN repository) has both TCP and UDP. Take a look at the features list
and API in the tables at the bottom of the following page:
http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/index.html
gwesp wrote on Thursday, October 12, 2017:
Thanks for your quick reply. I see I wasn’t specific enough in my description.
We’re currently targetting the LPC1830 Xplorer board. For this, we use the example from
FreeRTOS-Plus/Demo/FreeRTOS_Plus_UDP_and_CLI_LPC1830_GCC from FreeRTOSv9.0.0 .
This works very well, but it doesn’t include TCP.
Now when we add the FreeRTOS+TCP stack (I downloaded version 160919_FreeRTOS_Labs)
you mentioned, I see now that it does indeed include UDP as well. Still, we cannot use it
for the LPC1830 example above because some files are duplicate and have huge diffs. One
example is:
diff ./160919_FreeRTOS_Labs/FreeRTOS-Plus/Source/FreeRTOS-Plus-TCP/FreeRTOS_DHCP.c ./FreeRTOSv9.0.0/FreeRTOS-Plus/Source/FreeRTOS-Plus-UDP/FreeRTOS_DHCP.c
[ --> results in ca 1000 diff lines, including changed function prototypes ]
The question is how to resolve these ‘merge conflicts’. Any suggestions would be greatly
appreciated.
Actually, for the time being we’d be fine with TCP alone but we need it on the LPC1830.
Thanks and kind regards
–Gerhard Wesp
KISS Technologies GmbH
rtel wrote on Thursday, October 12, 2017:
The UDP and TCP products are different (or, at least, the TCP product is
an extension of the UDP product that is now different) - remove all the
FreeRTOS+UDP code and add the FreeRTOS+TCP code - then you will have
both UDP and TCP.
heinbali01 wrote on Thursday, October 12, 2017:
Hi Gerhard, once upon a time, there was FreeRTOS_Plus_UDP. This library could only do UDP, DHCP and ICMP(echo).
A couple of years ago, this stack was re-engineered and extended with a few more protocols, and it was called renamed to FreeRTOS+TCP. The name +TCP is possibly misleading, it should have been called FreeRTOS+UDP+TCP+DHCP+ICMP+FTP+HTTP+NBNS+LLMNR+etc 
In other words, what you should do is forget about the FreeRTOS_Plus_UDP, and work with FreeRTOS+TCP.
The two stack use the same principles, and they have the same kind of interface. Both stacks use a single IP-task that does all the work.
When working with FreeRTOS+TCP, start simple. Disable DHCP at first and give your device a fixed IP address. Try to ping it, and when that works, try DHCP and other protocols.
When you have questions, please post them here, in this thread.
gwesp wrote on Friday, October 13, 2017:
Thanks Hein,
that sounds like a plan. Since the API closely resembles the BSD sockets, I suppose we can
do what RTE suggested and just replace-merge the FreeRTOS+TCP files into the LPC1830 example.
Best
–Gerhard
heinbali01 wrote on Friday, October 13, 2017:
just replace-merge the FreeRTOS+TCP files into the LPC1830 example
Right, remove the entire UDP stack, and include the +TCP stack.
I will attach the current driver for LPC18 here below ( see LPC18xx_2017_oct.zip )
It is a zero-copy driver, so please add the following to your FreeRTOSIPConfig.h
#define ipconfigZERO_COPY_RX_DRIVER 1
#define ipconfigZERO_COPY_TX_DRIVER 1
A few parameters to tune are the following:
#define configNUM_RX_DESCRIPTORS 6
#define configNUM_TX_DESCRIPTORS 4
#define ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS 15
And later on, you may want to tune some TCP parameters, as describer here
The “quad” flash in the LPC18 that I used was a bit slow, and I placed some frequently-used functions in RAM:
#ifndef configPLACE_IN_SECTION_RAM
#define configPLACE_IN_SECTION_RAM __attribute__ ((section(".ramfunc")))
#endif
/* Move func() to RAM: */
configPLACE_IN_SECTION_RAM void func()
{
}
The .LD file contains the .ramfunc entry, in the RamLoc96 section:
/* Main DATA section (RamLoc96) */
.data : ALIGN(4)
{
FILL(0xff)
_data = . ;
*(vtable)
*(.ramfunc*)
*(.data*)
. = ALIGN(4) ;
_edata = . ;
} > RamLoc96 AT>SPIFI_4MB
If you have a fast flash, there is no need to move code to RAM.
Good luck!
gwesp wrote on Friday, October 13, 2017:
Thanks a lot, Hein! We’ll definitely check that out. From our UDP example it didn’t appear that
we’re particularly CPU bound, but it’s always good to have options.
Best
–Gerhard
heinbali01 wrote on Sunday, October 15, 2017:
From our UDP example it didn’t appear that we’re particularly CPU bound
As you probably know, the Ethernet layer needs two components:
The EMAC is often an internal peripheral of the CPU. A PHY is an external component. The EMAC and PHY communicate through a high-speed bus, MDIO or a newer protocol.
Both FreeRTOS_Plus_UDP as well as FreeRTOS+TCP need a driver for these two components. This driver exists of a xxx/NetworkInterface.c file and some (modified) drivers provided by the chip manufacturer.
I recently started to split-up the PHY-driver and make a generic driver that should work on all boards. As soon as it is well-tested, I will publish it here on this forum.
gwesp wrote on Tuesday, October 24, 2017:
OK, let us know when you have any updates. We were able to integrate your network driver into our project with some minor modifications (Chip_ENET_Init() function takes two arguments) and now working on a driver for our PHY (DP83822 on our final target hardware). Thanks a lot.