hwmaier wrote on Tuesday, 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:
Are there any plans to support Wifi and 3G/4G modems as well?
heinbali01 wrote on Tuesday, May 10, 2016:
Great to see a TCP/IP stack which is tightly coupled with an RTOS.
Thanks.
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:
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.
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.
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.
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.
Selectable, by default it has sliding TCP windows ( ipconfigUSE_TCP_WIN = 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 FREERTOS_SO_WIN_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.
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.
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.
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:
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 ipconfigTCP_HANG_PROTECTION ( 1 )
#define ipconfigTCP_HANG_PROTECTION_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().
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 ipconfigTCP_KEEP_ALIVE ( 1 )
#define ipconfigTCP_KEEP_ALIVE_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.
Regards.
hwmaier wrote on Wednesday, 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.
kahe601 wrote on Friday, January 06, 2017:
Hello,
is there any information on when the ipv6 protocol ist implemented into the stack?heinbali01 wrote on Friday, January 06, 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
dnil-daniel wrote on Sunday, January 08, 2017:
Hi,
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
heinbali01 wrote on Monday, 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.
heinbali01 wrote on Friday, 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.
medaver wrote on Wednesday, 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
heinbali01 wrote on Thursday, 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.
kenchang1 wrote on Wednesday, 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
heinbali01 wrote on Thursday, 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.
kenchang1 wrote on Thursday, 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
febe2 wrote on Wednesday, October 18, 2017:
Hi Dave,
Is it right, that you have a working FreeRTOS+TCP+FAT program which is running on SAM V71 platform?
I am already using FreeRtos+TCP with this network interface https://github.com/jtbr/FreeRTOS-TCP_SAMV71_NetIntf
but I have some troubles to use FreeRTOS +FAT.
Would it be possible for You to send me your basic program where TCP+FAT is working?
I hope you can help me?
Many thanks in advance
Felix