Abstract

This paper achieves the design of an embedded Web server,

which takes ARM920T-S3c241Os chip as its core and Linux as its
operating system. This is because Linux can be reduced and
transplanted. The method used to transplant Web server Boa on the
embedded Linux platform is also discussed in detail, and through CGI
technology functions of dynamic Web page is successfully realized.
Relevant experiments show that after the Web server is embedded
into the network video monitoring system, dynamic page interaction
can be achieved between the Web server and the embedded system
via the browser in the Windows environment.

The embedded system is a combination of computer hardware,

software and, perhaps, additional mechanical parts, designed to
perform a specific function. A good example is an automatic washing
machine or a microwave oven. Embedded systems need only the basic
functionalities of an operating system in real-time environment-a
scaled down version of an RTOS. They demand extremely high
reliability plus the ability to customize the OS to match an application's
unique requirements. However, commercial RTOSes, while designed to
satisfy the reliability and configuration flexibility requirements of
embedded applications, are increasingly less desirable due to their
lack of standardization and their inability to keep pace with the rapid
evolution of technology. The alternative is: open-source Linux. Linux
offers powerful and sophisticated system management facilities, a rich
cadre of device support, a superb reputation for reliability and
robustness, and extensive documentation. Also, Linux is inherently
modular and can be easily scaled into compact configurations.

Keywords-embedded systems; linux; embedded Web server; Boa; CGl

1
1. CRITICAL REVIEW

With the rapid development of Internet information technology,

those field-bus and Industrial Ethernet which are of high-specialization
and high cost and are used in control areas are gradually being
replaced by Ethernet [1]. Embedded systems and Internet technology
are combined to form a new technology - the Embedded Internet
Technology, which developed with the popularization of computer
network technology in recent years [2]. Without restrictions from
devices and systems, this technology could function in the hardware
and software as long as they are connected. Only by using web
browser through the Ethernet and TCPIP protocol can users get access
to various information [3]. It brings great convenience to remote video
monitoring and equipment management. The main advantages of
using embedded Web server mainly include: (1) the client can be
freely set and the browser can be used directly without installing
additional client software; (2) for the harmonization of Web standards,
it is possible to develop cross-platform transplantation; (3) the
operating system Linux, which can be reduced and transplanted,
provides a convenient, fast and simple method for embedded systems
and Internet access [4].

The term “embedded system” may be new to some of you and

require some explanation, even though you use embedded systems
every day of your life. Microwave ovens, TVs, cars, elevators, and
aircraft are all controlled by computers, which don’t necessarily have a
screen, keyboard, and hard disk. A computer could be controlling your
car without your knowledge: an engine management system takes an
input signal from the accelerator and provides outputs that control the
engine [6]. These computers are embedded in a system, of which they
may be only a small component. The embedded system designer may
have to work within tight constraints of size, weight, power
consumption, vibration, humidity, electrical interference, and above all,
cost and reliability. The PC architecture has been adapted for
embedded systems operation, and rugged single-board computers
(SBCs) are available from a wide variety of suppliers, together with the
necessary add-on cards to process real-world signals. The ultimate in
miniaturization is the microcontroller, which is a complete computer on
a single chip, including all the necessary I/O interfaces [7].

We will see first see the design of a web-server how small can a
Web server get? I already know the answer: there is a server on the
Web that claims to use only 256 bytes of read-only memory (ROM) for
its TCP stack, but I can't help thinking that this must be a highly
optimized chunk of assembly language, which is very difficult to adapt

2
for any practical use [8]. My objective is to create a miniature Web
server in C that is still potentially useful, in that it can monitor and
control real-world devices connected to the system's I/O lines. There is
little point in performing this exercise on the PC platform [9]

A microcontroller is a computer on a chip and is designed for

high-volume, low-cost applications. Microcontroller implementations
and their associated software development tools attempt to squeeze
the maximum capability from the simplest of hardware. To do this,
certain compromises have to be made, which makes the creation of
standard software tools very difficult or impossible [10], [11], [13],
[14], [15]. The C compiler writer faces two choices: either stick to the
standards, regardless, or adapt the C programming environment to
reflect the hardware constraints. The former approach, although
superficially attractive, can stretch the humble resources of the
microcontroller to the limit. A few lines of standard code can use up a
disproportionately large amount of the microcontroller's meager
resources [17], [21], [23], [24], [25]. For this reason, most
development environments are highly specific to the microcontroller
being used. To fit TCP into a microcontroller, you'll have to adapt your
thinking to reflect the quirks of the development tools and the
limitations of the hardware. Regrettably, the generic source code
approach must be sacrificed for the greater good of miniaturization.
The software in the next few chapters must be tied firmly to a specific
microcontroller and its associated development environment. That's
not to say that the techniques aren't equally applicable to similar
devices; it's just that there would be a significant amount of work to
adapt, or port, the code to another device[27].

Let us see what are the views of Alex Lennon regarding why we
should go for linux on top of ARM processor, Linux is an open-source
Unix-like kernel, that can be freely distributed under the ternis of the
GNU General Public License. (See the Links section for details of the
GNU project and the Open Source Initiative). It was developed initially
by the Finnish student Linus Torvalds, and had its first official release a
surprisingly long time ago in October 199 1 . Right from the beginning,
as is title case today, distributions of the Linux kernel have been
companied by GNU-developed utility programs to form a complete
operating system. Strictly speaking, the correct name for such
distributions is GNU/Linux, although GNU prefix is generally dropped in
the interests of brevity. Since its initial release the communications
infrastructure provided by the Internet has enabled large numbers of
developers to enhance and extend Linux, to the point where it can now
be seen as a mature alternative to operating environments such as
Windows and Unix. Linux is a multi-tasking, multi-user, multiprocessor
operating system supporting a wide range of hardware platforms, such

3
as x86, Alpha, Sparc, MIPS, SuperH, PowerPC and ARM. Where
hardware support is provided, the kernel makes use of protected-mode
memory management, increasing system reliability as one failing
application is unlikely to cause the kernel, or other applications, to fail
[29] [30]. One of the great strengths of the operating system is the
support for networking. This includes a large number of drivers for
network interface adaptors, and a complete implementation of TCP/IP
networking [31]. There are also drivers available for USB devices,
PCMClA cards, multimedia devices and many other types of hardware.
The typical Linux distribution comprises a wealth of software
resources. In addition to the kernel, it will include a basic Linux file
system, a desktop GUI, development and debugging tools and a
myriad of other open-source (distributed under the GPL) implications
and utilities Such is the enthusiasm of the Linux fraternity that,
whatever your requirements, there 15 likely to he a group working on a
project which will be useful to you-XM Java, wireless networking,
Bluetooth, network protocols, IPv6, home automation, remote data
acquisition and many more [38] [41].

Historically, Linux was developed specifically as an operating

system for desktop/server environment. More recently, there has been
a growing interest in tailoring Linux to the very different hardware and
software needs of the embedded applications environment. In
hardware terms, the minimum equipments of desktop Linux 7 compare
favorably with operating systems such as Windows and Solaris Red
Hat, a Linux distributor, suggests installation of an Intel 386 or above
for the CPU, a 1620 M-byte hard disk for a server, or 450 Mbytes for a
work station with 16 Mbytes of RAM A hardware footprint of this order
is entirely reasonable for a desktop PC [42] [43].

The ARM is a 32-bit reduced instruction set computer (RISC)

instruction set architecture (ISA) developed by ARM Holdings. It was
known as the Advanced RISC Machine, and before that as the Acorn
RISC Machine. The ARM architecture is the most widely used 32-bit ISA
in terms of numbers produced.[31][32] They were originally conceived
as a processor for desktop personal computers by Acorn Computers, a
market now dominated by the x86 family used by IBM PC compatible
computers. The relative simplicity of ARM processors made them
suitable for low power applications. This has made them dominant in
the mobile and embedded electronics market as relatively low cost and
small microprocessors and microcontrollers [44].

As of 2007, about 98 percent of the more than one billion mobile

phones sold each year use at least one ARM processor.[3] As of 2009,
ARM processors account for approximately 90% of all embedded 32-bit
RISC processors. ARM processors are used extensively in consumer

4
electronics, including PDAs, mobile phones, digital media and music
players, hand-held game consoles, calculators and computer
peripherals such as hard drives and routers [46].

The ARM architecture is licensable. Companies that are currently

or formerly ARM licensees include Alcatel, Apple Inc., Atmel, Broadcom,
Cirrus Logic, Digital Equipment Corporation, Free scale, Intel (through
DEC), LG, Marvell Technology Group, NEC, NVIDIA, NXP (previously
Philips), Oki, Qualcomm, Samsung, Sharp, ST Microelectronics,
Symbiosis Logic, Texas Instruments, VLSI Technology, Yamaha and
ZiiLABS [47]. ARM processors are developed by ARM and by ARM
licensees. Prominent examples of ARM Holdings ARM processor
families include the ARM7, ARM9, ARM11 and Cortex. Examples of ARM
processors developed by major licensees include DEC Strong-Arm, Free
scale’s i.MX, Marvell (formerly Intel) XScale, NVIDIA's Tegra, ST-
Ericsson Nomadik, Qualcomm's Snapdragon, and the Texas
Instruments OMAP product line [48].

