Real Time Configuration for Embedded System

Real Time

A system is real time when timeliness is a dimension of correctness; that means a correct answer delivered late is the same as an answer that has never been delivered. Real-time systems abound in the real world. To a degree, all systems are real time, because they have real-world deadlines: an airline ticketing program needs to issue tickets before the plane leaves, for example.

Real-time systems that can tolerate missing an occasional deadline, with a reduction in

performance or quality of output, are known as soft real-time systems.

On a hard real-time system, a missed deadline has serious consequences: when a deadline is missed, a saw may cut at the wrong angle; or a flow-control valve may not close, resulting in flooding.

Getting the Patch

Get the patch by visiting http://www.kernel.org/pub/linux/kernel/projects/rt/ and

looking for a patch set that is close to the version of the kernel used in the project. The patch may apply to a version of the kernel close to what you have, but getting the matching kernel version ensures that the patch applies. The patch is available in two forms: one file that includes the entire patch and another file that has a patch per file in the kernel, called the broken-out patch set. You can put them in any directory; the example creates one to keep everything neatly in one place:

$ mkdir ~/rt-kerel

$ wget http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.5-rt22.bz2

$ wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.5.tar.bz2

Decompress the kernel, and apply the patch. The patch file is compressed, and the uncompress command sends the results to patch, which updates the files:

$ tar xjf linux-2.6.29.5.tar.bz2

$ cd linux-2.6.29.5

$ bunzip2 -c ../patch-2.6.29.5-rt22.bz2 | patch -p 1

(much output clipped)

patching file drivers/net/atl1c/atl1c_main.c

patching file drivers/net/atl1e/atl1e_main.c

patching file drivers/net/chelsio/sge.c

patching file drivers/net/rionet.c

patching file drivers/net/s2io.c

patching file drivers/net/tehuti.c

Now that the kernel is patched, run the configuration program to enable the real-time features:

$ make menuconfig

LatencyTOP

Latency is nearly impossible to find by inspection, because it involves the interplay between several applications contending for resources and how the hardware reacts. Intel’s Open Source Technology Center released a tool called LatencyTOP that does a great job of showing, in plain English, where latency is occurring in an application. In order to get this tool to work, you need to build the kernel with some hooks enabled; you also need a userland program. You can download and build the userland program by doing the following:

$ wget http://www.latencytop.org/download/latencytop-0.5.tar.gz.

$ tar xzf latencytop-0.5.tar.gz

$ cd latencytop-0.5

Now things get interesting, because this project doesn’t use autoconf, and the make file isn’t built for cross-compilation. A few problems are easy to fix. First, change occurrences of gcc to $(CC) so you can override the compiler:

%.o : %.c

$(CC) -c $(CFLAGS) $(XCFLAGS) $< -o $@

latencytop: $(OBJS) latencytop.h Makefile

$(CC) $(CFLAGS) $(OBJS) $(LDF) -o latencytop

Next, remove the use of pkgconfig by changing these lines

XCFLAGS = -W -g `pkg-config --cflags glib-2.0` -D_FORTIFY_SOURCE=2 \

-Wno-sign-compare

LDF = -Wl,--as-needed `pkg-config --libs glib-2.0` -lncursesw

to this. If glib isn’t installed with your toolchain (most toolchains include glib), that library must be cross-compiled and installed in the toolchain before you build the program:

XCFLAGS = -W -g -I/usr/include/glib-2.0 /

-I/usr/lib/glib-2.0/include -D_FORTIFY_SOURCE=2 -Wno-sign-compare

LDF = -Wl,--as-needed -lglib-2.0 -lncursesw

This program needs the wide character ncurses library. Most toolchains don’t have support for this built-in, and you need to compile it first. This shows version 5.7 being compiled; the version you use may be slightly different:

$ wget http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.7.tar.gz

$ tar xzf ncurses-5.7.tar.gz

$ mkdir ncurses-build

$ cd ncurses-build

$ BUILDCC=”gcc -D_GNU_SOURCE” \CC=arm-linux-gcc \LD=arm-linux-ld \CXX=arm-linux-g++ \../ncurses-5.7/configure --host=arm-linux --enable-widec \--prefix=/home/gene/x-tools/arm-unknown-linux-gnueabi\/arm-unknown-linux-gnueabi/sys-root

$ make

$ make install

--enable-wideec is necessary to build the wide-character support required by LatencyTOP’s build. The other bit of code that may be a little out of the ordinary sets BUILD_CC: without including the - D_GNU_SOURCE macro, this version of ncurses won’t build. This bug will likely be fixed in the version you download, but in case it isn’t, use this workaround. For your environment, you also need to change the installation prefix to match the system root or library directory for your toolchain. To test that this library was installed as you expected, use the following command to have GCC report that it can find the file:

$ arm-linux-gcc -print-file-name=libncursesw.a

/home/gene/x-tools/arm-unknown-linux-gnueabi/\

lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../\

arm-unknown-linux-gnueabi/lib/libncursesw.a

If GCC emits just the file name, it couldn’t find the library, and the make for latencytop will fail. After you install this library and fix the make file, you can build latencytop with this command:

$ CC=arm-unknown-linux-gnueabi-gcc DESTDIR=/path/to/rfs make make install

Of course, change CC and DESTDIR to match your environment. After it’s compiled, run latencytop as root with no arguments to get the ncurses-based interface.