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 for any practical use [8]. My objective is to create a miniature Web

2

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 as x86, Alpha, Sparc, MIPS, SuperH, PowerPC and ARM. Where

3

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 electronics, including PDAs, mobile phones, digital media and music

4

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.

To add to your problems, the situation between any two nodes changes dynamically and very rapidly, so any failure situations can be

5

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 to various information [3]. It brings great convenience to remote video monitoring and equipment management. The main advantages of

6

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 [5]. Compared with the traditional C/S mode, this mode is simple to use, convenient to maintain, and easy to extend.

7

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 serverIn 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/srcCreat "Makefile" file:#/configureModify "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 ofroot directory of the Web server by modifying thestatements 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 theExecutable 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//specify the actual path of the virtual path of the server's default page4) 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 SYSTEMS5.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 toPC/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 transferdata 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 servicesIn 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 everbeing 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, and a number of other features. Compliance with this standard makes UNIX systems much more appropriate for real-time applications

26

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 timers are partially implemented. The problems of kernel non-preempt ability, low timer resolution, and high interrupt latency remains

27

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 programmers to write code with reckless abandon, without regard to how big the program is. This powerful feature is not needed in an

28

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 software for each embedded system can be loaded from a common server. This can be a very powerful feature for user monitoring and

29

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.

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

30

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 tofigure 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 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)

31

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. 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

32

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 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.

33

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 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

35

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 innetwork 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

36

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 and headaches of software royalties; end users get more value. And the penguins of the South Pole are celebrating.

37

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.

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

38

[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

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

39

[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.129No13, 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,August 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.

[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

41

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

[62] RTOS Evaluation Project, “What makes a good RTOS,” Dedicated

42

Systems Experts, 2001. [Online]. Available: http://www.dedicatedsystems. Com

43