The next step up the TCP/IP stack is TCP (transmission control

protocol). This isn't an easy protocol to implement; it has to perform a
multitude of tasks in pursuit of its ultimate objective: creating a
reliable connection between two points on the network This chapter
explores the elements of TCP, how they can be translated into
software, and how that software can be tested. I'll be creating my own
implementation of the general purpose TCP communications program,
TELNET.

Why is TCP so difficult? Fundamentally, it is trying to do several

jobs at once.

1. Initiate a connection between two nodes.

2. Send data bidirectional between the nodes.
3. Handle network datagram loss.
4. Handle network datagram duplication.
5. Handle out-of-order arrival of datagram’s.
6. Handle network failure.
7. Handle all data rates, from occasional single characters to bulk
transfer of large files.
8. Provide flow control to avoid data overload.
9. Provide the ability to hasten urgent data.
10. Close the connection between two nodes.
11. Support "half-closure," in which one participant wants to close, but
the other doesn't.
12. Handle datagram arrival after the connection is closed.

5
 To add to your problems, the situation between any two nodes
changes dynamically and very rapidly, so any failure situations can be
difficult to reproduce, making bugs hard to find and fix. The key to
creating a solid TCP implementation is to find a clear expression of the
underlying concepts and perform exhaustive testing. To help in this, I'll
include significant diagnostic capability in the code, with the ability to
deliberately generate errors, in order to analyze how the software
handles them [49], [50]

Boa is a single task Web server. The difference between Boa and
traditional Web server is that when a connection request arrives, Boa
does not create a separate process for each connection, nor handle
multiple connections by copying itself. Instead, Boa handles multiple
connections by establishing a list of HTTP requests, but it only forks
new process for CGr program. In this way, the system resources are
saved to the largest extent [9]. Like a common Web sever, an
embedded web server can accomplish tasks such as receiving requests
from the client, analyzing requests, responding to those requests, and
finally returning results to the client. The following is its work process.

There are many kinds of technologies such as COl, ASP, PHP JSP
and so on, which are used to achieve dynamic Web pages. If the
dynamic pages are to be realized under Linux operating system, COl is
preferred. COl [12](Common Gateway Interface) is a common interface
standard which is applied to interact between the application of
external expansion application and Web Server. COl provides the Web
server with a channel to implement external program. This service
technology makes browser and server interactive. COl is the program
consistent with these common interface standards and running on the
Web server. COl programs can be produced in any programming
language, for example, Shell scripting language, PerI, Fortran, Pascal
and C language and so on. The C language is chosen to write COl
programs in the present paper [51].

2. INTRODUCTION

With the rapid development of Internet information technology,

those field bus and Industrial Ethernet which are of high-specialization
and high cost and are used in control areas are gradually being
replaced by Ethernet [1]. Embedded systems and Internet technology
are combined to form a new technology - the Embedded Internet
Technology, which developed with the popularization of computer
network technology in recent years [2]. Without restrictions from
devices and systems, this technology could function in the hardware
and software as long as they are connected. Only by using web
browser through the Ethernet and TCP/IP protocol can users get access

6
to various information [3]. It brings great convenience to remote video
monitoring and equipment management. The main advantages of
using embedded Web server mainly include: (1) the client can be
freely set and the browser can be used directly without installing
additional client software; (2) for the harmonization of Web standards,
it is possible to develop cross-platform transplantation; (3) the
operating system Linux, which can be reduced and transplanted,
provides a convenient, fast and simple method for embedded systems
and Internet access [4].

3. OVERVIEW OF EXPERIMENTAL PLATFORM FOR THE

EMBEDDED WEB SERVER

The design in this paper applies S3C241Os32-bit ARM

microprocessor which takes ARM920T as its core. This microprocessor
has rich resources, including Clock, USB, SDRAM, UART, Nand Flash,
LCD, RS232 Interface, Ethernet Interface, JT AG, Power, etc. These
modules can help achieve Internet services. The logical structure of the
hardware is shown in Fig. l.

4. EMBEDDED WEB SERVER

A. The system diagram of Embedded Web server

The system structure of embedded Web server is shown in Fig. 2.

The entire system uses B/S mode. The client PC is connected to the
Internet through a browser and then gets access to the embedded
Web server. Through this way, remote login and operation are realized

7
[5]. Compared with the traditional C/S mode, this mode is simple to
use, convenient to maintain, and easy to extend.

B. The choice of Embedded Web server

Generally speaking, the embedded devices have limited resources

and don't need to handle the requests of many users simultaneously.
Therefore they do not need to use the most commonly used Linux
server Apache. Web server which is specifically designed for
embedded devices are applied in such case [6]. This kind of Web
server requires relatively small storage space and less memory to run,
which makes it quite suitable for embedded applications. The typical
embedded Web server has three kinds, namely https, Boa and thttpd
[7]. As the simplest Web server, https has the weakest functions
among the three. It does not support authentication and CGI
technology while Boa and thttpd support these functions [8]. If Web
server only provides some static web pages such as simple online
help and system introduction, then a static server can be adopted; if
you need to improve system security or interact with users such as
real-time status query and landing, then you have to use dynamic Web
technologies. In such situation, either Boa can achieve these goals. In
the present research, we adopt Boa, the Web server suitable for
embedded system, because it has less function and needs far more
resources to run.

8
C. The principle of Embedded Web server Boa

Boa is a single task Web server. The difference between Boa and
traditional Web server is that when a connection request arrives, Boa
does not create a separate process for each connection, nor handle
multiple connections by copying itself. Instead, Boa handles multiple
connections by establishing a list of HTTP requests, but it only forks
new process for CGI program. In this way, the system resources are
saved to the largest extent [9].Like a common Web sever, an
embedded web server can accomplish tasks such as receiving requests
from the client, analyzing requests, responding to those requests, and
finally returning results to the client. The following is its work process.

• Complete the initialization of the Web server, such as creating

an environment variable, creating socket, binding a port,
listening to a port, entering the loop, and waiting for connection
requests form a client.
• When there is a connection request from a client, Web server is
responsible for receiving the request and saving related
information.
• After receiving the connection request, Boa analyzes the
request, calls analysis module, and works out solutions, URL
target, and information of the list. At the same time, it processes
the request accordingly.
• After the corresponding treatment is finished, the Web server
sends responses to the client browser and then closes the TCP
connection with the client. For different request methods, the
embedded Web server Boa makes different responses. If the
request method is HEAD, the response header will be sent to the
browser; If the request method is GET, in addition to sending the
response header, it will also read out from the server the URL
target file of the client request and send it to the client browser;
If the request method is POST, the information of the list will be
sent to corresponding CGI program, and then take the
information as a CGI parameter to execute CGI program. Finally,
the results will be sent to client browser. Boa's flowchart is
shown in Fig. 3.

9
D. The creation of an embedded Web server
In the embedded Linux system, the creation of a Web server Boa
has the following steps:

10
1) Download the source code of Boa. The source code can be download
from http://www. boa.org [10].
2) Transplant the procedure of Boa. Decompress the downloaded
source code and lead it to enter "scr" subdirectory of the source
directory [11]:
#tar xzvf boa.tar.gz
#cd boa/src
Creat "Makefile" file:
#/configure
Modify "Makefile" file. Mainly modify the crosscompiler,
Find CC=gcc, change it into CC=armv41-
unknown-linux-gcc, save these changes and quit
"Makefile" file.
Specify the root directory path of Web server:
enter” boa/scr/" directory, and specify the absolute path of
root directory of the Web server by modifying the
statements which are in "defines.h" file.
#define SERVER _ ROOT"/mnt/yaffs/share/www/boa/http"
Then run "make" to compile, it will creat a file named
"boa" in the directory of "boa/src". This file shall be the
Executable file of Web server Boa.
3) Configure Boa so that it can support the implementation of
CGI
Programs. Boa requires establishing a boa directory in the root
file system "/mnt/yaffs/share/www”. A configuration file"
boa.conf' will be loaded when the boa boots. This file must be
edited before the boa program is running. There is already a
sample boa.conf in the Boa source directory. It can also be
modified on its basis. The following configurations need to be
changed: Port 80 //set the port of Web Oroup 0 //opening up the
restrictions on the user group
ErrorLog/mntlyaffs/share/www/boa/log/boa/error _log //set the
actual path of the error log Document
Root/mnt/yaffs/share/www/html //set the home directory of the
HTML file Script Alias/cgi-bini /mntlyaffs/share/www/cgi-bin /
/specify the actual path of the virtual path of the Col script
ScriptAlias/index.htmIl/mnt/yaffs/share/www/htmI/index.html//sp
ecify the actual path of the virtual path of the server's default
page
4) Test whether Boa can work normally, and whether the static
HTML pages can be visited normally. In this paper, NFS approach
is used to test. According to the configuration of boa.conf, we
copy the tested home page index.html into
"/mnt/yaffs/share/www" directory. The IP address of the board is
set to be 192.168.0.11S. We
enter"/mntlyaffs/share/www/boa/src" through mini com, and then

11
 run "./boa", and visit the following website: http://192.168.0.11S
on PC browser. Then we could see the pages of
"/mnt/yaffs/share/www/index.html". That means Boa works
normally in the embedded target systems.

After the daemon of Web server receives client requests, a child

