Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training


FreeRTOS+TCP technical features

Posted by hwmaier on May 10, 2016

Great to see a TCP/IP stack wich is tightly coupled with an RTOS.

I tried to find information what features the +TCP stack has compared to other well known offerings.In particular does is support:

  • IPv6
  • Packet fragment reassembly
  • Delayed acknowledgement and Retransmission
  • Congestion control
  • Sliding TCP Windows
  • Round-trip time estimation
  • Flow control
  • Multiple interfaces (eg 2 MACs)

Are there any plans to support Wifi and 3G/4G modems as well?

FreeRTOS+TCP technical features

Posted by heinbali01 on May 10, 2016

Great to see a TCP/IP stack which is tightly coupled with an RTOS.


FreeRTOS+TCP is indeed built on FreeRTOS and it uses many of its features, notably the event groups and queues.

The status of the project: FreeRTOS+TCP has been ported to many platforms and it has been tested by many people. Today you will still find it in the freertos/labs section, but it is about to be moved to the standard FreeRTOS release. The labs release will then be upgraded to include multiple interfaces and IPv6.

Your questions:

  • Multiple interfaces (eg 2 MACs)
  • IPv6

As said it is in preparation, it is being tested right now! Pretty soon FreeRTOS+TCP will support multiple interfaces and multiple end-points. So you can also bind several different IP-addresses to a single interface. The basics of IPv6 will be implemented so you can find devices (Neighbor Discovery and Name Service protocols), and use UDP and TCP on top of IPv6.

  • Packet fragment reassembly

Not at the IPv4 level if that is what you mean. FreeRTOS+TCP stopped supporting fragmentation because it is rarely used now. The only useful case would be an IPv4 UDP server that sends fragmented packets which are larger than the MTU (which is not my favourite solution).

Another reason to use fragmentation used to be: a lack of RAM. But if your device has a very small amount of RAM, you can also decide to use a smaller MTU (smaller packets) and thus use smaller RAM buffers.

The TCP protocol doesn't need fragmentation, it reassembles all packets at the end-point. TCP was heavily tested through the internet: an MCU was serving interactive (Java Script) web-pages through an unreliable and low band-width ISP. We recorded all TCP data with Wireshark and analysed the conversations.

  • Delayed acknowledgement and Retransmission

That is for TCP: yes it does both

There is a small problem with "Delayed acknowledgement" and embedded applications: some devices have very little RAM and use a sliding window of 1 MMS, e.g. WIN=1460. Normally an OS will delay it's ACK to a single packet for 200 ms. These connections will therefore never get faster than 5 x 1460 bytes per second. FreeRTOS+TCP decided to make this delay considerably shorter than 200 ms, in order to increase the speed of TCP connections with low-RAM devices.

  • Congestion control

It has congestion control but it does not implement all recommendations that have been published in RFC's. We had to make a choice between small code and smart behaviour.

  • Sliding TCP Windows

Selectable, by default it has sliding TCP windows ( ipconfigUSETCPWIN = 1 ) As embedded devices often have small amounts of RAM, you can determine exactly how much RAM will be dedicated to network buffers and TCP-buffers, see FREERTOSSOWIN_PROPERTIES.

Every TCP socket has its own stream buffers. The socket advertises a WIN size to the other party, the stream buffer guarantees that space will be available to receive WIN bytes. The stream buffers are implemented as circular buffers (with head and tail pointers): bytes can be added or retrieved within any locking mechanism.

  • Round-trip time estimation

Yes it does, both for Sliding TCP Windows as well as non-sliding version. Time-outs will be doubled after a missing ACK. The "fast retransmission" mechanism is also implemented.

  • Flow control

Yes it does. You can either poll how many bytes can be written to a TCP socket ( TX space ), or you can call FreeRTOS_send() in a blocking way and test how many have actually been sent.

  • Are there any plans to support WiFi and 3G/4G modems as well?

I am using WiFi and a 4G modem indirectly: my laptop serves as a gateway for my embedded devices which are on a LAN. 3G/4G Modems are normally part of a router which often has LAN connections and/or WiFi. It shouldn't be too difficult to write a driver for WiFi (access point or station).

Two questions that you didn't ask:

  • Anti-hanging

There is a time between receiving a SYN and a successful call to FreeRTOS_accept(). The SYN will lead to the creation of a socket which is owned by the IP-task. Because nobody can close the socket, the IP-task will set a timer to give these anonymous sockets a maximum life time:

~~~~ /* Include support for TCP hang protection. All sockets in a connecting or disconnecting stage will time-out after a period of non-activity. */ #define ipconfigTCPHANGPROTECTION ( 1 ) #define ipconfigTCPHANGPROTECTION_TIME ( 30 ) ~~~~

The socket will be closed automatically if it doesn't reach the connected state with N seconds. Once it gets connected, it wait for the application to call FreeRTOS_accept().

  • Keep alive messages

As long as a TCP connection is idle, you can not be sure if the path (from end-point to end-point) is still valid. Maybe a NAT-router has been reset and the connection has in fact gone. Maybe you are waiting for an important TCP message which never comes, and you think that no news is good news :-)

When keep-alive messages are enabled, the path will be tested from time to time:

~~~~ /* Include support for TCP keep-alive messages. / #define ipconfigTCPKEEPALIVE ( 1 ) #define ipconfigTCPKEEPALIVE_INTERVAL ( 20 ) / in seconds */ ~~~~

Not every router will recognise or cooperate with keep-alive messages. If you write the source-code for both client and server, it is better to include AYA (Are You Alive) messages in the protocol.


FreeRTOS+TCP technical features

Posted by hwmaier on May 11, 2016

