FreeRTOS-Plus-TCP-multi with Zynq

Kernel
1

tom12sg wrote on Sunday, May 20, 2018:

Hi,

I downloaded the above “180222_FreeRTOS-Plus-TCP-multi.zip” which support multi-interface.
However, i have problem in building it with Zynq SDK such that it complain:
error: unknown type name ‘UBaseType_t’
error: unknown type name ‘BaseType_t’
…
I would think it maybe path setting in the C/++ building setting.
Is there any sample project that i can refer to. I have also downloaded the “160919_FreeRTOS_Labs.zip” as a referance, but due to custom board i have problem to load the project.
Which version of the SDK is this TCP-multi support? It seem to be a very old version, maybe 2013?

I have a custom board with 2 NIC, and i wish to pass data from 1 NIC to another on the same board, any help is please.

Thanks.

2

rtel wrote on Monday, May 21, 2018:

Those types are defined in the FreeRTOS headers, rather than the
FreeRTOS+TCP headers. Please post the compiler output that shows the
errors so I can see which file the errors relate to.

3

tom12sg wrote on Monday, May 21, 2018:

Attached is the complier output.
I have build FreeRTOS and verified that it is working fine before create sub-directory and load-in the related TCP files

4

tom12sg wrote on Monday, May 21, 2018:

re-attach of the complier output after do a clean build.

5

heinbali01 wrote on Monday, May 21, 2018:

Hi Tom, I just downloaded mentioned release and I also found that uncached_memory.c could not be compiled.

It needs these include, in this order:

    /* Standard includes. */

    /* FreeRTOS includes. */

    /* FreeRTOS+TCP includes. */

    /* Platform specific includes. */

Also I found that two Xilinx sources needed to #include FreeRTOS_Routing.h.

Please find attached tcp_multi_zynq_driver.zip, with adapted sources.

Sorry for this inconvenience. Please report back on how things go.

6

tom12sg wrote on Monday, May 21, 2018:

Hi,

Thanks for the prompt response and action!
I have recomplie with your attach changes and most of the compliation error are resolved.
However, i am still getting some errors which i believe is due to my FreeRTOSIPConfig.h setting that i have just copied from the window platform.
I attached my compliation error and the setting file, hopefully you can advice further.

Do you have a minmal FreeRTOSIPConfig.h file setting that i can use and get things going? My intention is no DHCP, no DNS, able to do ping from PC and from another interface adaptor on the same board. Able to do iPerf test.I am runing on Zynq.

Also, is there any samples that shows how to setup to use multiiple interface adaptor.

Thanks!

7

heinbali01 wrote on Monday, May 21, 2018:

If I had the time, I should compile the library with all combinations of flags. In my case, I both have ipconfigUSE_DNS and ipconfigUSE_NBNS enabled, so I didn’t notice the problem.

In FreeRTOS_UDP_IP.c, you should make this little change around line 67:

 #include "FreeRTOS_Routing.h"
 
-#if( ipconfigUSE_DNS == 1 )
+#if( ipconfigUSE_DNS == 1 ) || ( ipconfigUSE_NBNS == 1 )
 	#include "FreeRTOS_DNS.h"
 #endif
 
 /* The expected IP version and header length coded into the IP header itself. */

I attached the FreeRTOSIPConfig.h that I used for a Xilinx/Zynq project.

Note that ipconfigUSE_NETWORK_EVENT_HOOK, the application Network Event hook, is very useful. When it is called for the first time with eNetworkEvent == eNetworkUp, you can start the necessary TCP- and UDP-servers.

Note that in FreeRTOS+TCP/multi, the application hook will be called for every defined end-point.

#if( ipconfigMULTI_INTERFACE != 0 )
	void vApplicationIPNetworkEventHook( eIPCallbackEvent_t eNetworkEvent, NetworkEndPoint_t *pxEndPoint )
#else
	void vApplicationIPNetworkEventHook( eIPCallbackEvent_t eNetworkEvent )
