Today, more and more systems go on-line. Just look at the tiny nanode covered earlier. Connectivity makes it easier to monitor remote sensors, implement home automation – as well as providing configuration and data read outs through a web interface.
When working with an embedded system, TCP/IP networking can feel intimidating. When working with FreeRTOS, however, it is easy to get started with an IP stack. You can even choose from two IP stacks – FreeTCPIP (based on uIP) and lwIP.
Network connectivity becomes more and more interesting as networks are more or less ubiquitous these days. It is not only a cheap feature that saves you from having to visit your board now and then to download sensor readings, update settings or other maintenance tasks. It can even be a cost reduction, if it lets you remove hardware for removable storage, physical interfaces, etc. From an device user standpoint, it is even better, as you can check if the device is alive and ok without physically visiting it.
FreeRTOS supports networking, and even comes with a set of networking examples. Looking at one of them, the Cortex STM32F107, built with GCC, we can learn how it basically works. This example is based on a modified version of uIP, by Adam Dunkels.
The big picture is that a FreeRTOS task is driving the uIP networking stack. It is run at the very highest priority. This is to ensure that the hardware buffers are emptied on time, so that the network traffic flows nicely.
As uIP is a part of the Contiki operating system, the handing of the actual web traffic is slightly different from what we are used to in FreeRTOS. Instead of consuming the data from a separate task, the UIP_APPCALL define (in webserver/webserver.h) provides a function to be called upon TCP/IP events. The webserver provided (webserver/httpd.c) relies on protothreads, i.e. a light version of co-routines, for its internal scheduling.
The webserver basically handles the technicalities of serving web pages over http. For configuration and monitoring, that can be of great interest. For smaller systems, it can be interesting to use more application specific, light-weight, protocols. In this case, it is basically a matter of overriding the UIP_APPCALL define and handle all communication yourself. The task driving uIP will still look very much the same.
When it comes to flexibility, it is interesting to see what uIP offers. As expected, it is possible to set an IP address, as well as a netmask. A MAC address is also specified. These settings are made at run-time, meaning that they can be user configurable.
In the configuration header file (webserver/uip-conf.h) the compile time settings are found. Here, the maximum number of simultaneous connections, maximum number of ports being listened to and the uIP buffer size can be set. In addition logging, statistics gathering and UDP can be enabled or disabled. For UDP, the usage of checksums can be enabled or disabled as well, thus making it possible to work without the computational effort that checksums implicate.
As you can see, the networking capabilities can be fine tuned. The examples provided gives you a web server, but with a lighter protocol and tighter configuration, you can make networking useful on even smaller devices.