Chapter 9: Other RTOS Services

9.1 Introduction
A good real-time embedded operating system avoids implementing the kernel as a large,
monolithic program. The kernel is developed instead as a micro-kernel. The goal of the micro-
kernel design approach is to reduce essential kernel services into a small set and to provide a
framework in which other optional kernel services can be implemented as independent modules.
These modules can be placed outside the kernel. Some of these modules are part of special
server tasks. This structured approach makes it possible to extend the kernel by adding additional
services or to modify existing services without affecting users. This level of implementation
flexibility is highly desirable. The resulting benefit is increased system configurability because
each embedded application requires a specific set of system services with respect to its
characteristics. This combination can be quite different from application to application.

The micro-kernel provides core services, including task-related services, the scheduler service,
and synchronization primitives. This chapter discusses other common building blocks, as shown
in Figure 9.1.

Figure 9.1: Overview.

9.2 Other Building Blocks

These other common building blocks make up the additional kernel services that are part of
various embedded applications. The other building blocks include the following:
§ TCP/IP protocol stack,
§ file system component,
§ remote procedure call component,
§ command shell,
§ target debut agent, and
§ other components.

9.2.1 TCP/IP Protocol Stack

The network protocol stacks and components, as illustrated in Figure 9.2, provide useful system
services to an embedded application in a networked environment. The TCP/IP protocol stack
provides transport services to both higher layer, well-known protocols, including Simple Network
Management Protocol (SNMP), Network File System (NFS), and Telnet, and to user-defined
protocols. The transport service can be either reliable connection-oriented service over the TCP
protocol or unreliable connectionless service over the UDP protocol. The TCP/IP protocol stack
can operate over various types of physical connections and networks, including Ethernet, Frame
Relay, ATM, and ISDN networks using different frame encapsulation protocols, including the
point-to-point protocol. It is common to find the transport services offered through standard
Berkeley socket interfaces.

Figure 9.2: TCP/IP protocol stack component.

9.2.2 File System Component

The file system component, as illustrated in Figure 9.3, provides efficient access to both local and
network mass storage devices. These storage devices include but are not limited to CD-ROM,
tape, floppy disk, hard disk, and flash memory devices. The file system component structures the
storage device into supported formats for writing information to and for accessing information
from the storage device. For example, CD-ROMs are formatted and managed according to ISO
9660 standard file system specifications; floppy disks and hard disks are formatted and managed
according to MS-DOS FAT file system conventions and specifications; NFS allows local
applications to access files on remote systems as an NFS client. Files located on an NFS server
are treated exactly as though they were on a local disk. Because NFS is a protocol, not a file
system format, local applications can access any format files supported by the NFS server. File
system components found in some real-time RTOS provide high-speed proprietary file systems in
place of common storage devices.
Figure 9.3: File system component.

9.2.3 Remote Procedure Call Component

The remote procedure call (RPC) component allows for distributed computing. The RPC server
offers services to external systems as remotely callable procedures. A remote RPC client can
invoke these procedures over the network using the RPC protocol. To use a service provided by
an RPC server, a client application calls routines, known as stubs, provided by the RPC client
residing on the local machine.

The RPC client in turn invokes remote procedure calls residing in the RPC server on behalf of the
calling application. The primary goal of RPC is to make remote procedure calls transparent to
applications invoking the local call stubs. To the client application, calling a stub appears no
different from calling a local procedure. The RPC client and server can run on top of different
operating systems, as well as different types of hardware. As an example of such transparency,
note that NFS relies directly upon RPC calls to support the illusion that all files are local to the
client machine.

To hide both the server remoteness, as well as platform differences from the client application,
data that flows between the two computing systems in the RPC call must be translated to and
from a common format. External data representation (XDR) is a method that represents data in
an OS- and machine-independent manner. The RPC client translates data passed in as
procedure parameters into XDR format before making the remote procedure call. The RPC server
translates the XDR data into machine-specific data format upon receipt of the procedure call
request. The decoded data is then passed to the actual procedure to be invoked on the server
machine. This procedure's output data is formatted into XDR when returning it to the RPC client.
The RPC concept is illustrated in Figure 9.4.
Figure 9.4: Remote procedure calls.

9.2.4 Command Shell

The command shell , also called the command interpreter , is an interactive component that
provides an interface between the user and the real-time operating system. The user can invoke
commands, such as ping , ls , loader , and route through the shell. The shell interprets
these commands and makes corresponding calls into RTOS routines. These routines can be in
the form of loadable program images, dynamically created programs (dynamic tasks), or direct
system function calls if supported by the RTOS. The programmer can experiment with different
global system calls if the command shell supports this feature. With this feature, the shell can
become a great learning tool for the RTOS in which it executes, as illustrated in Figure 9.5.

Figure 9.5: RTOS command shell.

Some command shell implementations provide a programming interface. A programmer can

extend the shell's functionality by writing additional commands or functions using the shell's
application program interface (API). The shell is usually accessed from the host system using a
terminal emulation program over a serial interface. It is possible to access the shell over the
network, but this feature is highly implementation-dependent. The shell becomes a good
debugging tool when it supports available debug agent commands. A host debugger is not
always available and can be tedious to set up. On the other hand, the programmer can
immediately begin debugging when a debug agent is present on the target system, as well as a
command shell.

9.2.5 Target Debug Agent

Every good RTOS provides a target debug agent. Through either the target shell component or a
simple serial connection, the debug agent offers the programmer a rich set of debug commands
or capabilities. The debug agent allows the programmer to set up both execution and data access
break points. In addition, the programmer can use the debug agent to examine and modify
system memory, system registers, and system objects, such as tasks, semaphores, and
message queues. The host debugger can provide source-level debug capability by interacting
with the target debug agent. With a host debugger, the user can debug the target system without
having to understand the native debug agent commands. The target debug agent commands are
mapped into host debugger commands that are more descriptive and easier to understand. Using
an established debug protocol, the host debugger sends the user-issued debug commands to the
target debug agent over the serial cable or the Ethernet network. The target debug agent acts on
the commands and sends the results back to the host debugger. The host debugger displays the
results in its user-friendly debug interface. The debug protocol is specific to the host debugger
and its supported debug agent. Be sure to check the host debugging tools against the supported
RTOS debug agents before making a purchase.

9.2.6 Other Components

What has been presented so far is a very small set of components commonly found in available
RTOS. Other service components include the SNMP component. The target system can be
remotely managed over the network by using SNMP. The standard I/O library provides a common
interface to write to and read from system I/O devices. The standard system library provides
common interfaces to applications for memory functions and string manipulation functions. These
library components make it straightforward to port applications written for other operating systems
as long as they use standard interfaces. The possible services components that an RTOS can
provide are limited only by imagination. The more an embedded RTOS matures the more
components and options it provides to the developer. These components enable powerful
embedded applications programming, while at the same time save overall development costs.
Therefore, choose the RTOS wisely.

9.3 Component Configuration

The available system memory in many embedded systems is limited. Therefore, only the
necessary service components are selected into the final application image. Frequently
programmers ask how to configure a service component into an embedded application. In a
simplified view, the selection and consequently the configuration of service components are
accomplished through a set of system configuration files. Look for these files in the RTOS
development environment to gain a better understanding of available components and applicable
configuration parameters.

The first level of configuration is done in a component inclusion header file. For example, call it
sys_comp.h , as shown in Listing 9.1.
Listing 9.1: The sys_comp.h inclusion header file.

#define INCLUDE_TCPIP 1
#define INCLUDE_FILE_SYS 0
#define INCLUDE_SHELL 1
#define INCLUDE_DBG_AGENT 1

In this example, the target image includes the TCP/IP protocol stack, the command shell, and the
debug agent. The file system is excluded because the sample target system does not have a
mass storage device. The programmer selects the desired components through sys_comp.h.

The second level of configuration is done in a component-specific configuration file, sometimes

called the component description file. For example, the TCP/IP component configuration file could
be called net_conf.h, and the debug agent configuration file might be called the dbg_conf.h.
The component-specific configuration file contains the user-configurable, component-specific
operating parameters. These parameters contain default values. Listing 9.2 uses net_conf.h.
Listing 9.2: The net_conf.h configuration file.

#define NUM_PKT_BUFS 100

#define NUM_SOCKETS 20
#define NUM_ROUTES 35
#define NUM_NICS 40

In this example, four user-configurable parameters are present: the number of packet buffers to
be allocated for transmitting and receiving network packets; the number of sockets to be allocated
for the applications; the number of routing entries to be created in the routing table used for
forwarding packets; and the number of network interface data structures to be allocated for
installing network devices. Each parameter contains a default value, and the programmer is
allowed to change the value of any parameter present in the configuration file. These parameters
are applicable only to the TCP/IP protocol stack component.