process will be created. Then this child process will set relevant data
requested by COl as environment variables and meanwhile build two
data channels between external COl program and the server (standard
input/output). Then the COl program assigned by URL is started and
keeps pace with the child process in order to monitor the
implementation state of COI program. The result of disposition is
passed to the daemon of Web server through the standard output
stream by the child process. Then the processing results are reported
back to the client by daemon as a response message. A COl program is
usually divided into two parts. (1)Receive data from submission form
according to POST method or OET method. (2) Generate the HTML
source code by means of printfO function and then correctly return the
decoded data to the browser.

5. EMBEDDED SYSTEMS
5.1 History
The computers, which are used to control equipment, or
embedded systems, have been around for almost as long as
computers themselves. The word “computer” was not as ubiquitous
back then, and the stored program referred to the memory that held
the program and routing information. Storing this logic, instead of
hard-wiring it into the hardware, was a real breakthrough concept.
Today, we take it for granted that this is the way things work. These

12
computers were custom designed for each application. By today’s
standards, they look like a collection of mutant deviants, with strange
special-purpose instructions and I/O devices that were integrated with
the main computing engine. The microprocessor changed that by
providing a small, low-cost, CPU engine that could be used as a
building block in a larger system. It imposed a rigid hardware
architecture based on peripherals connected by a bus and provided a
general purpose-programming model, which simplified programming.
Off-the-shelf operating systems for embedded systems began to
appear in the late 1970s.Many of these were written in assembly
language, and could be used only on the microprocessor for which they
were written. When microprocessor became obsolete, so did its
operating system, unless it was rewritten to run on a newer
microprocessor. When the C language came along, operating systems
could be written in an efficient, stable and portable manner. This had
instant appeal to management, because it held the hope of preserving
the software investment when the current microprocessor became
obsolete. This sounded like a good story in a marketing pitch.
Operating systems written in C became the norm and remain so today.
In general, reusability of software has taken hold and is doing rather
nicely. A number of commercial operating systems for embedded
systems sprang to life in the 1980s. This primordial stew has evolved
to the present-day stew of commercial operating systems. Today,
there are a few dozen viable commercial operating systems from which
to choose. A few big players have emerged, such as VxWorks, pSOS,
Neculeus and Windows CE. Many embedded systems do not have any
operating system at all, just a control loop. This may be sufficient for
very simple ones; however, as systems grow in complexity, an
operating system becomes essential or the software grows
unreasonably complex. Sadly, there are some horribly complex
embedded systems that are complex only because the designers
insisted they did not need an operating system. Increasingly, more
embedded systems need to be connected to some sort of network, and
hence, require a networking stack. For simple embedded systems that
are just coded in a loop, adding a network stack may raise the
complexity level to the point that an operating system is desirable.
Linux as an embedded OS is a new candidate with some attractive
advantages. It is portable to many CPUs and hardware platforms,
stable, scalable over a wide range of capabilities and easy to use for
development.

5.2 Definition

As the name signifies, an embedded system is ‘embedded’ or

built into something else, which is a non-computing device, say a car,
TV, or toy. Unlike a PC, an embedded computer in a non-computing

13
device will have a very specific function, say control a car, or display
Web pages on a TV screen. So, it need not have all the functionality
and hence all the components that a PC has. Similarly, the operating
system and applications need not perform all the tasks that their
counterparts from the PC sphere are expected to. In short, we can
define an embedded system as a computing device, built into a device
that is not a computer, and meant for doing specific computing tasks.
These computing tasks could range from acquiring or transferring data
about the work done by the mother device to displaying information or
controlling the mother device. Embedded systems could thus enable
us to build intelligent machines. Embedded systems are not a new and
exotic topic that is still confined to research theses. There are many
live examples of embedded systems around us. MP3 players
(computing capability built into a music system), PDAs (computing in
what essentially is an organizer), car-control systems, and intelligent
toys are but a few examples of such systems already in place.

5.3 Features

Most embedded applications have little or nothing in common.

Yet there are several embedded system features that are commonly
required by systems many different, regardless of their target
applications. A comprehensive set of these enhanced features are
listed below.

Solid State Disk Support

True embedded systems often require extremely strong data

integrity and have rigorous specifications for power consumption,
weight, and immunity to adverse environmental conditions. These
requirements may prohibit the use of mechanical storage media such
as floppy and hard disk drives. Solid state disks provide all of the
functionality of magnetic drives, but feature extremely low power
consumption, very light weight, and high durability and data reliability.

Power Management

Low power consumption is one of the most common

requirements of embedded systems. This is particularly true of
portable and other battery-powered applications, which often must run
for extended periods of time on a single battery charge. Embedded
computer modules provide comprehensive BIOS support for both
automatic and manual power management operations. These features
allow dramatic power reductions to be achieved during periods of non

14
operation. Thermal monitoring and control is also offered on products
which require CPU thermal conditioning.

Watchdog Timer

Many mission-critical systems cannot tolerate the down time

resulting from crashes due to software problems, power fluctuations,
or other abnormal events. The Watchdog timer protects against fatal
stoppages by monitoring system operation and resetting in the event
of a failure.

Battery-Free Operation

Embedded computer modules employ a serial EEPROM chip to

store a backup copy of the CMOS RAM data. This eliminates any
vulnerability of configuration data to battery failure, which is a
common problem among desktop systems. Battery less operation also
allows products to be used in systems which may be exposed to
explosive environmental gases.

No-Fail Startup

Embedded computer modules employ various techniques for

assuring correct system startup even under adverse conditions. Years
of effort have gone into fine-tuning the BIOS to intelligently manage
Startup errors in case user intervention is not possible.

Instant-On Support

Many embedded systems are required to boot up and begin

processing within seconds of system power-up. This is much different
than desktop PCs, which commonly take a minute or more to reach a
fully operational state. Embedded computer modules provide
sophisticated capabilities for dramatically reducing startup delays.

Unattended Operation

Some types of embedded systems are designed to operate

unattended for weeks, months, or even years at a time with no user
intervention. Such embedded systems should be designed to allow
independent operation for extended periods of time.

5.4 Embedded versus General purpose systems

15
 An embedded system is usually classified as a system that has a
set of predefined, specific functions to be performed and in which the
resources are constrained. Take for example, a digital wrist watch. It is
an embedded system, and it has several readily apparent functions:
keeping the time, perhaps several stopwatch functions, and an alarm.
It also has several resource constraints. The processor that is operating
the watch cannot be very large, or else no one would wear it. The
power consumption must be minimal; only a small battery can be
contained in that watch and that battery should last almost as long as
the watch itself. And finally, it must accurately display the time,
consistently, for no one wants a watch that is inaccurate. Each
embedded design satisfies its own set of functions and constraints.
This is different from general purpose systems, such as the computer
that sits on a desk in an office. The processor running that computer is
termed a ”general purpose” processor because it was designed to
perform many different tasks well, as opposed to an embedded system
that has been built to perform a few specific tasks either very well or
within very strict parameters.

5.5 Real Time Embedded Systems

Embedded systems are often misclassified as real-time systems.

However, most systems simply do not require real-time capabilities.
Real time is a relative term. A real-time system (defined by IEEE) is a
system whose correctness includes its response time as well as its
functional correctness. In other words, in a real-time system, it not only
matters that the answers are correct, but it matters when the answers
are produced. In other words a real-time computer system can be
defined as a system that performs its functions and responds to
external, asynchronous events within a specified amount of time. Most
control and data acquisition applications, for example, fall into this
category. A Real time operating system is an operating system capable
of guaranteeing timing requirements of the processes under its control.
While time-sharing OS like UNIX strive to provide good average
performance, for a real-time OS correct timing is the key feature.
Throughput is of secondary concern. There are hard and soft real-time
systems depending on time constrains.

Soft real-time systems

Soft real-time systems are those in which timing requirements

are statistically defined. An example can be a video conferencing
system: it is desirable that frames are not skipped, but it is acceptable
if a frame or two is occasionally missed. The soft requirements are
much easier to achieve. Meeting them involves a discussion of context
switch time, interrupt latency, task prioritization and scheduling.

16
Context switch time was once a hot topic among OS folks. However,
most CPUs handle this acceptably well, and CPU speeds have gotten
fast enough that this has ceased to be a major concern.

Hard real-time systems

In a hard real-time system, the deadlines must be guaranteed.

For example, if during a rocket engine test this engine begins to
overheat, the shutdown procedure must be completed in time. Tight
real-time requirements should usually be handled by an interrupt
routine or other kernel context driver functions in order to assure Linux
in Embedded Systems consistent behavior. Latency time, the time
required to service the interrupt once it has occurred, is largely
determined by interrupt priority and other software that may
temporarily mask the interrupt. Hard real time means that the system
(i.e., the entire system including OS, middleware, application, HW,
communications, etc.) must be designed to guarantee that response
requirements are met. It doesn’t matter how fast the requirements are
(microsecond, millisecond, etc.) to be hard real time just that they
must be met every time. This means that every resource mechanism
(i.e., scheduler, I/O manager, mute mechanism, communications
mechanism, etc.) must select the work to be done in the correct order
to meet time constraint requirements. This means that mechanisms
(e.g., priority inheritance) must be provided to avoid unbounded
priority inversion (such as was encountered and corrected in the hard
real-time failure in the Mars Pathfinder). This means that FIFO queues
must be avoided or kept empty. This means that all processes and
threads, including those within the kernel must either be perceptible
(i.e., a high priority request can preempt a lower priority one). Hard
real-time functions in this tight time range are being implemented in
dedicated DSP (digital signal processor) chips or ASICs (application-
specific ICs). Also, these requirements are often simply designed out
through the use of a deeper hardware FIFO, scatter/gather DMA
engines and custom hardware. Embedded Hardware Embedded
system consists of hardware (typically VLSI or very large-scale
integrated circuits) specifically built for the purpose, an embedded
operating system, and the specific application or applications required.
The user interface could be push buttons, numeric displays, and LCD
panes and so on. One of the problems with building specific hardware
for each type of application is that for every new application you have
to literally start from scratch and reinvent the wheel. This increases
costs of the system as well as the time taken to develop one. But the
benefits of using standard PC components in embedded systems were
obvious. So, a method was developed to shrink the PC. What was done
was to make the PC bus smaller, and also make the cards stackable,
one on top of another, instead of connecting all cards to one big