Wow, thank you. I am stunned by the comprehensiveness and quality of your answer. I suggest you add that information to an FAQ on the web site as it gives valuable information about the capabilities of FreeRTOS+TCP.

FreeRTOS+TCP technical features

Posted by kahe601 on January 6, 2017

is there any information on when the ipv6 protocol ist implemented into the stack?

FreeRTOS+TCP technical features

Posted by heinbali01 on January 6, 2017

Hi Karl,

You could have started a new topic for this.

What MCU or platform do you intend to use?

We are now testing a new release of FreeRTOS+TCP, called +TCP/multi/IPv6. For anyone who wants to use it, please contact us directly and we'll send you the source code.

The status is as follows:

+TCP/multi : this allows the use of multiple interfaces and multiple IP-addresses per interface. With IPv4, this is working well. +TCP/IPv6 : this allows the usage of both IPv4 and IPv6 packets. It has been tested on LAN's, both for TCP clients and servers.

Under construction: adding more IPv6 ICMP messages and functionality.

If you want to receive the source code of +TCP/multi/IPv6, please email: h point tibosch at freertos point org. We like to get in contact with more testers

FreeRTOS+TCP technical features

Posted by dnil-daniel on January 8, 2017


I'd like to follow up on the initial question in this thread regarding features on FreeRTOS+TCP. Having used FreeRTOS now on a few different projects, I'm impressed with the quality of the code and the performance of the OS. I've also tried FreeRTOS+TCP in one of these projects, though only for prototyping (TCP not part of final product). Looking forward I see a couple of projects needing FreeRTOS and a TCP/IP stack and the choices seems to be lwIP or FreeRTOS+TCP. Target MCUs are STM32F4/F7, and in this case quite a bit of glue code for lwIP on STM32 with FreeRTOS can be taken from STs work on STM32cubeMX.

The one feature I see a need for is PPP, related to the initial 3G/4G modem question. PPP is supported in lwIP, but I can't find much references to PPP support in FreeRTOS+TCP. I can tell there are some PPP stacks with "suitable" licenses I could port to FreeRTOS+TCP, but ideally I would like to avoid doing all that work on my own. Are there other companies interested in PPP support here?

PPP is mainly needed to integrate 2G/3G modems in the customer product. There are of course other ways to do that, like simply using the built-in TCP/IP stack on the modem which has a number of limitations though I'd like to avoid. More advanced integrations like CDC ethernet over USB or even the new USB MBIM profile likely requires even more integration work.

Thanks Daniel

FreeRTOS+TCP technical features

Posted by heinbali01 on January 23, 2017

Hi Daniel, Now that I read your recent post about the STM32F port, I found your earlier post here above. I'm sorry it stayed unanswered. I remember reading it, I did prepare an answer and then somehow got distracted by something else.

Are there other companies interested in PPP support here? PPP is mainly needed to integrate 2G/3G modems in the customer product

Although very interesting, at this moment these kind of protocols do not have our priority. I'm now mostly concentrated on the IPv6 and the multi-NIC extension. And also, I am re-evaluating the STM32F4 port.

If you start working on a new protocol, don't hesitate to write us, maybe we can make changes to the source code to facilitate your implementation. Regards.

FreeRTOS+TCP technical features

Posted by heinbali01 on March 31, 2017

And also, I am re-evaluating the STM32F4 port

For those interested, there is a new zero-copy driver for the STM32F4.

And secondly : a person called Arturo sent me an email from "Automation Control Co", but my SMTP's complain about the email address: "Unroutable address".

Arturo, if you're interested in using +TCP/multi, please write me again, using a different email address.

FreeRTOS+TCP technical features

Posted by medaver on April 12, 2017

Hello Hein,

We are currently running FreeRTOS+TCP+FAT on the SAMV71 platform.

We are interested in using/testing +TCP/multi and +TCP/ipv6. Is there a release date for these features?

We are also intereseste in PPP for 3G modem support. Are there any plan for implementing PPP?

Regards, Dave

FreeRTOS+TCP technical features

Posted by heinbali01 on April 13, 2017

Hi Dave, as I wrote elsewhere: if you email me ( h [point] tibosch [at] freertos [point] org ), I will send you the +TCP/multi/IPv6 release. Once that release is well-tested and stable, it will become public. There is no support yet for PPP, and I don't know if someone working on that.

FreeRTOS+TCP technical features

Posted by kenchang1 on April 19, 2017

If you want to receive the source code of +TCP/multi/IPv6, please email: h point tibosch at freertos point org. We like to get in contact with more testers

Dear Hein, I am interested in testing +TCP/multi, but I am still looking for a Zynq dev board with 2 eth PHYs. I am currently testing FreeRTOS+TCP with a MicroZed dev board and I am very happy with it. Any suggestions for dual eth Zynq boards? Best regards, Ken

FreeRTOS+TCP technical features

Posted by heinbali01 on April 20, 2017

Hi Ken Chang

but I am still looking for a Zynq dev board with 2 eth PHYs

I'm not sure why you want to use both EMAC's? The Zynq processor does have 2 EMAC's, but there are some limitations see e.g. here: http://zedboard.org/content/understanding-ethernet-zedboard

PS. I just posted a recent version of the Zynq driver here.

FreeRTOS+TCP technical features

Posted by kenchang1 on April 20, 2017

Hello Hein, For my application I need 2 EMAC's because I want to connect to 2 network devices at the same time. I am not using any network switches/routers. I have found a HW solution. I need the FMC carrier board + the quad ethernet FMC board from Opsero: https://opsero.com/product/robust-ethernet-fmc/ I will only use port 3 of this board, which is connected to the second EMAC (ETH1) of the Zynq. Best regards, Ken

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists