tcp/ip for tiva tm4c M4 products

Anyone aware of any ports of the freertos-plus-tcp for the TI tiva CCS compiler? I want to use the tcp socket apis on a tm4c1294 launchpad. It appears only the atsam4e and stm32f series are supported. Is that correct?

tcp/ip for tiva tm4c M4 products

I think there was somebody on the forum using a Tiva, but we don’t have any code ourselves. If you have FreeRTOS working on the board, and you have a working network driver, then instructions on stitching in FreeRTOS+TCP can be found here: http://www.freertos.org/FreeRTOS-Plus/FreeRTOSPlusTCP/FreeRTOSTCPPorting.html

tcp/ip for tiva tm4c M4 products

Within that link, it says that “Each MCU to which FreeRTOS+TCP is ported requires an Ethernet MAC driver. It is assumed this already exists and is known to work. ” The ethernet MAC driver for the tiva products would be tivaware. However, I can’t find where this specifies what is required of the the ethernet MAC driver. Is that because the functions are only called from the “network interface port layer”? In the example network interface.c file for the STM32 parts, there are several other functions defined. Where are prvNetworkInterfaceInput, vMACBProbePhy and others documented? Should I follow the online guide and only provide the init, and interfaceoutput functions? While also sending data via the sendeventstructtoiptask? Do I need a prvEthernetUpdateConfig() function? Thanks!

tcp/ip for tiva tm4c M4 products

There are only two dependencies between the FreeRTOS+TCP code and the Ethernet driver, that is, the Ethernet driver must provide two functions. The two functions are as per the following two bullet points:
  • The network interface port layer must provide a function called xNetworkInterfaceInitialise() that initialises the MAC driver.
  • The network interface port layer must provide a function called xNetworkInterfaceOutput() that sends data received from the embedded TCP/IP stack to the Ethernet MAC driver for transmission.
If those two functions are not provided then the code won’t link, as they will be undefined references. How those functions are implemented is up to you, but it is recommended to map them as closely as you can to functions that are already known to be working that perform similar functionality. The implementation of those functions will inevitably call other hardware specific function to do things like set up port pins, provide a clock to the MAC hardware, probe the PHY, etc., they are the other functions you are seeing. They are chip specific, and private to and only used internally by the driver – FreeRTOS+TCP does not need them to be defined and they can be anything that is required to make the driver work (and are nearly always provided for you by the chip vendor).