17
motherboard, so that space is saved. The PC/104 standard, established
in 1992 defines the embedded PC. The specification is considered to be
an extension of the ISA bus specification. The PC /104 standard have
since been extended to
PC/104-plus to include the PCI bus. So, today you have PC-based
embedded systems that have the ISA bus, the PCI bus, or both. Unlike
with regular PCs, in the world of the embedded PC, 386s, 486s and
Pentiums are still good enough. Besides these, there are a number of
CPUs meant specifically for embedded applications, like the Strong
Arm, Motorola 68k family and the MIPS. An embedded system also
needs memory for two purposes – to store its program, and to store its
data. Unlike normal desktops, in which programs and data are stored
at the same place, embedded systems store data and programs in
different memories. This is simply because the embedded system
doesn’t have a hard drive and the program must be stored in memory,
even when the power is turned off. This special memory that
remembers the program, even without power, is called ROM or Read
Only Memory. Embedded applications commonly employ a special type
of ROM like Flash Memory that can be programmed or reprogrammed
with the help of special devices, unfortunately this kind of memory is
not fit for storing data, so embedded systems need some additional
regular memory for that function. Any additional requirement in an
embedded system is dependent on the equipment it is controlling.
Very often these systems have a standard serial port, a network
interface, input/output (I/O) interfaces like push buttons, numeric
displays, LCD panes or hardware to interact with sensors and
activators on the equipment. So an embedded system has a
microprocessor or micro controller for processing of information and
execution of programs, memory in the form of Flash memory for
storing embedded software programs and data I/O interfaces for
external interface. All these devices are hardwired on a printed circuit
board (PCB) .The functional diagram of a typical embedded system is
shown in figure. The processor uses the address bus to select a specific
memory location within the memory

18
Subsystem or a specific peripheral chip. The data bus is used to
transfer
data between the processor and memory subsystem or peripheral
devices. The control bus provides timing signals to synchronies the
flow of data between the processor and memory subsystem or
peripheral devices. With embedded PCs you can even go beyond the
single-function definition of an embedded system, and could build an
entire PC into another machine; a PC inside a refrigerator, or a PC
inside a car, for instance.

Embedded Processors

With so many applications, all major microprocessor

manufacturers are building their own embedded processors. Many
companies have started using existing microprocessor cores and
modifying them to suit embedded devices. AMD, for example, recently
introduced its AMD-K6-2E processor in two flavors for embedded
applications. These have gained support from industry players like
Lucent for its WAN/ VPN products line. Motorola has been a significant
player in the embedded processors field over the last couple of years.
They have the 68K cores at the low-end, Cold Fire in the midrange and

19
PowerPC for higher-end applications. Another contender for the market
share is Intel, who went the embedded way with its i960 processor,
based on 1.0 micron technology. The same team was then put into
developing the Strong-Arm, which is based on 0.18 micron technology.
This processor became quite popular, and found its way into devices
like the Compaq iPAQ pocket PC, HP Jornada handheld PC, mobile
phones and various digital imaging products.

5.6 Embedded Hardware

With the increase in interest and research of embedded systems

have come a flood of new design trends. It is hard to envision that five
years from now embedded systems will bear much resemblance to the
systems today, other than their basic functionalities and even those
may be replaced in the future. Two of the trends currently hot in the
embedded systems world that is discussed here are that of application
specific integrated circuits (ASICs) and systems on a chip (SOC).

Application Specific Integrated Circuits

As the title suggests, this is a IC that has been designed for a

specific application. In ASICs, the drawback is that they need heavier
investments and longer time spans to develop. Plus, they can’t be
customized later as the software instructions for them are put on a
ROM, which is difficult to modify. Examples of ICs that are ASICs are a
chip designed for a toy robot or a chip designed to examine sun spots
from a satellite .The reason for mentioning this is that since ASICs are
developed for a specific purpose, they are most likely constrained with
both a tight budget and a short time to market. Any and all methods
that might aid in the development of these chips would be welcomed
with open arms in the industry.

System -on- a-Chip

A system-on-a-chip offers all the functions of a computer, but

with a difference-all these features including a processor, chipset,
video encoder, graphics processor, super I/O, clock generator, and the
various buses used to interconnect, except the host memory of the
system, are integrated on a single silicon chip .This has the added
benefits of size reduction, power reduction, cost reduction, and high
performance. One of the more popular forms of SOC is that of Dave
Patterson’s Intelligent-RAM (IRAM). IRAM is the combination of a
processor on a chip with a large area of DRAM. Like all forms of SOC, it
reduces the number of chips in a system, allowing the product to be
smaller and less expensive. IRAM addresses the key bottlenecks in

20
many systems: memory bandwidth and memory latency. However, the
difficulties are: One, there is not so much area on a chip, and it puts
upper limits on the amount of main memory that you can have with a
system. Another large problem is that the design team creating the
system on a chip must contain all of the knowledge to create a
processor, a main memory, an I/O controller, and optimize all of them
together.

6. REAL TIME OPERATING SYSTEM AND EMBEDDING LINUX

Basic kernel services

In the discussion below, we will focus on the "kernel”? The part
of an operating system that provides the most basic services to
application software running on a processor. The "kernel" of a real-time
operating system ("RTOS") provides an "abstraction layer" that hides
from application software the hardware details of the processor (or set
of processors) upon which the application software will run. This is
shown in Figure1.

Figure

Figure 1: An RTOS Kernel provides an Abstraction Layer between

Application Software and Embedded Hardware

In providing this "abstraction layer" the RTOS kernel supplies five

main categories of basic services to application software, as seen in
Figure 2.

21
The most basic category of kernel services, at the very center of Figure
2, is Task Management. This set of services allows application software
developers to design their software as a number of separate "chunks"
of software – each handling a distinct topic, a distinct goal, and
perhaps its own real-time deadline. Each separate "chunk" of software
is called a "task." Services in this category include the ability to launch
tasks and assign priorities to them. The main RTOS service in this
category is the scheduling of tasks as the embedded system is in
operation. The Task Scheduler controls the execution of application
software tasks, and can make them run in a very timely and
responsive fashion. [Later, we will see the details of how this is done.]
The second category of kernel services, shown at the top of Figure 2, is
Inter task Communication and Synchronization. These services make it
possible for tasks to pass information from one to another, without
danger of that information ever
being damaged. They also make it possible for tasks to coordinate, so
that they can productively cooperate with one another. Without the
help of these RTOS services, tasks might well communicate corrupted
information or otherwise interfere with each other. Since many
embedded systems have stringent timing requirements, most RTOS
kernels also provide some basic Timer services, such as task delays
and time-outs. These are shown on the right side of Figure 2.
Many (but not all) RTOS kernels provide Dynamic Memory
Allocation services. This category of services allows tasks to "borrow"

22
chunks of RAM memory for temporary use in application software.
Often these chunks of memory are then passed from task to task, as a
means of quickly communicating large amounts of data between tasks.
Some very small RTOS kernels that are intended for tightly memory-
limited environments, do not offer Dynamic Memory Allocation
services. Many (but not all) RTOS kernels also provide a "Device I/O
Supervisor" category of services. These services, if available, provide a
uniform framework for organizing and accessing the many hardware
device drivers that are typical of an embedded system. [For more
information on this, please visit: the device drivers page at the
Kalinsky Associates Website] n addition to kernel services, many
RTOSs offer a number of optional add-on operating system
components for such high-level services as file system organization,
network communication, network management, database
management, user-interface graphics, etc. Although many of these
add-on components are much larger and much more complex than the
RTOS kernel, they on the presence of the RTOS kernel and take
advantage of its basic services. ach of these add-on components is
included in an embedded system only if its services are needed for
implementing the embedded application, in order to keep program
memory consumption to a minimum. n this paper, we will focus on the
basic RTOS kernel services for task management, inter ask
communication and synchronization, and dynamic memory Allocation.

6.1 Why Linux

Intelligent dedicated systems and appliances used in interface,

monitoring, communications, and control applications increasingly
demand the services of a sophisticated, state-of-the-art operating
system. Many such systems require advanced capabilities like: high
resolution and user-friendly graphical user interfaces (GUIs); TCP/IP
connectivity; substitution of reliable (and low power) flash memory
solid state disk for conventional disk drives; support for 32-bit
ultrahigh- speed CPUs; the use of large memory arrays; and seemingly
infinite capacity storage devices including CD-ROMs and hard disks.
This is not the stuff of yesteryear's "standalone" code, "roll-your-own"
kernels, or "plain old DOS". No, those days are gone -- forever! Then
too, consider the rapidly accelerating pace of hardware and chipset
innovation -- accompanied by extremely rapid obsolescence of the

