FreeRTOS-Plus TCP in TI c2000

Partners & Sponsors ARM
1

Hello, does anyone have an example with the freeRTOS-plus tcp stack on an f2838x microcontroller from texas instrument?

2

Hi @adrien,
Welcome to FreeRTOS community!

Currently there is no existing F2838x port in FreeRTOS-Plus-TCP. If you want, you can follow porting guide to create one by yourself. Feel free to contribute to the repo once complete porting.

Thanks!

3

Is the porting guide up to date? I cannot find px${port_name}_FillInterfaceDescriptor() function and others in the example provided in FreeRTOS-Plus-TCP/source/portable/NetworkInterface

4

Yes, it’s up-to-date.
Take pxSAM_FillInterfaceDescriptor() as example.

5

I don’t understand when ulTaskNotifyTake is notify in porting guide Porting TCP/IP Ethernet drivers to a different MCU (freertos.org)

6

Hi @adrien,
Take DriverSAM as example again. There is a task called EMAC created in prvSAM_NetworkInterfaceInitialise(). In that task, it waits for notification by calling xTaskNotifyWait(). And the notifier is RX path triggered by HW interrupt.

  • Call flow: GMAC_Handler() → gmac_handler() → xRxCallback() → xTaskNotifyFromISR()
7

Hi mybe it can help,
this is a port of a Ti mcu(msp432e), derived from the port written by jscott for the Ti tm4c.
Maybe are the “Ti driverlib” similar to this one

The driver in question not perfect but it works

8

Hi, for me it is not clear how i have to Notify the IP stack on (PHY) linkup/down events

9

Hi @esr,
Please refer to NXP1060 driver. It sends networn down event to IP stack when it finds the interface is down.

At the begining of IP task, it also triggers network down events to initialize network interfaces.

Thanks.

10

hello, I managed to make a Basic Network Interface Port Layer. I can communicate with an http server on freertos. But after a while freeRtos gets stuck in portTASK_FUNCTION(prvIdleTask, pvParameters)

11

Thank you,
for me still not clear what to do when link is returning up

12

Hi @adrien,
Sorry for late response. Could you provide more information about how you know it stuck in prvIdleTask? Do you define configASSERT to help catch error?

Thank you.

Hi @esr,
IMHO, FreeRTOS-Plus-TCP assumes interface is already up after calling initialization function of interface. We support NXP re-plug procedure in NXP1060. When ethernet is un-plug, it detects the cable connection status via polling message here then trigger network down event to IP task. Then IP stack re-init the interface by calling same network initialization function during down procedure to make it up again.

Thank you.

13

Hi,
In void vApplicationIPNetworkEventHook(eIPCallbackEvent_t eNetworkEvent) I see that FreeRTOS-Plus-TCP emit eNetworkUp even if no cable is plugged in. I thougth if, my driver can notify linkUp, this notification could be more “precise”.
Otherwise is only a “definition problem”; In my understanding FreeRTOS-Plus-TCP eNetworkUp says: stack and driver are ready to take connections and not we have an usable link/network.
Can you give me an explanation why is defined that way?

My driver is now capable to re-plug, The thing i had to do is make BaseType_t port_pfInitialise(NetworkInterface_t *_if) doing nothing and returning true if hardware is alredy setup.

14

Hi,
I’m not 100% sure but I believe that depends on use cases. In my experience, re-plug event is not that common on IoT devices for an application to know. I’m not against that idea, instead, we’d be super glad if you can help contribute that to our repo.

BTW, may I know your scenario? What does the application do when it gets re-plug ( eNetworkUp) event?

Thanks you.

15

I am still experimenting…
the main point is that the device can be used with cable and without. With cable the device is controlled with tcp and the device is the “server”, in this case I better wait on incoming TCP connection than on eNetworkUp. I am wondering how shoud i do if device is client and the controlling service is server, how is the best way to tell the device that is now time to connect to server? Polling?

16

Not sure if I got you completely.

FreeRTOS+TCP reports network up when DHCP finishes. If you’re using dynamic address, it makes sense to wait for that event like FreeRTOS_Plus_TCP_Echo_Posix does. But if you’re using static IP address, it’s not necessary to wait for network event because everything is configured when IP task is ready.

Do I answer your question? Or could you help elaborate more on your scenario?

Thank you.

17

It would still require an active internet connection i.e. the ability to communicate to the server, right? So you want to make sure that the network is up - and this should be same regardless of whether the device is server or a client. What problem are you trying to solve by polling?

18

Hello Adrien,
I’ve seen your previous discussions about porting the FreeRTOS-Plus-TCP stack to the F2838x series. I am currently undertaking a similar project and am keen to understand your experience with this process.

Were you successful in getting the FreeRTOS-Plus-TCP stack running on the f2838x? If so, I would greatly appreciate it if you could share any guides, resources, or tips that assisted you in this process?

19

When writing a new network interface, it is good to look at examples, for instance STM32Fxx or TM4C.

You can get help and advice here in this forum, just by opening a new post about your driver.

If you want to make your driver integrate with the +TCP repo, we will make sure that it has the same behaviour / properties as other existing drivers.

One of the first things you can do to start is write a PHY_read() and a Phy_write() function, include common/phyHandler.c (100 Mbps only), and initialise the PHY of your device.

Good luck

20

Adrien Cardinale wrote:

Is the porting guide up to date? I cannot find px${port_name}_FillInterfaceDescriptor() function and others in the example provided in FreeRTOS-Plus-TCP/source/portable/NetworkInterface

As you know, every application can have one or more interfaces, and every interface can have one or more endpoints.

A new interface can be installed by calling it’s px${port_name}_FillInterfaceDescriptor() function. That is a global function declared in the specific NetworkInterface.c source.

New endpoints can be added by calling FreeRTOS_FillEndPoint() or FreeRTOS_FillEndPoint_IPv6().

Every interface has three “methods”:

/* This function will be called upon initialisation and repeated until it returns pdPASS. */
NetworkInterfaceInitialiseFunction_t pfInitialise;

/* This function is supposed to send out a packet. */
NetworkInterfaceOutputFunction_t pfOutput;

/* This function will return pdTRUE as long as the PHY Link Status is high. */
GetPhyLinkStatusFunction_t pfGetPhyLinkStatus;

These must be provided by every interface. The function px${port_name}_FillInterfaceDescriptor() makes sure that the function pointers will be set to point to the proper interface.

The actual functions are declared static in the NetworkInterface.c

1 Like