Component-specific parameters must be passed to the component during the initialization phase.
The component parameters are set into a data structure called the component configuration
table. The configuration table is passed into the component initialization routine. This level is the
third configuration level. Listing 9.3 shows the configuration file named net_conf.c , which
continues to use the network component as the example.
Listing 9.3: The net_conf.c configuration file.

#include "sys_comp.h"
#include "net_conf.h"

#if (INCLUDE_TCPIP)
struct net_conf_parms params;
params.num_pkt_bufs = NUM_PKT_BUFS;
params.num_sockets = NUM_SOCKETS;
params.num_routes = NUM_ROUTES;
params.num_NICS = NUM_NICS;

tcpip_init(&params);

#endif

The components are pre-built and archived. The function tcpip_init is part of the component.
If INCLUDE_TCPIP is defined as 1 at the time the application is built, the call to this function
triggers the linker to link the component into the final executable image. At this point, the TCP/IP
protocol stack is included and fully configured.
Obviously, the examples presented here are simple, but the concepts vary little in real systems.
Manual configuration, however, can be tedious when it is required to wading through directories
and files to get to the configuration files. When the configuration file does not offer enough or
clear documentation on the configuration parameters, the process is even harder. Some host
development tools offer an interactive and visual alternative to manual component configuration.
The visual component configuration tool allows the programmer to select the offered components
visually. The configurable parameters are also laid out visually and are easily editable. The
outputs of the configuration tool are automatically generated files similar to sys_comp.h and
net_conf.h. Any modification completed through the configuration tool regenerates these files.

9.4 Points to Remember

Some points to remember include the following:
§ Micro-kernel design promotes a framework in which additional service components can
be developed to extend the kernel's functionalities easily.
§ Debug agents allow programmers to debug every piece of code running on target
systems.
§ Developers should choose a host debugger that understands many different RTOS
debug agents.
§ Components can be included and configured through a set of system configuration files.
§ Developers should only include the necessary components to safeguard memory
efficiency.
Chapter 10: Exceptions and Interrupts
10.1 Introduction
Exceptions and interrupts are part of a mechanism provided by the majority of embedded
processor architectures to allow for the disruption of the processor's normal execution path. This
disruption can be triggered either intentionally by application software or by an error, unusual
condition, or some unplanned external event.

Many real-time operating systems provide wrapper functions to handle exceptions and interrupts
in order to shield the embedded systems programmer from the low-level details. This application-
programming layer allows the programmer to focus on high-level exception processing rather
than on the necessary, but tedious, prologue and epilogue system-level processing for that
exception. This isolation, however, can create misunderstanding and become an obstacle when
the programmer is transformed from an embedded applications programmer into an embedded
systems programmer.

Understanding the inner workings of the processor exception facility aids the programmer in
making better decisions about when to best use this powerful mechanism, as well as in designing
software that handles exceptions correctly. The aim of this chapter is to arm the programmer with
this knowledge.

This chapter focuses on:

§ the definitions of exception and interrupt,
§ the applications of exceptions and interrupts,
§ a closer look at exceptions and interrupts in terms of hardware support, classifications,
priorities, and causes of spurious interrupts, and
§ a detailed discussion on how to handle exceptions and interrupts.

10.2 What are Exceptions and Interrupts?

An exception is any event that disrupts the normal execution of the processor and forces the
processor into execution of special instructions in a privileged state. Exceptions can be classified
into two categories: synchronous exceptions and asynchronous exceptions.

Exceptions raised by internal events, such as events generated by the execution of processor
instructions, are called synchronous exceptions. Examples of synchronous exceptions include the
following:
§ On some processor architectures, the read and the write operations must start at an even
memory address for certain data sizes. Read or write operations that begin at an odd
memory address cause a memory access error event and raise an exception (called an
alignment exception ).
§ An arithmetic operation that results in a division by zero raises an exception.

Exceptions raised by external events, which are events that do not relate to the execution of
processor instructions, are called asynchronous exception s. In general, these external events
are associated with hardware signals. The sources of these hardware signals are typically
external hardware devices. Examples of asynchronous exceptions include the following:
§ Pushing the reset button on the embedded board triggers an asynchronous exception
(called the system reset exception ).
§ The communications processor module that has become an integral part of many
embedded designs is another example of an external device that can raise asynchronous
exceptions when it receives data packets.