23
older devices. Combine these two, and you can see why it's become an
enormous challenge for commercial RTOS vendors to keep up with the
constant churning of hardware devices. Supporting the newest devices
in a timely manner -- even just to stay clear of the unrelenting
steamroller of chipset obsolescence -- takes a large and constant
resource commitment. If it's a struggle for the commercial RTOS
vendors to keep up, going it alone by writing standalone code or a roll
your- own kernel certainly makes no sense. With the options
narrowing, embedded system developers find themselves faced with a
dilemma: On the one hand, today's highly sophisticated and
empowered intelligent embedded systems -- based on the newest
chips and hardware capabilities -- demand nothing less than the
power, sophistication, and currency of support provided by a popular
high-end operating system like Windows. On the other hand,
embedded systems demand extremely high reliability (for non-stop,
unattended operation) plus the ability to customize the OS to match an
application’s unique requirements. Here's the quandary: general
purpose desktop OSes (like Windows) aren't well suited to the unique
needs of appliance-like embedded systems. However, commercial
RTOSes, while designed to satisfy the reliability and configuration
flexibility requirements of embedded applications, are increasingly less
desirable due to their lack of standardization and their inability to keep
pace with the rapid evolution of technology.

6.2 What is developer to do?

Fortunately, a new and exciting alternative has emerged: open

source Linux. Linux offers powerful and sophisticated system
management facilities, a rich cadre of device support, a superb
reputation for reliability and robustness, and extensive documentation.
Best of all (say system developers), Linux is available at no charge
--and with completely free source code. Is Linux, like Windows, too
large and demanding of system resources to fit the constraints of
embedded systems? Unlike Windows, Linux is inherently modular and
can be easily scaled into compact configurations -- barely larger than
DOS -- that can even fit on a single floppy. What's more, since Linux
source code is freely available, it's possible to customize the OS
according to unique embedded system requirements. It's not
surprising, then, that open-source Linux has created a new OS
development and support paradigm wherein thousands of developers
continually contribute to a constantly evolving Linux code base. In
addition, dozens of Linux-oriented software companies have sprung up
– eager to support the needs of developers building a wide range of
applications, ranging from factory automation to intelligent appliances.

6.3 Which Linux?

24
 Because Linux is openly and freely available in source form,
there are many available variations and configurations. So, how do you
decide which distribution to use? That depends. First, realize that all
Linux distributions are variations on the same theme -- that is, they are
pretty much collections of the same basic components, including the
Linux kernel, command shells (command processors), and many
common utilities. The differences tend to center around which of the
many hundreds of Linux utilities have been included, what extras are
included, and how the installation process is managed. Even though
Linux is free, purchasing a "commercial" Linux distribution can have
many advantages. The many companies who are now building
businesses around distributing and supporting Linux are busy investing
in developing tools and services to differentiate their Linux offerings
from the pack. Some of the special capabilities being developed
include:
• Installation tools to automate and simplify the process of generating
a Linux configuration that is tuned to a specific target's hardware
setup.
• A variety of Windows-like GUIs to support a wide range of embedded
requirements.
• Support for the specific needs of various embedded and real time
computing platforms and environments (e.g. special Compact PCI
system features).

6.4 Embedded Linux Systems

Historically, Linux was developed specifically as an operating

system for the desktop/server environment. More recently, there has
been a growing interest in tailoring Linux to a very different hardware
and software needs of the embedded applications environment. In
practice, most embedded systems run from ROM or flash memory, and
a more typical footprint would be 386/486/586 or equivalent processor,
8-16Mbytes of ‘hard disc’ implemented as flash memory, and 16
Mbytes or more RAM. Since Linux provides both a basic kernel for
performing the embedded functions and also has all the user interface
bells and whistles you could ever want, it is very versatile. It can
handle both embedded tasks and user interfaces. Look at Linux as a
continuum: scaling from a stripped-down micro-kernel with memory
management, task switching and timer services and nothing else, to a
full-blown server, supporting a full range of file system and network
services. A minimal embedded Linux system needs just these essential
elements:
• a boot utility
• the Linux micro-kernel, composed of memory management,

25
 • process management and timing services
• an initialization process To get it to do something useful and still
remain minimal, you need to add:
• drivers for hardware
• one or more application processes to provide the needed
functionality
• As you add more capabilities, you might also need these:
• a file system (perhaps in ROM or RAM)
• TCP/IP network stack
• a disk for storing semi-transient data and swap capability

6.5 Real Time Operating Systems

Real-Time Operating Systems (RTOS) are commonly used in the

development, productizing, and deployment of embedded systems.
Unlike the world of general purpose computing, real-time systems are
usually developed for a limited number of tasks and have different
requirements of their operating systems. This section first gives the
requirements of real time operating systems, then how real time
performance is achieved in Linux, a general purpose operating system
(GPOS).

6.5.1 Real Time Operating Systems: the requirements

A good RTOS not only offers efficient mechanisms and services

to carry out real-time scheduling and resource management but also
keeps its own time and resource consumption predictable and
accountable. A RTOS is responsible for offering the following facilities
to the user programs that will run on top of it. The first responsibility is
that of scheduling: a RTOS needs to offer the user a method to
schedule his tasks. The second responsibility is that of timing
maintenance: the RTOS needs to be responsible in both providing and
maintaining an accurate timing method. The third responsibility is to
offer user tasks the ability to perform system calls: the RTOS offers
facilities to perform certain tasks that the user would normally have to
program himself, but the RTOS has them included in its library, and
these system calls have been optimized for the hardware system that
the RTOS is running on. The last thing that the RTOS needs to provide
is a method of dealing with interrupts: the RTOS needs to offer a
mechanism for handling interrupts efficiently, in a timely manner, and
with an upper bound on the time it takes to service those interrupts.
Several systems adopt POSIX.1b-1993 standard for real-time features
in UNIX. The standard defines prioritized scheduling, locking of user
memory ages in memory, real time signals, improved IPC and timers,

26
and a number of other features. Compliance with this standard makes
UNIX systems much more appropriate for real-time applications

6.5.2 Linux and Real Time

Many (if not all) embedded applications have some sort of real
time performance requirement. Many of these real-time requirements
prove to be”soft” - missing a deadline once in a while does not impact
the overall system viability. Even when ”hard” real-time deadlines do
exist, the scope of deterministic response can be reduced to the driver
level or overcome by the ”real-fast” performance offered by combining
Linux with Pentium and PowerPC silicon. So, when developers choose
to embed Linux to leverage the wealth of available networking,
database, and interface software, real-time concerns often take a back
seat. But should they? Using a GPOS, like Windows NT, for real-time
and embedded applications, can spell disaster - recall the U.S. Navy
has to tow their Aegis destroyers back to port, repeatedly, because of
crashed WindowsNT steering systems. A GPOS typically suffers from
several challenges to real-time applicability: determinism in general,
and response under load in specific. GPOS schedulers, optimized for
time-sharing, can induce unpredictably long blocking times; drivers
developed by a mix of GPOS-vendor engineers, peripheral-board
vendors, and other third parties add their own variable latencies.
Linux, developed for desktops and servers, is also a GPOS, but enjoys a
promising future in real time embedded designs. Two primary paths
exist to providing a real-time Linux: by inserting a second kernel into
the system, and by refining the standard Linux scheduler and tuning
Linux device drivers. The first approach, which has also been applied to
WindowsNT, presumes that to use Linux for real-time, you must
first”throw it out”. The addition of a second OS, regardless of its
putative real-time characteristics, vastly complicates both the
development and run-time considerations of the embedded Linux
developer. A much more sensible approach is to optimize the existing,
open Linux code base to address the needs of actual applications, but
first to characterize the performance of standard versions of Linux.
Before even attempting to enhance Linux responsiveness, it is key to
measure its real-time performance, thoroughly, in terms familiar to
real-time/embedded designers: worst-case interrupt latency, context
switch, and maximum blocking times. Linux already enjoys provably
superior compute and networking performance throughput, even when
compared to supposedly lightweight RTOS products, implying good to
excellent average response times, even under load. Developers, whose
requirements exceed such real-time characterizations in terms of the
Linux kernel itself, need not despair. Linux partially supports the
POSIX.1b standard. As of May 1, 1997, functions for the control of the
scheduler and memory locking are fully implemented in Linux, and

27
timers are partially implemented. The problems of kernel non-preempt
ability, low timer resolution, and high interrupt latency remains
unresolved. Thus, POSIX.1b compatibility only permits certain kinds of
soft real-time processing in Linux.

6.6 Embedding Linux

One of the common perceptions about Linux is that it is too

bloated to use for an embedded system. This need not be true. The
typical Linux distribution set up for a PC has more features than you
need and usually more than the PC user needs also. The standard
Linux kernel is always resident in memory. Each application program
that is run is loaded from disk to memory where it executes. When the
program finishes, the memory it occupies is discarded, that is, the
program is unloaded. In an embedded system, there may be no disk.
There are two ways to handle removing the dependence on a disk,
depending on the complexity of the system and the hardware design.
In a simple system, the kernel and all applications processes are
resident in memory, when the system starts up. This is how most
traditional embedded systems work and can also be supported by
Linux.