#endif
	{
	}

Something about address binding: within FreeRTOS+TCP /multi, a port number can only be bound once. When binding a socket, the IP-address provided is ignored. So if you bind a socket to e.g. port number 5001, that server socket will receive connection requests from all interfaces. The function FreeRTOS_accept() will tell you which client is connecting to your server.

An equivalent in Berkeley sockets is to bind a socket to the IP-address 0.0.0.0.

	xBindAddress.sin_len = sizeof( xBindAddress );
	xBindAddress.sin_family = FREERTOS_AF_INET;
	xBindAddress.sin_addr = 0ul;
	xBindAddress.sin_port = FreeRTOS_htons( 5001 );	/* Bind to server port number. */

Regards,

8

tom12sg wrote on Monday, May 21, 2018:

Hi,

Thanks!
I tried your FreeRTOSIPConfig.h, but it seem there is still something missing:
a) function lUDPLoggingPrintf() is needed when ipconfigHAS_PRINTF is being (1), but i caannot locate it in all my downloaded achieve…
b) uxRand(), i found there is one such function defined in main.c under demo for Window_Simulator. Can it be use?

Attached is the new compliation error file.
I am wondering, if DHCP is enabled, will the stack auto switch to static IP after sometime if it cannot locate any IP address. I do not have DHCP server. (i think lwIP demo example is doing it this way).

Thanks again for you help!

9

heinbali01 wrote on Monday, May 21, 2018:

Hi Tom,

function lUDPLoggingPrintf() is needed when ipconfigHAS_PRINTF is being (1)

This is a function from a module called Common\Utilities\UDPLoggingPrintf.c, which was added to the FreeRTOS+TCP demo’s. As I made some changes to the module for ipconfigMULTI_INTERFACE, so I will attach the latest versions to this post.

uxRand(), i found there is one such function defined in main.c under demo for Window_Simulator. Can it be use?

Yes, as long as it generates ( pseudo ) random numbers, it is OK.
It would be good, if you can set it’s seed just after the device has started up. That saves lots of problems later on, while testing TCP. If uxRand() always returns the same series of numbers, the IP-stack won’t issue truly random port numbers, and the TCP sequence numbers will always start with the same values, which is not secure.

I am wondering, if DHCP is enabled, will the stack auto switch to static IP
after sometime if it cannot locate any IP address (i think lwIP demo example
is doing it this way).

Yes sure, when DHCP fails, you can choose to use either a fixed configured IP-address, or you start using “auto-IP” if ipconfigDHCP_FALL_BACK_AUTO_IP is defined. “auto-IP” assigns a Link Layer IP address in the range 169.254.x.x.

DHCP has an application hook ( see ipconfigUSE_DHCP_HOOK ), which let’s you decide what action to take:

			#if( ipconfigUSE_DHCP_HOOK != 0 )
				/* Ask the user if a DHCP request is required. */
				eAnswer = xApplicationDHCPHook( eDHCPPhasePreRequest, pxEndPoint->xDHCPData.ulOfferedIPAddress );
				if( eAnswer == eDHCPContinue )
			#endif	/* ipconfigUSE_DHCP_HOOK */

where eDHCPContinue means: accept the offer.

10

tom12sg wrote on Tuesday, May 22, 2018:

Hi Hein,

Managed to complied without error. Will be testing later.
Thank you.
Do you have any UDP Iperf test that i can include in for testing the throughput or shall i contact you offline?

Regards,
Tom
11

heinbali01 wrote on Wednesday, May 23, 2018:

Hi Tom, please find attached iperf_task_v3_0c.c and iperf_config.h.

At the host side, you will have to install “iperf3”. You will find examples of how to call “iperf3” in the source code, here attached.

Also attached iperf_config.h which defines some buffer sizes for high performance.

“iperf” does support UDP, and I started to implement it, but I haven’t tested it for a long time, so it probably won’t work as it is now.