suggestion :
There is a need to start the IP task of +TCP :
static void prvIPTask( void * pvParameters )
Why ? because in my case I need to use a task to load in configuration. I need to be able to use TaskSuspend(handle) before starting the scheduler.
The problem : The IP task handle is private. I cannot access it (without modifying source)

suggestion : have a start parameter for FreeRTOS_IPInit ?
or ability to get the private handle via some fn call …

Why not just loading your configuration and FreeRTOS_IPInit afterwards ?
The IP task (handle) is an implementation detail and should not made public.
Which bigger problem do you want to solve ?

FreeRTOS_IPInit is called before the scheduler is started.

Hmm… and what about changing your init sequence matching your needs ?
That’s better than asking for FreeRTOS API changes to match your init sequence, right :wink:

For now you can add:

TaskHandle_t FreeRTOS_GetIPTaskHandle( void )
    return xIPTaskHandle;

into FreeRTOS_IP.c - we will do likewise in the upstream version.

See [Feature Request] Add a method to obtain the handle of the FreeRTOS+TCP IP task · Issue #549 · FreeRTOS/FreeRTOS · GitHub

[I actually created that ticket in the wrong repository as FreeRTOS+TCP has its own repo - I will move when the work is done.

Hi Richard, nice to hear from you again. Yes thanks, that would be my solution, exposure of private static via a function. I have tried out the IPv6-Multi port and it is very impressive - there are many more enhancements in the code I see than simply multi end point support. Great work in progress. I went back to the ‘main line’ that I am familiar with for the moment.

I have new projects and I have gone back to FreeRTOS from Linux.

If anyone needs assistance with their FreeRTOS+TCP Xilinx MPSoC Ultrascale port, I can probably help .

Hartmut , thanks for your interest. This project needs to get the whole device up in 1 second. This is a software defined radio based around a MPSoC, there is much hardware that must get initialized, and config has to be drawn early before partial reconfiguration. I have some good background to the inner workings of FreeRTOS+TCP from my work years ago.
Best Regards.

@glenenglish Ok - than you obviously know why and what you’re asking for :slight_smile:
Good luck !

@glenenglish, thanks for you suggestions, I put it into a new PR: #222.

About IPv6/multi:

yes it does have many new features, but in a regular project you won’t need most of the added functions.
There is even a macro that gives 100% downward compatibility: ipconfigCOMPATIBLE_WITH_SINGLE, you only have to include the new module “FreeRTOS_Routing.c”.

About the end-points: normally everything should work automatically. For instance, the following set of end-points is straightforward, i.e. mutually exclusive: // Local IP address with Gateway     // Local IP address
2001:510:da23::            // Public IPv6 address with Gateway
fe80::9355:69c7:585a:afe7  // local-link address

For every IP-address, the stack knows exactly which end-point to use:

end-point 1: 192.168.2.x and IPv4 gateway
end-point 2: 10.x.x.x
end-point 3: public IPv6 addresses
end-point 4: Link-local destinations

Here is more information about +TCP and multiple interfaces.
And here is some text about IPv6.
We also developed some demos for the WinSim project, which are described here.