6.6.1 Scaling Linux

Traditional embedded operating systems go to great lengths to

tout the size and efficiency of their kernels. Realistically, viable
commercial OS configurations come in at 128-256 KB for a reasonably
configured kernel, another 100-200 KB for a TCP/IP stack and sockets
library, and for a web appliance, 50-150 KB for a HTTP server, plus a
minimum 64 KB of working RAM. An embedded system software profile
of 800 KB to 1 MB no longer looks gargantuan! These same vendors
point out that a desktop distribution of Linux runs into the hundreds of
megabytes. Well, they are right. When you embed Linux, you choose
only those components that make sense for your application. Don’t
need read/write file system? Don’t use it! The same logic applies to
networking, GUI, shells, and countless other utilities and libraries. If
your project does need more functionality than fits into local non-
volatile storage, you can craft either a tiny Linux boot loader, a stand-
alone bootable Linux system, or a slim Linux kernel that pulls down
additional modules and application code over a network, frequently in
500 KB or less!

6.6.2 Un-virtual Memory

Another feature of standard Linux is its virtual memory

capability. This is that magical feature that enables application

28
programmers to write code with reckless abandon, without regard to
how big the program is. This powerful feature is not needed in an
embedded system. In fact, you probably do not want it in real-time
critical systems, because it introduces uncontrolled timing factors. The
software must be more tightly engineered to fit into the available
physical memory, just like other embedded systems. On many CPUs,
virtual memory also provides memory management isolation between
processes to keep them from overwriting each other’s address space.
This is not usually available on embedded systems which just support a
simple, flat address space. Linux offers this as a bonus feature to aid in
development. It reduces the probability of a wild write crashing the
system. Many embedded systems intentionally use “global” data,
shared between processes for efficiency reasons. This is also
supported in Linux via the shared memory feature, which exposes only
the parts of memory intended to be shared.

6.6.3 The file systems- components

Many embedded systems do not have a disk or a file system.

Linux does not need either one to run. As mentioned before, the
application tasks can be compiled along with the kernel and loaded as
one image at boot time. This is sufficient for simple systems. In fact, if
you look at many commercial embedded systems, you’ll see that they
offer file systems as options. Most are either a proprietary file system
or an MS-DOS-compatible file system. Linux offers an MS-DOS
compatible file system, as well as a number of other choices. The other
choices are usually recommended, because they are more robust and
fault-tolerant. Linux also has check and repair utilities, generally
missing in offerings from commercial vendors. This is especially
important for flash systems which are updated over a network. If the
system loses power in the middle of an upgrade, it can become
unusable. A repair utility can usually fix such problems.

The file systems can be located on a traditional disk drive, on

flash memory, or any other media. Also, a small RAM disk is usually
desirable for holding transient files. Flash memories are segmented
into blocks. These may include a boot block containing the first
software that runs when the CPU powers up. This could include the
Linux boot code. The rest of the flash can be used as a file system. The
Linux kernel can be copied from flash to RAM by the boot code, or
alternatively, the kernel can be stored in a separate section of the flash
and executed directly from there. Finally, for networked embedded
systems, Linux supports NFS (Network File System).This opens the
door for implementing many of the value-added features in networked
systems. First, it permits loading the application programs over a
network. This is the ultimate in controlling software revisions, since the

29
software for each embedded system can be loaded from a common
server. This can be a very powerful feature for user monitoring and
control. For example, the embedded system can set up a small RAM
disk, containing files which it keeps updated with current status
information. Other systems can simply mount this RAM disk as a
remote disk over the network and access status files on the fly. This
allows a web server on another machine to access the status
information via simple CGI scripts. Other application packages running
on other computers can easily access the data. For more complex
monitoring, an application package such as MatLab can easily be used
to provide graphical displays of system operation at an operator’s PC
or workstation. Linux applications are usually linked to shared libraries.
These, just as their name implies, are libraries of functions that are
shared between applications and utilities.

The most frequently required shared library is C runtime

library(GLIBC)-around 4 Mbytes Luckily ,libraries can often be reduced
in size by removing all debugging information .However if this is too
large for your embedded system, it is possible to turn to less
standardized embedded libraries, for example uClibc and new lib.
Again, depending upon application requirements for a build of
embedded Linux, additional file system components will be needed.
For Java support, we may need to add JVM such as Kafee or IBM’s J9.

6.6.4 The file systems-high availability

An embedded Linux file system, unlike desktop or server

implementations, must offer user independent support for recovery in
the event of power failure. Also, power consumption, size and failure
rate considerations mean that the file system is likely to be running
from some variant of flash or ROM, rather than hard disc or other
rotating media. There are a number of alternatives when using flash
based storage media. Some flash devices connect to the standard hard
drive connector (IDE port) and emulate a hard disc drive. These are
extremely easy to use-requiring no changes to the kernel-but are
generally susceptible to corruption. An alternative is to use a ‘smart’
flash device such as Disc on Chip from M-systems. The Linux kernel
must be rebuilt to support this device, but, again depending on the file
system used, corruption can occur. Another is to make use of on-board
flash memory. As with Disc on Chip devices, drivers must be added to
Linux kernel -but there is the option of using the Journaling Flash File
System (JFFS), currently under devolvement within open-source
community. The 2.4 series of Linux kernels currently include support
for the JFFS.

30
 This is a ‘log structured ‘file system, which means that old data is
not lost when new data is written to flash. Periodically, this old
information is garbage collected from the flash, but write interruption
will not cause the file system to become corrupt. Work is also
underway to implement a compressed JFFS for embedded devices.

6.6.5 Booting

When a microprocessor first powers up, it begins executing

instructions at a predetermined address. Usually there is some sort of
read-only memory at that location, which contains the initial start-up or
boot code. In a PC, this is the BIOS. It performs some low-level CPU
initialization and configures other hardware. The BIOS goes on to
figure out which disk contains the operating system, copies the OS to
RAM and jumps to it. Linux systems running on a PC depend on the
PC’s BIOS to provide these configuration and OS-loading functions. In
an embedded system, there often is no such BIOS. Thus, you need to
provide the equivalent startup code. Fortunately, an embedded system
does not need the flexibility of a PC BIOS boot program, since it usually
needs to deal with only one hardware configuration. The code is
simpler and tends to be fairly boring. It is just a list of instructions that
jam fixed numbers into hardware registers. However, this is critical
code, because these values need to be correct for your hardware and
often must be done in a specific order. There is also, in most cases, a
minimal power-on self-test module that sanity-checks the memory,
blinks some LED’s, and may exercise some other hardware necessary
to get the main Linux OS up and running. This startup code is highly
hardware-specific and not portable.

6.7 Advantages and Disadvantages of Using Embedded Linux.

Although most Linux systems run on PC platforms, Linux can also

be a reliable workhorse for embedded systems. The popular ”back to-
basics” approach of Linux, which makes it easier and more flexible to
install and administer than UNIX, is an added advantage for UNIX gurus
who already appreciate the operating system because it has many of
the same commands and programming interfaces as traditional UNIX.
A fully featured Linux kernel requires about 1 MB of memory. However,
the Linux micro-kernel actually consumes very little of this memory,
only 100 K on a Pentium CPU, including virtual memory and all core
operating system functions. With the networking stack and basic
utilities, a complete Linux system runs quite nicely in 500 K of memory
on an Intel 386 microprocessor, with an 8-bit bus (SX). Because the
memory required is often dictated by the applications needed, such as
a Web server or SNMP agent, a Linux system can actually be adapted
to work with as little as 256 KB ROM and 512 KB RAM. So it’s a

31
lightweight operating system to bring to the embedded market.
Another benefit of using an open source operating system like
Embedded Linux over a traditional real-time operating system (RTOS)
is that the Linux development community tends to support new IP and
other protocols faster than RTOS vendors do. For example, more
device drivers, such as network interface card (NIC) drivers and
parallel and serial port drivers are available for Linux than for
commercial operating systems. The core Linux operating system, the
kernel itself has a fairly simple micro-kernel or monolithic architecture,
meaning the whole operating system-process management, memory
management, file system and drivers-is contained within one binary
image which is in compressed form. Networking and file systems are
layered on top of the micro-kernel in modular fashion. Drivers and
other features can be either compiled in or added to the kernel at
runtime as loadable modules. This provides a highly modular building
block approach to constructing a custom embeddable system, which
typically uses a combination of custom drivers and application
programs to provide the added functionality. An embedded system
also often requires generic capabilities, which, in order to avoid re-
inventing the wheel, are built with off-the-shelf programs and drivers,
many of which are available for common peripherals and applications.
Linux can run on most microprocessors with a wide range of
peripherals and has a ready inventory of off-the-shelf applications.
Linux is also well suited for embedded Internet devices, because of its
support of multiprocessor systems, which lends it scalability. This
capability gives a designer the option of running a real-time application
on a dual processor system, increasing total processing power. So you
can run a Linux system on one processor while running a GUI, for
example, simultaneously on another processor.

The one disadvantage to running Linux on an embedded system

