There is a need to start the IP task of +TCP :
static void prvIPTask( void * pvParameters )
In SUSPENDED state
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 …
platform : ULTRASCALE MPSoC XILINX.
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
For now you can add:
TaskHandle_t FreeRTOS_GetIPTaskHandle( void )
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.
@glenenglish Ok - than you obviously know why and what you’re asking for
Good luck !
@glenenglish, thanks for you suggestions, I put it into a new PR: #222.
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:
192.168.2.100 // Local IP address with Gateway
10.2.0.12 // 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.