is that the Linux architecture provides real-time performance through
the addition of real-time software modules that run in the kernel space,
the portion of the operating system that implements the scheduling
policy, hardware-interrupts exceptions and program execution. Since
these real-time software modules run in the kernel space, a code error
can impact the entire system’s reliability by crashing the operating
system, which can be a very serious vulnerability for real-time
applications.

6.8 Comparison with existing Embedded Operating systems

An off-the-shelf RTOS like QNX, PSOS, and VxWorks are designed

from the ground up for real-time performance, and provides reliability
through allocating certain processes a higher priority than others when
launched by a user as opposed to by system-level processes.

32
Processes are identified by the operating system as programs that
execute in memory or on the hard drive. They are assigned a process
ID or a numerical identifier so that the operating system may keep
track of the programs currently executing and of their associated
priority levels. Such an approach ensures a higher reliability
(predictability) with the RTOS time than Linux is capable of providing.
Also they have been designed from the ground up to conform to the
constraints of inherent in an embedded environment. Similarly, the
demands for real time performance were addressed during the initial
design phase. As a result, commercial non-Linux embedded operating
systems have tended to be more scalable at the low end and have
better real-time performance. However embedded Linux has now
evolved to the point where it can address, at low or zero cost, all but
the most demanding of embedded applications .The real time
performance issue can be important in the market, and embedded
Linux vendors are working hard to match the real time capabilities of
established products. Its future looks bright-the penguin has come of
the age.

6.9 Embedded Software

C has become the language of choice for embedded

programmers, because it has the benefit of processor independence,
which allows programmers to concentrate on algorithms and
applications, rather than on the detailed of processor architecture.
However, many of its advantages apply equally to other high-level
languages as well. Perhaps the greatest strength of C is that it gives
embedded programmers an extraordinary degree of direct hardware
control without sacrificing the benefits of high-level languages.
Compilers and cross compilers are also available for almost every
processor with C. Any source code written in C or C++ or Assembly
must be converted into an executable image that can be loaded onto a
ROM chip. The process of converting the source code representation of
your embedded software into an executable image involves three
distinct steps, and the system or computer on which these processes
are executed is called a host computer. First, each of the source files
that make an embedded application must be compiled or assembled
into distinct object files, Second, all of the object files that result from
the first step must be linked into a final object file called the re
locatable program. Finally, the physical memory address must be
assigned to the re locatable program. The result of the third step is a
file that contains an executable image that is ported on the ROM chip.
This ROM chip, along with the processor and other devices and
interfaces, makes an embedded system run. There are some very
basic differences between conventional programming and embedded
programming. First each target platform is unique. Even if the

33
processor architecture is the same, I / O interfaces or sensors or
activators may differ. Second, there is a difference in the development
and debugging of applications.

34
7. Applications

Embedded software is present in almost every electronic device

you use today. However, a common obstacle for developers has been
the need to develop different sets of hardware and software, for
different devices. An ’intelligent’ washing machine uses a hardware
chip different from that used by an ’intelligent’ wristwatch. In addition,
the software running on the hardware chip is different. This often
results in increased costs and time taken for development. Defense
services use embedded software to guide missiles and detect enemy
aircrafts. Communication satellites, medical instruments, and deep
space probes would have been nearly impossible without these
systems. Embedded systems cover such a broad range of products
that generalization is difficult. Here are some broad categories.

• Aerospace and Defense electronics (ADE)

• Automotive
• Broadcast and entertainment
• Consumer/internet appliances
• Data communications
• Digital imaging
• Industrial measurement and control
• Medical Electronics
• Server I/O
• Telecommunications

7.1 Linux and PDAs

In no area is this improvement more significant than for PDAs, a

market for which Linux currently seems stunningly appropriate. Here is
a market in which connectivity with desktop computers is important, so
mature and stable networking support is a necessity. The presence of
a GUI virtually defines what a PDA is, so good GUI support is also
important. Current retail prices for PDAs are in the low hundreds of US
dollars, a price range that allows designing in RAM, flash, and
processing power sufficient to support Linux well. On the other hand,
the market is sufficiently price sensitive that most manufacturers find
it onerous to pay even a token royalty to Microsoft or Palm for the use
of an OS. Yet using a low-end or home-brew OS, in an attempt to target
cheaper hardware, is simply out of the question –the market is moving
too fast for the longer design cycles that would result. In recent
months there have been numerous announcements of new Embedded

35
Linux support for PDAs and other handheld personal computing
devices. Additionally, a growing number of PDAs (and similar devices)
are known to be in development that will offer Linux as their primary
embedded operating system. They include Sharp Zaurus SL-5000
G.Mate Yopy, Empower Power Play III, HNT Exilien, SK Telecom
IMT2000Web Phone etc. In short, all signs now point to embedded
Linux, as a platform for today’s increasingly sophisticated PDAs.

8. EXPERIMENT RESULTS

We load each driver and start the Web server on an already

established experimental platform-S3c24 lOs. In client browser, we
input the corresponding IP addresshttp://192.168.0.11S/, and then the
Web page is opened which is as shown in Fig. 5
.

9. Conclusion

This embedded Web server is a separate module which can

provide a standard interface. With slight modifications it can be applied
easily to embedded fields such as on-site AC servo system, industrial
control, and intelligent appliances. Therefore, it has a wide range of
application prospects and great promotion value. The embedded Web
server designed in this paper is based on the ARM-Linux operating
system. It succeeds in

36
network video monitoring. The whole system has low-cost, good
openness and portability, and is easy to maintain and upgrade. The
Web server Boa selected in the present research requires small
storage space and occupies less memory when it's running. It also has
more functions and supports COL Communication between external
expansion applications and Web server can be achieved through Col
technology. This method can not only improve system security, but
also make it possible to interact with users and create dynamic Web
pages The developments of embedded systems have been fairly
dynamic over the past couple of years with the rapid digitization of
various parts of our day-to-day utility items. For example, in the
industrial segment the biggest turnaround came with the aircraft
industry adopting the fly-by-wire as a standard. This promulgated the
total automation of airplanes, which percolated further with the
digitization of cars, down to simple ignition systems that are used
today. The rapid development of industries has led to plant automation
across the world. Today robots do most of the welding and placing in
large factories. These robots are again powered by microprocessors
that tell them to fire the right sparks at the right place and the right
time. The possibilities in this field are only limited by our imagination.
Embedded developers are a flexible, forward-looking bunch, and
despite the need to reorient themselves technically, they are flocking
to Linux like penguins to their nesting ground. They are choosing Linux
for the technical advantages cited above, for its greater reliability, for
the comprehensive set of standard APIs, and to lower their cost of
goods sold, and bring their products to market faster.

10. Future Scope

The trend of embedded systems now involves the miniaturization

of electronics so that it can fit into compact devices. In the future these
systems will be moved by the forces of nature. Soon we will see more
digitization of appliances, and these will be fueled by human need.
Today when we lose our way, we have no better option but to ask
people for directions. However, we will soon be assisted by GPS and
pathfinders that will power cars and people alike. Looking into future,
we can see industries with automated time clocks, which will compute
with the back-end supply chain to decide on raw materials and
stocking. For several years, Linux advocates have predicted that Linux
will become a significant factor in the embedded market. In addition to
its virtues as a full-featured modern operating system, it is inexpensive
to duplicate, an especially important factor for embedded systems.
Time will tell, but it certainly looks as though Linux has already altered
the embedded and real-time operating system landscape in a
fundamental and irreversible way. Developers now have greater
control over their embedded OS; manufacturers are spared the costs

37
and headaches of software royalties; end users get more value. And
the penguins of the South Pole are celebrating.

11. LITERATURE SURVEY

[I] Wang Xianchun, Guo Jierong, Hu Weiwen, and Fan Xiping, "Design
and Implementation of Embedded Web Server Based on ARM and
Linux," Micro Computer Information, vol. 23(5-2),2007, pp. 164-165.

[2] Jacek W, "Embedded Internet technology in process control

devices," IEEE Internet Computing, Vol. 34, 2000.

[3] Douglas,” Engineering Web Technologies for Embedded

Applications," IEEE Internet Computing, May/June 1998.

[4] Wang Tianmiao, Publication: Embedded System Design and Case

Development. Beijing: Tsinghua University Press, 2002.

[5] Liu Yingshui, Xiao Zhengyu, and Sun Wei, "Embedded Web Server
Based on ARM and Linux," Microcontrollers & Embedded Systems, june
2007, pp. 14-21.

[6] Mi-Joung Choi, Hong-Taek lu, Hyun-Jun Cha, Sook-Hyang Kim, and
Won-Ki Hong, "An Efficient Embedded Web Server for Web-based
Network Element Management," International lourmal of Network
Management, Vol. 10, May 2000.

[7] Zhang Wenya., "Design and Implementation of Network Video

Monitoring System Based on Embedded Linux," Southwest Jiaotong
University Master Degree Thesis, May 2009, pp. 32-33.

[8] Li Weixuan, Zhao ling, Peng Zhicheng, and Xu Zhihao, "Research of

Remote Monitoring System Based on Embedded Web Server," AECC
Symposium, vol. 20, 2007, pp. 147-148.

[9] Liu Minying, "Design and Realization of a Remote Monitoring

System Based on Web ", Dalian Maritime University Master Degree
Thesis, May 2008. pp. 40 49.

[10] Zhao Huijuan, "The building of embedded Linux development

platform based on ARM9 and realization of Boa," Southwest Jiaotong
University Master Degree Thesis, Match 2008, pp. 57-59.

[11] R. Stones, and N. Matthew. Publication: Beginning Linux

Programming (2nd Edition). Endland: Wrox Press, 2003.

38
[12] 1. Dwight, M. Erwin, R. Niles, cm Development Handbook.
Machinery Industry Press.

[13]. Alex Lennon, “Embedding Linux”, IEE Review, pp. 33-37, May
2001.

[14]. Wayne Wolf, “Computers as Components-Principles of Embedded

Computing System Design”

[15]. Sumeet Kumar, “Delving Deeper into Embedded Systems”,

Information Technology Magazine, pp.13-16, October 2001.

[16]. Krishna Kumar, “Computers in your Toys, cars, appliance...”, PC

Quest Magazine,Pp.3-8, May 2001.

[17]. Joel R. Williams, “Embedding Linux in a Commercial Product”,

[18]. http://embedded.linuxjournal.com/articles/3587.php.

[19]. Rick Lehrbaum, “Using Linux in Embedded and Real-Time

Systems”,

[20]. http://embedded.linuxjournal.com/articles/3980.php.

[21]. S. Markon and K. Sasaki, “Linux for Embedded Systems ”,

[22]. http://embedded.linuxjournal.com/articles/0133.php.

[23] . Kevin Dankwardt, “Comparing real-time Linux alternatives”,

[24]. http://www.linuxdevices.com/articles/AT4503827066.html.

[25]. Rick Lehrbaum, “The Linux-PDA and PDA-Linux Quick Reference

Guide”,http://www.linuxdevices.com/articles/AT8728350077.html.

[26]. Sebastien Huet, “Embedded Linux

HOWTO”,http://linuxembedded. com/howto/Embedded-Linux-
Howto.html.

[27]. Stephen Balacco, “Linux's Future in the Embedded

SystemsMarket”,http://www.linuxdevices.com

39
[28] PHILIPS Co.Ltd. LPC2210/2214/2212/2214 User Manual. PHILIPS
Co.Ltd, 2004.

[29] Zhou Ligong. ARM Embedded System Basic Course, Beijing

University of Aeronautics and Astronautics Press, Beijing, China,
2005.5.

[30] Gan Ping LEE, Ming LEE. “Networked Intelligent Controller Based
on Embedded System”, The 30th Annual Conference of the IEEE
Industrial Electronics Society.

[31] Mo Chuanmeng, Feng Xiaoyu. “Double CAN communicating

building block based on embedded system μC/OS-II”. Micro computer
information, Beijing, China.Vol.20.3.2004, pp.83-85.

[32] Wang Junbo, Zou Jijun. “The Design of USB Bus and CAN Bus
Protocol Adaptor”. JOURNAL OF EAST CHINAINSTITUTE OF
TECHNOLOGY, Wuhan, China. Vol.129
No13, Sep. 2006, pp.273-276.

[33] J. Hong-Taek, C. Mi-Joung, and J. W. Hong. (2000). “An Efficient

and Lightweight Embedded Web Server for Web-based Network
Element Management,” International Journal of Network Management.
10, pp. 261-275.

[34] K. Tim et. all., “People, Places, Things: Web Presence for the Real
World,” ACM MONET (Mobile Networks & Applications Journal).7(5), pp.
365-376.

[35] R. Janne, M. Peri, M. J. Saaranen, R. Jussi and S. Juha-Pekka. (2001,

October). “Providing Network Connectivity for Small Appliances: A
Functionally Minimized Embedded Web Server,” IEEE Communication
Magazine.

[36]Blunk Microsystems – TargetWeb,

http://www.blunkmicro.com/web.htm, September, 2006.

[37] Moteiv – Tmote Connect, “Tmote Connect – Data

Sheet,”http://www.moteiv.com/products/docs/tmote-connect
datasheet. pdf, February 2006.
[38] A. Turan, “Remotely Accessible Hardware-in-the-Loop Robot
Simulator” MS Thesis, University of Alaska Fairbanks, Electrical and
Computer Engineering, 2006.

[39] Sense Laboratory, ECE Department, University of Alaska

Fairbanks. http://www.faculty.uaf.edu/ffdr/research.htm

40
[40] O. Lewis, “Time Synchronization and System Support for Energy
Efficient WSNs,” MS Thesis, University of Alaska Fairbanks, Electrical
and Computer Engineering, 2007.

[41] V. Revuri, “Internet Based Data Collection and Monitoring for

WSNs,” MS Thesis, University of Alaska Fairbanks, Electrical and
Computer Engineering, 2007.

[42] Rabbit Semiconductor, “RCM3750 Rabbit Core Data Sheet,”

http://www.rabbitsemiconductor.com/products/rcm3750/rcm3750.pdf,A
ugust 2005.

[43] E. Siever, A. Weber, S. Figgins, and R. Love, Linux in a Nutshell.

Sebastopol, CA: O’Reilly, 2005.

[44] Q. Zhou, W. Wu, and Y. Ma, “The embedded data acquisition

system for Mössbauer spectrum,” in Proc. Third Real-Time Linux
Workshop Embedded Linux Expo Conf. Real-Time Embedded Comput.
Conf., Milan, Italy, Nov. 2001, pp. 26–29.

[45] J. E.Marca, C. R. Rindt, M.Mcnally, and S. T. Doherty, “A GPS

enhanced in-vehicle extensible data collection unit,” Inst. Transp.
Studies, Univ. California, Irvine, CA, Uci-Its-As-Wp-00-9, 2000.

[46] W. Kattanek, A. Schreiber, and M. Götze, “A flexible and cost-

effective open system platform for smart wireless communication
devices,” in Proc. ISCE, 2002.

[47] J. E. Marca, C. R. Rindt, and M. G. Mcnally, “The tracer data

collection system: Implementation and operational experience,” Inst.
Transp. Studies, Univ. California, Irvine, CA, Uci-Its-As-Wp-02-2, 2002.

[48] E. Bekiroglu and N. Daldal, “Remote control of an ultrasonic motor

by using a GSM mobile phone,” Sens. Actuators A, Phys., vol. 120, no.
2, pp. 536–542, May 17, 2005.

[49] C. E. Lin and C.-C. Li, “A real-time GPRS surveillance system using
the embedded system,” J. Aerosp. Comput. Inf. Commun., vol. 1, no. 1,
pp. 44–59, Jan. 2004.

[50] C. Xiaorong, S. Zhan, and G. Zhenhua, “Research on remote data

acquisition system based on GPRS,” in Proc. 8th ICEMI, 2007, pp. 2-20–
2-23.

41
[51] M. A. Al-Taee, O. B. Khader, and N. A. Al-Saber, “Remote
monitoring of vehicle diagnostics and location using a smart box with
Global Positioning System and General Packet Radio Service,” in Proc.
IEEE/ACS AICCSA, May 13–16, 2007, pp. 385–388.

[52] C. Zhang, J. Ge, H. Yu, and X. Zhang, “ET gravimeter data

collecting system based on GPRS,” in Proc. 8th ICEMI, Jul. 18–Aug. 16,
2007, pp. 2-86–2-92.

[53] A. Sang, H. Lin, and C. E. Y. Z. Goua, “Wireless Internet-based

measurement architecture for air quality monitoring,” in Proc. 21st
IEEE IMTC, May 18–20, 2004, vol. 3, pp. 1901–1906.

[54] G. Zhenyu and J. C. Moulder, “An Internet based telemedicine

system,” in Proc. IEEE EMBS Int. Conf. Inf. Technol. Appl. Biomed.,
2000, pp. 99–103.

[55] J. Dong and H. H. Zhu, “Mobile ECG detector through

GPRS/Internet,” in Proc. 17th IEEE Symp. CBMS, Jun. 24–25, 2004, pp.
485–489.

[56] P.Wang, J.-G.Wang, X.-B. Shi, andW. He, “The research of

telemedicine system based on embedded computer,” in Proc. 27th
IEEE Annu. Conf.Eng. Med. Biol., Shanghai, China, Sep. 1–4, 2005, pp.
114–117.

[57] C. E. Lin, C.-C. Li, A.-S. Hou, and C.-C.Wu, “A real-time remote
control architecture using mobile communication,” IEEE Trans.
Instrum. Meas.,vol. 52, no. 4, pp. 997–1003, Aug. 2003.

[58] T. Motylewski, “The industrial data-acquisition system with

embedded Rt-Linux and network server technology,” in Proc. Third
Real-Time Linux Workshop, 2001. [Online]. Available: The Real Time
Linux Foundation:
http://www.realtimelinuxfoundation.org/events/rtlws-2001/papers.html
[59] K. Yaghmour, Building Embedded Linux Systems. Sebastopol, CA:
O’Reilly, 2003.

[60] C. Hallinan Embedded Linux Primer: A Practical Real-World

Approach. Englewood Cliffs, NJ: Prentice–Hall, 2006.

[61] NMEA, NMEA 0183 Standard. [Online]. Available:

http://www.nmea.org

42
[62] RTOS Evaluation Project, “What makes a good RTOS,” Dedicated
Systems Experts, 2001. [Online]. Available:
http://www.dedicatedsystems. Com

43