Embedded operating systems

Embedded Operating Systems Dinuka Wijesinghe

B00538290

University of Ulster, Jordanstown Systems Software

COM 332 Assignment 2

Abstract This paper presents a comprehensive in-depth study of Embedded Operating Systems. This includes discussing typical requirements, constraints, and applications of embedded systems. Typical characteristics , issues and design requirements for an embedded operating systems and the relative advantages and disadvantages of developing an embedded operating system based on modifications to an existing operating system compared to the development of a purpose-built embedded operating system. This section should make reference to commercially available embedded operating systems. Keywords: Requirements engineering, specification, Embedded Operating Systems

1. Introduction

Like the familiar Microwave Oven, an Embedded System is designed to perform some dedicated function. A combination of hardware and software, it forms an embedded part of a complete device. Since an Embedded system has a limited range of applications, design engineers face no problem to optimize both size and cost or enhance reliability and quality of performance.

Embedded systems range from portable devices such as digital watches and MP3 players, to large stationary

installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure.

Typically, embedded systems are Reactive and Real time systems. A Reactive system is one, which is in continual interaction with its environment and executes at a pace determined by that environment.

Embedded system is application-oriented special computer system which is scalable on both software and hardware. It can satisfy the strict requirement of functionality, reliability, cost, volume, and power consumption of the particular application.

With rapid development of IC design and manufacture, CPUs became cheap. Lots of consumer electronics have embedded CPU and thus became embedded systems. For example, PDAs, cell phones, point-of-sale devices, VCRs, industrial robot control, or even your toasters can be embedded system. There is more and more demand on the embedded system market. Some report expects that the demand on embedded CPUs is 10 times as large as general purpose PC CPUs.

As applications of the embedded systems become more complex, the operating system support and development environment became crucial.

Figure 1: Generic embedded system.

2. Uses of Embedded Systems

There are endless uses for embedded systems in consumer products, with new methods of exploiting them presented every year at such industry events as the MEDC and the Embedded Systems Conference. The most obvious beneficiaries are those enterprises concerned with the manufacture and sale of electrical devices, as the inclusion of microcontrollers to replace general purpose microprocessors can drive down unit manufacturing costs and end user prices dramatically, resulting in increased sales and an improved profit margin. The use of embedded systems in electrical products can also solve many problems of complexity and product size. For example, a modern automobile may contain dozens of embedded systems to control a wide range of processes within the car, ranging from brake balance control to air conditioning to the ignition system. Without embedded systems it would be impossible to computerise all of these features without the inclusion of a mass of complicated, fault prone electronics. The only realistic alternative to using embedded systems in a modern automobile would be to install a fully functional PC within the car to control all of the functions currently managed by microcontrollers. Examples:

• Audio like mp3 players and telephone switches for interactive voice response systems

• Avionics, such as inertial guidance systems, flight control hardware/software and other integrated systems in aircraft and missiles

• Cellular telephones and telephone switches • Electric or Electronic Motor controller for

Brushless DC motors, Induction motors and DC Motors

• Engine controllers and antilock brake controllers for automobiles

• Home automation products, such as thermostats, air conditioners, sprinklers, and security monitoring systems

• Handheld calculators • Household appliances, including microwave

ovens, washing machines, television sets, DVD players and recorders

• Medical equipment • Personal digital assistant • Videogame consoles • Computer peripherals such as routers and

printers • Industrial controllers for remote machine

operation • Digital musical instruments (digital synthesizers

and digital pianos). • Security applications such as DVR and video

server

Characteristics

• Embedded Systems are designed to do some specific task, rather than be a general-purpose computer for multiple tasks. Some also have real-time performance constraints that must be met, for reason such as safety and usability; others may have low or no performance requirements, allowing the system hardware to be simplified to reduce costs.

• Embedded Systems are not always separate

devices. Most often they are physically built-in to the devices they control.

• The software written for embedded systems is often called firmware, and is stored in read-only memory or Flash memory chips rather than a disk drive. It often runs with limited computer hardware resources: small or no keyboard, screen, and little memory.

• Must be dependable. Reliability R (t) = Probability of system working correctly provided that it was working at t=O. Making the system dependable must not be an afterthought, it must be considered from the very beginning

• Maintainability M (d) = Probability of system working correctly d time units after error occurred

• Availability A (t): Probability of system working at time t.

• Safety: No harm to be caused.

• Security: Confidential and authentic communication. Even perfectly designed systems can fail if the assumptions about the workload and possible errors turn out to be wrong.

• Must be efficient Energy efficient Code-size efficient (especially for systems on a chip) Run-time efficient Weight efficient Cost efficient

• Dedicated towards a certain application. Knowledge about behaviour at design time can be used to minimize resources and to maximize robustness.

• Dedicated user interface. (No mouse, keyboard and screen)

• Many Embedded System must meet real-time constraints

• Frequently connected to physical environment through sensors and actuators, Dortmund

Growing importance of embedded systems

• Worldwide mobile phone sales surpassed 156.4 rnillion units In Q2 2004, a 35% increase from Q2 2003,

• The worldwide portable flash player market exploded in 2003 and is expected to grow from 12.5 rnillion units in 2003 to over 50 rnillion units in 2008

• Global 3G subscribers will grow from an estimated 45 rnillion at the end of 2004 to 85 rnillion in 2005,according to Wireless World Forum

• The number of broadband lines worldwide increased by almost 55% to over 123 rnillion in the 12months to the end of June 2004, according to Point-Topic.

• Today's DVR (digital video recorders) users - 5% of households will grow to 41% within five years

• Embedded chips form the backbone of the electronics driven world in which we live they are part of

• almost everything that runs on electricity • 79% of all high-end processors are used in

embedded systems

Application areas

• Automotive • Electronics • Avionics • Trains • Telecommunication • Medical systems • Authentication • Military applications • Robotics • Sensor technology • Mobile phones • Mobile base station • Telecom switch • Optical O copper connections • Smart welding machine • Sewing machine

3. Requirements

There are two kinds of requirements: functional and quality of service. Functional requirements are requirements about what the system should do and how it

should behaviour in a variety of circumstances. For example, · The system shall adjust the angle of the telescope under user control · The system shall deliver anaesthetic agent in gaseous form to a desired concentration. · Locking clamps shall engage when the elevator cable breaks. · The device shall alarm if the heart rate falls to less than 30 beats per minute. · The pacemaker shall pace in AAI mode (pace the atrium, sense in the atrium, inhibit on an intrinsic heart beat detection). · The spacecraft shall downlink captured information periodically to the deep space network. Quality of Service (QoS) requirements specify how well a functional requirement shall be accomplished. In real-time and embedded systems, QoS requirements may specify properties of the system, e.g. range, speed, throughput, capacity, reliability, maintainability, evolvability, time to market, safety, predictability, schedulability; or properties of the process. As a rule of thumb, if it’s something that can be quantified, or optimized, then it is a QoS requirement. For example (QoS requirements italicized), · The angle of the telescope shall be set in units of 0.1 degrees with a maximum error of 0.01 degrees. · The anaesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%. · Locking clamps shall engage in the event of an elevator support cable breakage within less than 0.5 seconds. · The device shall alarm within 10 seconds if the heart rate falls to less than 30 beats per minute. · The pacemaker pacing rate shall be settable from 30 to 120 paces per minute (inclusive) and during operation accuracy of pacing shall be ±100 ms. · The reliability of communications from the spacecraft to the deep space network shall be better than 0.9994%, with a single bit error detection/correction rate of 0.9999% and a multiple bit detection/correction rate of 0.99%.

Industrial Requirements Industrial requirements depend on applications; special requirements typically include:

• Availability and reliability

Availability (from Wikipedia): The degree to which a system, subsystem, or equipment is operable and in a committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random, time. Simply put, availability is the proportion of time a system is in a functioning condition.

Reliability: The IEEE defines it as ". . . the ability of a system or component to perform its required functions under stated conditions for a specified period of time." In general, in automation, availability and reliability are required to be very high, to minimize the cost of operation (for instance to minimize scheduled and unplanned maintenance)

• Safety

Safety: Absence of catastrophic consequences of a system failure for property, humans, and environment

The (embedded) automation systems and plants have to be safe operational over extended periods of time, even if they continue operation in a degraded mode in the presence of a fault.

• Survivability

Survivability: Need for restricted modes of operation that preserve essential services in adverse operational environments

• Security

Operational IT security requirements: Confidentiality: Protecting data from unauthorized entities Integrity: Protecting against unauthorized data manipulation Availability: Data available when needed • Real-time, deterministic response

Typically, (networked) embedded systems are required to operate in a reactive way (for instance, systems used for control purposes) requiring to respond within a predefined period of time, mandated by the dynamics of the process under control. A response, in general, may be: •Periodic - to control a specific physical quantity by regulating dedicated end-effectors •Aperiodic - arising from unscheduled events such as out-of-bounds state of a physical parameter or any other kind of abnormal conditions.

• Power consumption

Low-power design: extending life time of electronic components (lifecycle). Wireless sensor networks need for self-sustained energy source. Sources of wireless power: •Batteries, fuel cells, etc. •From local environment: light, heat, vibration, •Transmitted by optical and radio frequencies, sound

• Lifetime issues

Typical lifetime of a device in an industrial environment is around 10 - 20 (plus) years

Need for: •Increased reliability •Robustness •Re-configurability •Maintainability •Scalability

Within the exception of these few common features, rest of the embedded hardware is usually unique and varies from application to application. Each system must meet a completely different set of requirements. The common critical features and design requirements of an embedded hardware include:

• Processing power: Selection of the processor is based on the amount of processing power to get the job done and also on the basis of register width required.

• Throughput: The system may need to handle a lot of data in a short period of time.

• Response: the system has to react to events quickly

• Memory: Hardware designer must make his best estimate of the memory requirement and must make provision for expansion.

• Power consumption: Systems generally work on battery and design of both software and hardware must take care of power saving techniques.

• Number of units: the no. of units expected to be produced and sold will dictate the Trade-off between production cost and development cost

• Expected lifetime: Design decisions like selection of components to system development cost will depend on how long the system is expected to run.

• Program Installation: Installation of the software on to the embedded system needs special tools.

• Testability & Debug ability: setting up test conditions and equipment will be difficult and finding out what is wrong with the software will become a difficult task without a keyboard and the usual display screen.

• Reliability: is critical if it is a space shuttle or a car but in case of a toy it doesn’t always have to work right.

4. System Limitations Most embedded systems place severe constraints on the processor in the terms of requirements for size, weight, power, cooling, performance, reliability, and cost. This is because the processor is just a component of a larger system, which has its own operating requirements and manufacturing constraints.

Size and Weight

Size and weight restrictions can greatly limit the complexity of the hardware which can be brought to bear on solving a particular embedded control problem. Platforms such as aircraft, spacecraft, and portable equipment may have strict weight limitations. Most other applications also have size limitations of some sort. A typical embedded controller may have a size budget of a few cubic inches, and a weight budget of a few pounds (including the power supply requirements).

The problem with size and weight restrictions is that high performance processing systems tend to be larger and heavier than slower systems. At the CPU level, a processor that has a large number of pins takes up a large printed circuit board area. At the system level, a design that needs cache memory controller chips and large amounts of memory takes even more printed circuit board area.

The key to the size and weight issue is keeping component count small. This is best accomplished by using

the highest integration level possible. But, even with custom VLSI chips and surface- mount technology the fact remains that in embedded system, high complexity means problems with size and weight budgets. The smallest systems are those which have on-chip memory for some or all of the system requirements, do not require external support chips (especially cache memory support), and which allow small, efficient encodings of programs.

Power and Cooling

The processor complexity can affect the power consumption of the system. High power consumption increases the size and weight requirements of the power supply. Since essentially all power consumed by a computer is eventually given off as heat, increased power consumption results in increased cooling requirements.

The amount of power used by the processor is related to the number of transistors and pins on the processor chip. Processors that rely on exotic process technology for speed usually consume too much power to be useful. Processors that need huge numbers of power consuming high speed memory devices likewise can exceed a power budget.

Consequently, CMOS components are usually used whenever possible. Newer CMOS technology runs at high speed, yet dissipates little power in comparison to other technologies. Static CMOS is often selected because it can operate with a slow or stopped clock to save power when the system is idle.

Computing Performance Computing performance in a real time embedded control environment is not simply an instructions per-second rating. While raw computational performance is important, other factors which are vital to system performance include interrupt response characteristics, context switching overhead and I/O performances. Since real time tasks are characterized by frequent, often unpredictable events, the performance of a processor at handling interrupts is crucial to its suitability for real time processing. Since a control application usually involves a reasonable amount of communication with the outside world (such as reading sensors and activating control circuits), good IJO performance is also important.

Two key considerations for more difficult real time control applications are predictability and determinacy. Predictable systems have behavior at run-time that is easily understandable from examination of the original source code program;

In other words, there are no surprises to a user of average sophistication. Deterministic systems hove instructions whose behavior does not vary; in other words, the execution speed of an instruction does not depend on execution history of the program. For real time control with hard deadlines, a designer must be able to predict with absolute certainty the running time of the piece of code responding to an external event. If a system has variable performance elements, such as cache memory, the designer must be extremely pessimistic about the performance of these features, and plan on the worst case.

In some systems, it is important to exactly determine the time for a sequence of instructions to execute, with no possibility for variation allowed. Processors with extremely consistent execution speeds can use software to reduce system complexity by replacing hardware such as UART chips, disk controller chips, or video memory se-quencers with programmed transfers using carefully timed code.

Since program memory space may be extremely limited, programs may be highly compacted by using subroutine calls to reuse common code sequences. In fact, many embedded applications use threaded languages such as Forth because they produce exceedingly compact code. This suggests that an embedded processor should have efficient support for subroutine calls as a means of conserving program memory.

Embedded processing applications are notorious for extreme operating conditions, especially in automotive and military equipment. The processing system must deal with vibration, shock, extreme heat and cold, and perhaps radiation. In remotely installed applications, such as spacecraft and undersea applications, the system must be able to survive without field service technicians to make repairs.

The general techniques used for avoiding problems caused by operating environments are to keep the component count and number of pins as low as possible. It is also helpful to keep the systems cool as possible to inhibit aging of the system's components.

Cost

The cost of the processor itself may be very important to low- and medium-performance systems, especially consumer electronics products. Since the cost of a chip is related to the number of transistors and to the number of pins on the chip, low complexity processors have an inherent cost advantage.

In high-performance systems, the cost of the processor may be overwhelmed by the cost of the multi-layered printed circuit boards, support chips, and high-speed memory chips. In these cases, overall system complexity must be reduced to keep system costs down.

Architectural Features

Many of the computer architect's techniques to improve system performance, such as cache, branch target buffers, and pre-fetch queues, work on statistical principles. They assume things such as temporal and spatial locality, which tend to be true on large workstation programs when run for long periods of time. They give relatively uniform performance when used in a CAD or office automation environment. However, the constraints of hard real time control applications have requirements which make standard, statistically good speedup techniques inappropriate. Real time control of periodic events requires absolute predictability, often down to a single clock cycle. Deadlines must be guaranteed to be met 100% of the time. Having a situation where an unfortunate interaction between two different routines contending for cache memory causes an increase in cache misses is simply unacceptable. In a tightly scheduled environment, even the time taken by a single cache miss can cause a missed deadline. Inappropriate Architectural Features

There are many reasons that an architectural feature is included in a processor. Today, usually the feature is added in order to support "general purpose" computing, which usually means engineeri n g work s ta t i on a ppl i ca t i on p ro gra ms . T he problem is that this definition of "general purpose" is often at odds with requirements for the systems we have just described. The list of architectural features that are inappropriate for hard real time embedded control systems seems similar to a catalogue of modern processor design techniques. They are listed here along with a brief explanation of the problems they can cause. The focus here is on determinism and predictability, although the reader should not forget that most of these features also contribute substantially to system complexity as well.

Cache memory: Data and instruction cache m e m o ri es a r e t h e b i g g e s t s ou r c e s o f u n p r edictability and indeterminacy. Modern compiler technology is just beginning to address the issue of scheduling instruction cache misses. Furthermore, it is impossible to characterize data cache misses for programs of interesting complexity. Because the time required to process a cache miss is approximately an order of magnitude slower than the time required for a cache hit, significant execution speed degradation takes place with even a small percentage of cache misses. Figure 1 shows relative execution time variations that may take

place with varying numbers of cache misses. In this five-instruction example, assuming that a cache miss costs five clock cycles, execution time may vary between 5 and 25 clock cycles for the same code. In hard real-time systems, often the worst case of all cache misses must be assumed for time-critical sections, resulting in designing hardware with only fast static memory chips that render the cache management hardware super-fluous. On-chip caches add to system debugging concerns because they are often not visible outside the chip.

Low semantic content of instructions: Low semantic content of instructions greatly increases the number of instructions that must be executed to accomplish a given task. This, in turn, increases demands for high-speed memory. A requirement for large amounts of high speed

memory in turn either requires the use of cache memory or a significant expense in making all program memory out of cache-grade memory chips for high guaranteed system performance.

Variable length execution times of instructions: Many instructions can take a variable number of clock cycles to execute, often depending on the data input to the instruction. An example of such an instruction is a multiply routine that has an "early-out" feature.

Write buffers: Write buffers allow the CPU to perform a write to memory without pausing for an actual memory cycle to take place. The problem is that this write must then wait for spare bus cycles.

If no spare bus cycles are forthcoming, the processor must be stalled when the write buffer overflows. Additional stalls can be caused if a memory read could possibly correspond to a memory location that has yet to be updated by the write buffer. Interaction between the write buffer and cache misses for instruction and data fetches can cause indeterminacy in program execution.

Branch target buffers: This is a special case of an instruction cache, in which past program execution history is used to cache instructions at branch targets for quick access. This type of instruction cache operates in a manner dependent on input data, and so is beyond the ability of compilers to manage effectively. Branch target buffers are sometimes used in conjunction with branch prediction strategies, in which the compiler encodes a guess as to whether a particular branch is likely to be taken into the instruction itself, causing either the branch target or the next consecutive instruction to be fetched before the outcome of the branch is resolved. The actual time to perform a branch then depends on whether the compiler guessed the branch outcome correctly, and whether the branch target buffer value corresponds to the guess made by the compiler.

Pre-fetch queues: Pre-fetch queues greatly affect the predictability of execution because the execution time for an instruction depends on whether or not the preceding instructions were slow enough to allow the pre-fetch queue to accumulate new instructions. Thus, determining whether a particular instruction will execute quickly from the pre-fetch queue or slowly from program memory requires cycle counting of several preceding instructions to see if spare memory cycles would have been available for the pre-fetch queue to fill. This cycle counting is subtly affected by data-dependent execution paths through the program as well as the

number of wait states or cache misses in program memory. For example, if there is latency for filling an empty pre-fetch queue, adding a one- cycle wait state that causes the pre-fetch queue to be emptied may add more than one clock cycle to program execution time.

Pipelines: Deep instruction pipeline increases interrupt response latency. Even if the first instruction of an interrupt service routine can be inserted into the pipeline within one clock of the interrupt being asserted, it still takes several clock cycles for the instruction to pass through the pipeline and actually do its job. A pipeline also requires some sort of handling of data dependencies and delays for memory access, which results either in compiler-generated flops, instruction rearrangement, or hardware-generated pipeline stalls. All of these dependency-resolution techniques decrease predictability, determinacy, or both. Pure load/store architectures: Load/store RISC architectures can by their very nature makes no provision for atomic read/modify/write instructions. This generally required the addition of external hardware for implementing semaphores, locks, and other inter-process communication devices, increasing system complexity.

Scoreboards: Scoreboards attempt to speed up program execution by allowing several instructions to be in execution concurrently. Score boarding usually implies out-of-order execution, which may make it impossible to correctly determine the correct system state in the event of an exception or interrupt (the term usually used here is that the system has imprecise interrupts). Furthermore, the execution time of an instruction depends on the resources being used by the previous several instructions, and can vary considerably.

Supers cater instruction issue: Newer-generation microprocessors are beginning to implement "superscalar" instruction execution, in which multiple instructions may be issued in a single clock cycle. Unfortunately, the number of instructions that may be issued depends on the types of the instructions, the available hardware resources, and the execution history of the program. All these factors make it very difficult to determine any single instruction's execution time.

Dependence on sophisticated compiler technology: Most RISC designs depend implicitly on complex and ambitious optimizing compilers for fast operating speeds. This tradeoff between hardware and software complexity is a part of the RISC design philosophy. The problem is that the optimizing compilers make it difficult to establish a correspondence between source code and the code that actually is executed because of the large number of program transformations performed. This compli cates program debuggin g, as wel l as decouples the programmer's source code changes from effects on f inal program performance, decreasing predictability. A surprising side-effect of the complexity of these compilers is that they add a level of indeterminacy in the mapping of source to object code. The use of heuristics for block-level and global optimization techniques can actually cause the same exact sequence of source code statements to generate significantly different object code in two places of the same program module (Razouk etal. 1986). Large register file: The use of a large number of registers allows programs to execute quickly, hut greatly increases the amount of information (the machine state) that must be saved on context switches and interrupts. This adversely affects responsiveness to external events.

Virtual memory: The use of virtual memory

implies the use of a cache memory to perform address translation (a Translation Look aside Buffer), which has the same problems as other caches. If a disk-paging system is used, the problem of speed degradation can become much worse than for simple cache misses.

Use of DRAM access technology: Some processor implementations exploit special access techniques to DRAM chips in order to achieve high average throughput with a low system coat. The use of static-column, paged, and video DRAMs creates real problems in predictability because access to these DRAMs becomes much slower whenever page boundaries must be crossed. The use of DRAM memory chips also requires performing memory refresh, which can interact with other accesses to cause performance degradations that are worse than expected.

Au tonomou s I /O p ro ce s s ors : T h e u s e o f autonomous I/O processors and DMA hardware that steal bus cycles can cause non-determinism as the processor is stalled for bus accesses. Consequently, it is sometimes desirable to perform I/O directly from the CPU.

The Challenge to Processor Designers

The above list of architectural characteristics contains elements of design found in virtually every RISC or CISC processor made today. These architectural characteristics are truly valuable for speeding up average system performance, especially in workstation environments. The problem is that hard embedded real time control applications do not have the same characteristics and requirements as workstation-based engineering design applications, and so these characteristics actually hurt system performance. Therefore, what is needed are new CPU design's that make tradeoffs in favor of the requirements of real time embedded control, even at the expense of performance of workstation-type applications.

5. Embedded OS vs. General Purpose OS

The key difference between general-computing operating systems and real-time operating systems is the need for “deterministic " timing behaviour in the real-time operating systems. Formally, "deterministic" timing means that operating system services consume only known and expected amounts of time. In theory, these service times could be expressed as mathematical formulas. These formulas must be strictly algebraic and not include any random timing components. Random elements in service times could cause random delays in application software and could then make the application randomly miss real-time deadlines – a scenario clearly unacceptable for a real-time embedded system. Many non-real-time operating systems also provide similar kernel services.

General-computing non-real-time operating systems are often quite non-deterministic. Their services can inject random delays into application software and thus cause slow responsiveness of an application at unexpected times. If you ask the developer of a non-real-time operating system for the algebraic formula describing the timing behaviour of one of its services (such as sending a message from task to task), you will invariably not get an algebraic

formula. Instead the developer of the non-real-time operating system (such as Windows, UNIX or Linux) will just give you a puzzled look. Deterministic timing behaviour was simply not a design goal for these general-computing operating systems.

On the other hand, real-time operating systems often go a step beyond basic determinism. For most kernel services, these operating systems offer constant load-independent timing: In other words, the algebraic formula is as simple as: T(message send) = constant , irrespective of the length of the message to be sent, or other factors such as the numbers of tasks and queues and messages being managed by the RTOS.

Many RTOS proponents argue that a real-time operating system must not use virtual memory concepts, because paging mechanics prevent a deterministic response. While this is a frequently supported argument, it should be noted that the term "real-time operating system" and determinism in this context covers a very wide meaning, and vendors of many different operating systems apply these terms with varied meaning. When selecting an operating system for a specific task, the real-time attribute alone is an insufficient criterion, therefore. Deterministic behaviour and deterministic latencies have value only if the response lies within the boundaries of the physics of the process that is to be controlled. For example, controlling a combustion engine in a racing car has different real-time requirements to the problem of filling a 1,000,000 litre water tank through a 2" pipe.

Real-time operating systems are often uses in embedded solutions, that is, computing platforms that are within another device. Examples for embedded systems include combustion engine controllers or washing machine controllers and many others. Desktop PC and other general-purpose computers are not embedded systems.

While real-time operating systems are typically designed for and used with embedded systems, the two aspects are essentially distinct, and have different requirements. A real-time operating system for embedded system addresses both sets of requirements.

The most common operating system for personal computer include Windows from Microsoft, OS X from Apple, and the wide variety of Linux variants that can be obtained from their respective developers. What most people do not know are Real-time Operating Systems or generally referred to by the acronym RTOS. These are operating systems that are used for more specialized applications that demand response that is as close to real time as possible. The most significant difference between the two is in how they approach each task. Standard operating systems focus on doing as much computation in the shortest span of time while RTOS’s emphasize on having a predictable response time.

Standard operating systems are widely used nowadays, partly due to the rapid spread of personal computers. Devices that use standard operating systems, aside from computers and laptops, are also beginning to appear. RTOS’s are used in more specialized fields where the response time is much more important than the ability to

process a huge number of instructions within a given time span. Examples of which are computer that scan levels and states in a facility. It is important that the monitors see changes occur at the instant that they do.

Most operating systems use a time sharing architecture where each task is assigned a small slice of time to execute its instructions before switching to another task. The switching process is too fast that it often appears as real time to users. Some RTOS’s also use this design but with much lower density of tasks to ensure that the processor never gets to loaded, which can increase the response time. Another design that is used for an RTOS is an event-driven architecture. In this design, the system only switches tasks once an event or interrupt occurs.

Coding practices for an RTOS is much stricter compared to a standard OS as the code needs to perform consistently all the time. Standard OS’s are not that concerned since response time is not of great importance in its application.

An RTOS is not required for an embedded system but it can offer powerful advantages to the system developer. Without an RTOS the developer must write his own code to handle all of these functions.

• Enables real-time, deterministic scheduling and task prioritization

• Abstracts away the complexities of the processor • Provides a solid infrastructure constructed of rules

and policies • Simplifies development and improves developer

productivity • Integrates and manages resources needed by

communications stacks and middleware • Optimizes use of system resources • Improves product reliability, maintainability and

quality • Promotes product evolution and scaling

A well-architected RTOS will handle these functions much more efficiently that a programmer could write the code. RTOS developers are expert in how to handle operations with a minimum of processor cycles. There are many questions when adapting a GPOS (General Purpose Operating System) RTOS:

• What does an RTOS have that a GPOS does not? • How useful are the real-time extensions now

available for some GPOSs? • Can such extensions provide a reasonable

facsimile of RTOS performance? Task scheduling Let’s begin with task scheduling. In a GPOS, the scheduler typically uses a fairness policy to dispatch threads and processes onto the CPU. Such a policy enables the high overall throughput required by desktop and server applications, but offers no guarantees that high-priority, time critical threads will execute in preference to lower-

priority threads. For instance, a GPOS may decay the priority assigned to a high-priority thread, or otherwise dynamically adjust the priority in the interest of fairness to other threads in the system. A high-priority thread can, as a consequence, be pre-empted by threads of lower priority. In addition, most GPOSs have unbounded dispatch latencies: the more threads in the system, the longer it takes for the GPOS to schedule a thread for execution. Any one of these factors can cause a high-priority thread to miss its deadlines – even on a fast CPU. In an RTOS, on the other hand, threads execute in order of their priority. If a high-priority thread becomes ready to run, it will, within a small and bounded time interval, take over the CPU from any lower-priority thread that may be executing. Moreover, the high-priority thread can run uninterrupted until it has finished what it needs to do – unless, of course, it is pre-empted by an even higher priority thread. This approach, known as priority-based pre-emptive scheduling, allows high-priority threads to meet their deadlines consistently, no matter how many other threads are competing for CPU time. Pre-emptily kernel For most GPOSs, the OS kernel is not pre-emptily. Consequently, a high-priority user thread can never pre-empty a kernel call, but must instead wait for the entire call to complete – even if the call was invoked by the lowest-priority process in the system. Moreover, all priority information is usually lost when a driver or other system service, usually performed in a kernel call, executes on behalf of a client thread. Such behaviour causes unpredictable delays and prevents critical activities from completing on time. In an RTOS, on the other hand, kernel operations are pre-emptily. There are still windows of time in which pre-emption may not occur, but in a well-designed RTOS, those intervals are extremely brief, often on the order of hundreds of nanoseconds. Moreover, the RTOS will impose an upper bound on how long pre-emption is held off and interrupts disabled; this allows developers to ascertain worst-case latencies. To achieve this goal, the RTOS kernel must be simple and as elegant as possible. Only services with a short execution path should be included in the kernel itself. Any operations that require significant work (For instance, process loading) must be assigned to external processes or threads. Such an approach helps ensure that there is an upper bound on the longest non-pre-emptily code path through the kernel. In a few GPOSs, such as Linux 2.6, some degree of pre-emptibility has been added to the kernel. However, the intervals during which pre-emption may not occur are still much longer than those in a typical RTOS; the length of any such pre-emption interval will depend on the longest critical section of any modules incorporated into the kernel (for example, networking and file systems). Moreover, a pre-empt kernel does not address other conditions that can impose unbounded latencies, such as the loss of priority information that occurs when a client invokes a driver or other system service.

Avoiding priority inversion Even in an RTOS, a lower-priority thread can inadvertently prevent a higher priority thread from accessing the CPU – a condition known as priority inversion. Generally speaking, priority inversion occurs when two tasks of differing priority share a resource, and the higher priority task cannot obtain the resource from the lower-priority task. To prevent this condition from exceeding a fixed and bounded interval of time, an RTOS may provide a choice of mechanisms including priority inheritance and priority ceiling emulation. We could not possibly do justice to both mechanisms here, so let us focus on a simple example of priority inheritance. To begin, we first must look at the blocking that occurs from synchronization in systems, and how priority inversion can occur as a result. Let us say two jobs are running, and that Job 1 has the higher priority. If Job 1 is ready to execute, but must wait for Job 2 to complete an activity, we have blocking. This blocking may occur as a result of synchronization – waiting for a shared resource controlled by a lock or a semaphore – or as a result of requesting a service. The blocking allows Job 2 to run until the condition that Job 1 is waiting for occurs (for instance, Job 2 unlocks the resource that both jobs share). At that point, Job 1 gets to execute. The total time that Job 1 must wait may vary, with a minimum, average, and maximum time. This interval is known as the blocking factor. If Job 1 is to meet any of its timeliness constraints, this factor cannot vary according to any parameter, such as the number of threads or an input into the system. In other words, the blocking factor must be bounded. Now let us introduce a third job that has a higher priority than Job 2 but a lower priority than Job 1 (Figure 1). If Job 3 becomes ready to run while Job 2 is executing, it will pre-empty Job 2, and Job 2 will not be able to run again until Job 3 blocks or completes. This will, of course, increase the blocking factor of Job 1; that is, it will further delay Job 1 from executing. The total delay introduced by the pre-emption is a priority inversion. In fact, multiple jobs can pre-empt Job 2 in this way, resulting in an effect known as chain blocking. Under these circumstances, Job 2 might be pre-empted for an indefinite period of time, yielding an unbounded priority inversion, causing Job 1 to fail to meet any of its timeliness constraints. This is where priority inheritance comes in. If we return to our scenario and make Job 2 run at the priority of Job 1 during the synchronization period, then Job 3 will not be able to pre-empty Job 2, and the resulting priority inversion is avoided (Figure 2). Duelling kernels GPOSs – Linux, Windows, and various flavors of UNIX – typically lack the Mechanisms we have just discussed. Nonetheless, vendors have developed a number of real-time extensions and patches in an attempt to fill the gap. There is, for example, the dual-kernel approach, in which the GPOS runs as a task on top of a dedicated real-time kernel (Figure 3). Any tasks that require deterministic scheduling run in this kernel, but at a higher priority than the GPOS kernel. These tasks can thus pre-empt the GPOS whenever they need to execute and will yield the CPU to the GPOS only when their work is done.

Unfortunately, tasks running in the real-time kernel can make only limited use of existing system services in the GPOS – file systems, networking, and so on. In fact, if a real-time task calls out to the GPOS for any service, it will be subject to the same pre-emption problems that prohibit GPOS processes from behaving deterministically. As a result, new drivers and system services must be created specifically for the real-time kernel – even when equivalent services already exist for the GPOS. Also, tasks running in the real-time kernel do not benefit from the robust Memory Management Unit (MMU) protected environment that most GPOSs provide for regular, non-real-time processes. Instead, they run unprotected in kernel space. Consequently a real-time task that contains a common coding error, such as a corrupt C pointer, can easily cause a fatal kernel fault. To complicate matters, different implementations of the dual kernel approach use different APIs. In most cases, services written for the GPOS cannot be easily ported to the real-time kernel, and tasks written for one vendor’s real-time extensions may not run on another’s real-time extensions.

Modified GPOSs Rather than use a second kernel, other approaches modify the GPOS itself, such as by adding high-resolution timers or a modified process scheduler. Such approaches have merit, since they allow developers to use a standard kernel (albeit with proprietary patches) and programming model. Moreover, they help address the requirements of reactive, event-driven systems. Unfortunately, such low-latency patches do not address the complexity of most real-time environments, where real-time tasks span larger time intervals and have more dependencies on system services and other processes than do tasks in a simple event-driven system. For instance, in systems where real-time tasks depend on services such as device drivers or file systems, the problem of priority inversion would have to be addressed. In Linux, for example, the driver and Virtual File System (VFS) frameworks would effectively have to be rewritten along with any device drivers and file systems employing them. Without such modifications, real-time tasks could

experience unpredictable delays when blocked on a service. As a further problem, most existing Linux drivers are not pre-empting. To ensure predictability, programmers would also have to insert pre-emption points into every driver in the system. All this points to the real difficulty and immense scope of modifying a GPOS so it is capable of supporting real-time behaviour. However, this is not a matter of RTOS good, GPOS bad. GPOSs such as Linux, Windows XP, and UNIX all serve their intended purposes extremely well. They only fall short when they are forced into deterministic environments they were not designed for, such as those found in automotive telemetric systems, medical instruments, and continuous media applications. What about an RTOS? Still, there are undoubted benefits to using a GPOS, such as support for widely used APIs, and in the case of Linux, the open source model. With open source, a developer can customize OS components for application-specific demands and save considerable time troubleshooting. The RTOS vendor cannot afford to ignore these benefits. Extensive support for POSIX APIs – the same APIs used

by Linux and UNIX – is an important first step. So is providing well-documented source and customization kits that address the specific needs and design challenges of embedded developers. The architecture of the RTOS also comes into play. An RTOS based on a microkernel design, for instance, can make the job of OS customization fundamentally easier to achieve. In a microkernel RTOS, only a small core of fundamental OS services (such as signals, timers, and scheduling) reside in the kernel itself. All other components (such as drivers, file systems, protocol stacks, and applications) run outside the kernel as separate, memory protected processes (Figure 4). As a result, developing custom drivers and other application-specific OS extensions does not require specialized kernel debuggers or kernel gurus. In fact, as user space programs, such extensions become as easy to develop as regular applications, since they can be debugged with standard source level tools and techniques. For instance, if a device driver attempts to access memory outside its process container, the OS can identify the process responsible, indicate the location of the fault, and create a process dump file viewable with source-level debugging tools. The dump file can include all the information the debugger needs to identify the source line that caused the problem,

Along with diagnostic information such as the contents of data items and a history of function calls. This architecture also provides superior fault isolation. If a driver, protocol stack, or other system service fails, it can do so without corrupting other services or the OS kernel. In fact, software watchdogs can continuously monitor for such events and restart the offending service dynamically, without resetting the entire system or involving the user in any way. Likewise, drivers and other services can be stopped, started, or upgraded dynamically, again without a system shutdown. A strategic decision An RTOS can help make complex applications both predictable and reliable. In fact, the predictability made possible by an RTOS adds a form of reliability that cannot be achieved with a GPOS (if a system based on a GPOS does not behave correctly due to incorrect timing behaviour, then we can justifiably say that the system is unreliable). Still, choosing the right RTOS can itself be a complex task. The underlying architecture of an RTOS is an important criterion, but so are other factors. Consider Internet support. Does the RTOS support an up-to-date suite of protocol stacks such as IPv4, IPv6, IPSec, SCTP, and IP filtering with NAT? What about scalability? Does the RTOS support a limited number of processes, or does it allow hundreds or even thousands of processes to run concurrently? And does it provide support for distributed or symmetric multiprocessing? GUI considerations Graphical User Interfaces (GUIs) are becoming increasingly common in embedded systems, and those interfaces are becoming increasingly sophisticated.

Consequently, does the RTOS support primitive graphics libraries, or does it provide an embeddable windowing system that supports 3D rendering, multi-layer interfaces, and other advanced graphics? Can you customize the GUI’s look-and feel? Can the GUI display and input multiple languages simultaneously? And does the GUI support an embeddable web browser? The browser should have a scalable footprint, and be capable of rendering web pages on very small screens. It should also support current standards such as HTML 4.01, XHTML 1.1, SSL 3.0, and WML 1.3. Tool considerations On the tools side, does the RTOS vendor offer diagnostic tools for tasks such as trace analysis, memory analysis, application profiling, and code coverage? What of the development environment? Is it based on an open platform like Eclipse, which lets you readily plug in third-party tools for modelling, version control, and so on? Or is it based on proprietary technology? On one point, there is no question. The RTOS can play a key role in determining how reliable your system will be, how well it will perform, and how easily it will support new or enhanced functionality. And it can support many of the rich services traditionally associated with GPOSs, but implemented in a way to address the severe processing and memory restraints of embedded systems.

6. Embedded GPOS Examples

Windows XP

Benefits: Windows® XP Embedded is built on upon the proven code base of Windows XP, which features a 32-bit computing architecture and a fully protected memory model. Key reliability, security, and performance features include Device Driver Rollback, a pre-emptive Multi-tasking Architecture, and Encrypting File System (EFS) with Multi-user Support.

By componentizing Windows® XP Professional, Windows XP Embedded enables developers to use the latest technologies the Windows platform has to offer, while at the same time achieving a reduced footprint. Embedded developers can take advantage of all the great features available in Windows XP such as multimedia capabilities. Features include Universal Serial Bus (USB) and Internet Explorer 6.0.

Windows XP Embedded also includes embedded-enabling features, such as Flexible Boot and Storage Options, and Enhanced Write Filter. Rich networking capabilities and management features provide Windows® XP Embedded devices seamless integration with PCs, servers, Web services, and other devices. Comprehensive networking protocol support includes Infrared Data Association (IrDA) Support, 802.11 and 802.1x, and Universal Plug and Play.

Windows® XP Embedded includes a completely redesigned tool set that enables devices based on Windows XP Embedded to be brought to market faster. The new Windows Embedded Studio streamlines the end-to-end development process enabling developers to rapidly configure, build, and deploy smart designs with rich applications.

Features:

Device Driver Rollback If issues occur when new device drivers are added, a copy of the previously installed driver is saved, enabling a user to roll back to the original device.

Universal Serial Bus (USB) Supports a wide array of USB peripherals such as scanners, mice, keyboards, and so on.

Universal Plug and Play (UPnP) Universal Plug and Play (UPnP) is architecture for pervasive peer-to-peer network connectivity of devices of all form factors, including intelligent appliances and wireless devices. UPnP is a distributed, open networking architecture that leverages TCP/IP and the Web to enable seamless-proximity networking in addition to control and data transfer among networked devices in the home, office, and everywhere in between.

Pre-emptive Multi-tasking Architecture Designed to allow multiple applications to run simultaneously. Includes enhancements to ensure great system response and stability.

Encrypting File System (EFS) with Multi-user Support Encrypts each file with a randomly generated key. The encryption and decryption processes are transparent to the user. In Windows XP Embedded, EFS can allow multiple authorized users access to an encrypted document.

Flexible Boot and Storage Options In addition to magnetic disk, boot capability is offered for alternative nonvolatile (persistent) read/write storage devices such as

Flash ROM and battery-backed RAM. Boot from CDROM is possible when the El Torito bootable CD-ROM driver is used in combination with the Enhanced Write Filter and ROM. Windows XP Embedded also provides support for DiskOnChip Flash, PCMCIA-ATA, Compact Flash, MultiMediaCard, and MemoryStick.

Enhanced Write Filter Enhanced Write Filter (EWF) re-routes selected disk I/O to memory or another storage medium, thus providing the appearance to the operating system that your read-only storage is writable.

Internet Explorer 6 Provides the latest Web browsing technologies including visual refresh, playback support for Flash and Shockwave files, and privacy enhancements.

802.11 Windows XP Embedded supports 802.11 wireless LAN technologies that provide high bandwidth connectivity without wires.

802.1X 802.1X provides secure access to the network to support wireless LANs and Ethernet. It enables interoperable user identification, centralized authentication, and dynamic key management and can secure both wired and wireless LAN access.

Infrared Data Association (IrDA) Support Windows XP Embedded fully supports standards for this low-cost, low-power, cable replacement technology that enables any device to communicate from point-to-point when two devices are in line sight of each other.

Embedded-Specific Features Windows XP Embedded with Service Pack 1 incorporates the latest embedded-enabling capabilities, focusing on remote deployment and maintenance scenarios.

Remote Boot The Remote Boot service for Windows XP Embedded with Service Pack 1 enables a Windows XP Embedded-based client device to boot using an image downloaded from a server. It also enables Windows XP Embedded-based devices to operate without requiring persistent storage, such as a hard drive or Flash RAM.

Device Update Agent Windows XP Embedded with Service Pack 1 enhances support for in-field servicing with Device Update Agent (DUA). DUA is designed to address scenarios where it is necessary to incrementally update or service a Windows XP Embedded device that has been previously deployed to the field.

Footprint Estimator Using Footprint Estimator, embedded developers can now estimate the footprint size of individual components and their dependencies, as well as macro components, prior to adding them to a configuration. This enables developers to proactively know what the impact of a given component will have on the image size, thereby avoiding guesswork and saving development time.

System Deployment Image (SDI) Manager: The System Deployment Image (SDI) service enables you to quickly deploy run-time images to your Windows XP Embedded-based devices. The SDI feature enables easier staging of runtime images on your development workstation and preparation of images for fast deployment. It also provides an easier method for transferring the runtime image from the development system to the device.

Multilingual User Interface (MUI) Language Packs Windows XP Embedded with Service Pack 1 has support for over 20 languages. Windows XP Embedded MUI Language Packs enable you to save time and effort in

localizing your solution for multiple markets by enabling you to develop your customized operating system image only once rather than requiring you to localize each version from the ground up. By simply adding the desired language pack to your base English configuration, the user interface will be localized into your chosen language.

Hardware Requirements

CPU: Computer with 300 megahertz or higher processor clock speed recommended; Pentium II 233 MHz minimum required (single or dual processor system);* Intel Pentium/Celeron family, or AMD K6/Athlon/Duron family, or compatible processor recommended. Some slower CPU's are supported but will cause limitations of the build particularly in multimedia applications.

RAM: 256 Megabytes (MB) of RAM or higher (256 megabytes recommended) (128 MB minimum supported; but will limit performance and some features)

Flash: 200 megabytes or more of available storage space

Video: Super VGA (800 × 600) or higher-resolution video adapter and monitor

User Interface: Keyboard and Microsoft Mouse or compatible pointing device

Typical requirements for a Full standard workstation XPE build: A system with a Pentium III or better processor 256MB of memory and at least 2GB of flash for a Full Standard build with SP3 and .Net 3.0 frameworks. Builds running multimedia will require a faster processor and more memory, typically at least 512MB, to run smoothly.

Minimum recommended system for a Full standard workstation XPE build: LX800 500MHz CPU, 512MB of memory 4GB of High-speed DMA Flash

Minimum recommended system for a partial workstation XPE build: VDX 800MHz CPU, 256MB of memory 1GB Embed disk Flash

Windows NT FEATURES & BENEFITS

Scalable Functionality; Supports Both Workstation and Server Features — Windows NT Embedded can be scaled from a workstation with no GUI to a full-server, based on the requirements of the application. There are four licensing configurations: Headless Workstation, Full Workstation, Headless Server, and Full Server.

Authoring Tool Set — Windows NT offers a broad spectrum of functionality with many opportunities for "componentization". To take advantage of this, Windows NT Embedded includes an authoring tool set that is currently composed of two tools, the Target Designer and the Component Designer. The Target Designer is the primary authoring tool, allowing you to define the target configuration of the OS and build the run-time environment for the device. While the Target Designer defines the set of files and configuration information to be included on the target system, the Component Designer allows you to define elements of the OS into components. One or more components comprise a capability and capabilities are grouped together to form overall system

configurations. It is the inclusion or exclusion of components that ultimately determines the feature-set of the embedded target. Using the familiar Windows NT user interface, the tool set guides you through the process of profiling, defining, and generating customized software system.

Headless support — this enables Windows NT to be used in devices that boot and run without a mouse, keyboard or display device. Many embedded systems do not expose either a traditional user interface (e.g. Windows-based or DOS-based PC) or, in many instances, any local user interface whatsoever. Windows NT requires a display driver to interface between the graphics sub-system and the video hardware. All currently available video display drivers assume and rely on the existence of underlying video hardware. Windows NT Embedded does not require this.

Read-Only Boot Support — many embedded devices utilize ROM to support stateless operation, lower the unit cost and improve reliability. Windows NT Embedded supports a variety of read-only media for boot-strapping itself in a manner that is transparent to the applications and system binaries that access the media.

Solid-State Media Support — Due to environmental factors such as shock or vibration, many embedded devices use bootable non-volatile storage media with no moving parts to increase mean time between failure (MTBF) ratings and to improve overall device robustness. NT Embedded supports solid state disks and flash memory.

Remote Management — in an embedded system, access to the operating system and/or application is often through a remote system of some type, since a user interface on the device itself does not exist or is not practical to access. Windows NT Embedded provides both character-mode and graphical management solutions using serial, dial-up, and network connections.

Error Recovery — Robustness and fault-resilience have always been design criteria of Windows NT. For example, Windows NT possesses characteristics such as protected virtual memory and object-based security. Many embedded applications have more extensive error recovery requirements since they are often used in 7/24 an application in which operator intervention and assistance is not practical. Windows NT Embedded solves the issues associated with "blue screens", the communication of error conditions normally displayed on the console that require user interaction. These errors can not only be logged, but can be used to trigger application software events.

TECHNICAL OVERVIEW

A developer configures a device-specific NTE image by using Target Designer to select the Windows NT binaries needed by the application, the binaries associated with the special NTE features required by the application, and the application itself. In some cases, Component Designer is needed to recreate reusable components not found in NTE (e.g. device drivers). Once created, new components are imported into Target Designer, dependencies are checked, and an OS image is built that can be downloaded onto the device.

Windows NT Embedded does not compete with Windows CE but rather provides a complementary choice for embedded developers. There are a number of design considerations that will help to select the best version of Windows for your device:

§ Platform

Windows NT Embedded is currently only available for Intel Pentium and compatible microprocessors. Windows CE supports X86 microprocessors as well as RISC processors such as MIPS, ARM and StrongARM, SHx, and PPC.

§ Footprint

If a device needs a small footprint, Windows CE is the best choice, requiring as little as 4MB of RAM. Windows NT Embedded requires a device with the specifications listed below:

Class 1 — Headless Workstation

Standard Install

Memory: 32 to 256 MB of RAM Storage (min.): 128 MB (Build size is about 92 MB.)

Specialized Install

Memory: 16 to 256 MB of RAM Storage (min.): 32 MB (Build size is about 32 MB.)

Class 2 — Standard Workstation

Standard Install

Memory: 32 to 256 MB Storage (min.): 128 MB (Build size is about 90 MB.)

Specialized Install

Memory: 16 to 256 MB Storage (min.): 32 MB (Build size is about 30 MB.)

Windows NT Embedded supports up to 256 MB of RAM Maximum.

§ Feature Set

Windows CE is the best choice if the device requires semi-real-time capabilities, instant on, and the ability to operate in a disconnected state. Windows NT Embedded would be the better choice if the device requires the full Win32 API, built-in networking, Windows NT security, remote administration and management, POSIX support, and extensive device driver support. Real-time capabilities for NT and NT Embedded can be added using third party solutions. There is no USB support for Windows NT Embedded, all drivers for USB support must be custom written.

Windows CE

The Windows CE operating system is a 32-bit, multitasking, multithreaded operating system that has a scalable, open architecture design, providing support for a variety of devices. Windows CE is compact, providing high performance in limited memory configurations,

supporting a range of embedded, mobile or multimedia product lines. Windows CE also has integrated power management, enabling long battery life on mobile devices. Standard communications support is built into Windows CE, enabling access to the Internet to send and receive e-mail or browse the World Wide Web. A graphical user interface incorporating many elements of the familiar the Desk-Top Windows user interface is also available, facilitating ease-of-use for end users.

KEY FEATURES & BENEFITS

Sub-set of Win32 API – Windows CE supports more than 700 of the most-frequently-used Win32 APIs, enabling developers to take advantage of vast amounts of third-party programming resources, tools, software examples, and documentation for their Windows CE-based development. With more than 500,000 developers worldwide using Win32, there are many experienced programmers who already know how to develop for the Microsoft Windows CE platform, which lowers training costs and shortens your time to market.

Low-cost, familiar development tools – Windows CE requires two inexpensive, basic development tools. The first development tool is for the operating system itself: Platform Builder which is required if you are generating your own build. If you have EMAC generate your build you will not require this relatively expensive and difficult to use tool. Platform Builder contains all of the cross-compilers, assemblers, remote debugger tools, boot loaders, sample device drivers (keyboard, LCD, serial, IrDA, touch screen, etc.), sample platforms, and operating system components. The second development tool Windows Visual Studio is used for developing applications.

Scalable, full-featured operating system – Windows CE can be customized for a product by selecting from a set of available software modules. In addition, some of the modules are componentizable, which means that you can further customize the modules by selecting from a set of available components for that module. Because the Windows CE operating system is componentized, you can design embedded system platforms using the minimum set of software modules and components needed to support the platform's system requirements. This minimizes the memory footprint and maximizes performance of the operating system. Windows CE scales from a kernel to a full-featured OS with networking and GUI.

Extensive and Extensible Device Support – Windows CE directly supports many kinds of hardware peripherals and devices, such as keyboards, mouse devices, touch panels, serial ports, Ethernet, modems, USB devices, audio devices, parallel ports, printer devices, and storage devices (ATA or flash media). At the same time, as Windows CE extends to new industries and device categories, there is tremendous potential for embedded developers to easily add new device types and peripherals. This is made possible through the simple and well-defined Windows CE Device Driver model, which provides a well-documented set of device driver interfaces (DDIs) and sample code that demonstrates implementation. This model enables embedded developers (both OEMs and IHVs) to easily implement their own driver software for a variety of devices that run on the Microsoft Windows CE platform.

Wide microprocessor support – Currently supported processor architectures include: NEC, Philips, Toshiba MIPS 39xx and 4xxx, Motorola PowerPC 821, 823, 850, 860, Hitachi SH3 and SH4, Intel 486 and Pentium (and compatibles: AMD, Cyrix, SGS Thomson), ARM, and Intel X-Scale. The wide choice enables OEMs to select architecture with the best price/performance for their specific application. New processors are being added

regularly. For the complete list of supported processors, including specific model numbers, visit the Microsoft Windows CE website.

TECHNICAL OVERVIEW

OEM Adaptation Layer (OAL)

Windows CE is adapted for a specific hardware platform by creating a thin layer of code that resides between the kernel and the hardware platform. This layer is known as the OEM Adaptation Layer (OAL). The OAL isolates device-specific hardware features from the kernel. The Windows CE kernel, in turn, contains processor-specific code to handle processor core functions. The OAL is specific for a particular CPU and hardware platform.

The primary purpose of the OAL is to expose the target platform's hardware to the kernel. This includes managing the hardware's timers and device interrupts, and implementing power management across the device's peripherals. Windows CE handles interrupts by associating each hardware interrupt request line (IRQ) with one interrupt service routine (ISR). When interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt. The ISR, the kernel-mode-portion of interrupt processing, is kept as short as possible. Its responsibility is primarily to direct the kernel to schedule and launch the appropriate interrupt service thread (IST). The IST, implemented in the device driver software module, gets or sends data and control codes from or to the hardware and acknowledges the device interrupt.

Device Drivers

§ Built-in support for the keyboard, touch panel, notification LED, display, audio (including Sound Blaster™), battery drivers, and a rapid development model that allows these devices to be ported quickly to your platform.

§ Support for wireless and wireline Ethernet LAN connectivity

§ Statically replaceable keyboard layout § Extended interrupt processing interface or

device drivers based on the Win32 event model § Network printing § Support for serial and parallel devices § Host support for Universal Serial Bus (USB)

devices § PCMCIA Card and Socket Services for

removable or built-in storage cards

Kernel

§ Multi-threaded; preemptive multitasking § Preemptive priority-based thread scheduling

based on the Win32 process and thread model; supports eight levels of thread priority

§ Support for priority inheritance to correct priority inversion

§ Demand paging supported by ROM, RAM, and FAT file systems

§ Execute in place from ROM § Support for synchronization objects

(WaitForSingleObject, WaitForMultipleObjects) § Low ISR and threat latency § Portable across microprocessors § Heap size that is limited only by available

memory

Object Store

§ Available object stores include file systems, registry, and database

§ Database provides storage and retrieval of database records, with up to four sort keys and support for transaction logging and rollback

§ File System § Access is through Win32 API § Supports FATFS, including multiple FAT

volumes (up to 99 volumes) § Installable block Device Drivers (ATA Flash and

SRAM drivers included) § True Flash File System support § Installable file systems § Databases on mounted file systems

Registry

§ Win32-like registry § Access is through Win32 Registry API

GDI and USER

§ Configurable from nothing to full-blown GDI & User, with intermediate points:

§ display-less, message passing (mininput)

§ graphics but no windowing (mingdi) § minimalist window manager

(minwmgr) § GDI - resolution-independent graphics § Raster and TrueType Font support o1 to 32 BPP

Color Pixel depths w/ palettes § Printing (device-side rendering) § User - windowing, dialogs, messaging § Additional: Controls, clipboard, cursors, caret,

idle time out, hot keys, etc. § GDI and user export a subset of the Win32 API

Communications Support

§ Windows Sockets APIs § WinInet with FTP, HTTP and HTTPS support § Secure Sockets Layer (SSL) with Server Gated

Cryptography support § TCP/IP, PPP, SLIP, and IrDA, including Fast IR § TAPI modem support § Serial APIs § Direct connection, dial-up and device-to-device

connectivity § LAN connectivity using NDIS and Microsoft

Network client software (to access remote file and print servers)

§ Remote access services (RAS) to support remove connectivity

§ Remote debugging over LAN, serial or parallel connections

§ Built-in support for communication hardware (built-in modems, Ethernet chips, etc.)

§ Windows NT® LAN Manager-based authentication

Remote Connectivity

§ Remote networking § Direct connection to PC § Dial-up access to Internet, PCs, and Servers

Shell

§ Includes a minimum shell that supports application launching and switching

§ The shell can be included to serve as the basis of an embedded application

§ Key UI components included to allow rapid development of custom embedded shells

Internationalization/Localization

§ Support for localization of the operating system, including built-in support for French, German, Italian, Portuguese (Brazilian), Spanish, Dutch, Swedish, Japanese and Chinese (Beta)

§ Far East text support § Input Method Manager, Input Method Editor,

and Soft Input Panel § UNICODE support § Support for the national language support (NLS)

API, which allows system and user locales

Additional Component Features

§ ActiveX® and COM/OLE § Microsoft Virtual Machine for Java for Windows

CE § Microsoft Foundation Classes for Windows CE

WINDOWS CE - Based HARDWARE REQUIREMENTS

At a minimum, a Windows CE-based device must have a supported processor, memory and an internal timer for scheduling. No other hardware is specifically referenced by the operating system, but most devices will have a number of peripherals.

Windows CE is a small-footprint, flexible operating system. The memory needed by a Windows CE-based system is totally dependent on which components the designer of the system selects. A Typical CE build may require 32 Meg of Flash and 32 Meg of RAM.

7. Commercial RTOS brands Among commercial embedded operating systems, Wind River's VxWorks was the undisputed leader, as shown in Figure 6. With more than 25% of all the votes, it scored particularly well in avionics applications (where it ranked well above average) but somewhat poorer in automotive, computer-related, and industrial segments (where it scored well below average). Its popularity was insensitive to age but was strongly correlated to company size, with larger development firms using VxWorks much more frequently than small companies.

Tied for second place are the Microsoft twins, Windows XP for Embedded and Windows CE (there were separated by one vote). In a predictable reversal, WinXP and WinCE were most popular where VxWorks was weakest: industrial and computer-related applications. XPe was especially strong in manufacturing industries, where VxWorks also made a good showing. In the number four spot we have Texas Instruments' DSP/BIOS, a product with obvious hardware ties. That's followed by Red Hat's Linux, the first of the many Linux variants to make the list. After that, the numbers all drop to below 8%. QNX, RTX, C/OS, and Mentor Graphics' Nucleus RTOS head the list of

several popular embedded OSes with single-digit market shares. ThreadX is deliberately listed twice: once for the Green Hills distribution and once for Express Logic's product. Oddly, Green Hills appears to sell more copies of ThreadX than the company that developed it. Looking ahead, we asked those same survey takers what OS they'd consider using in their next project. Would they stay with their current OS or switch to another? We also asked non-OS users the same question to see if they were considering a commercial OS for the first time. The results are summarized in Figure 7.

The chart shows the delta between the "would consider" responses and the "using now" responses from the previous graph. In brief, the winners lose and the losers win. How is that possible and what does it all mean? First, the responses don't necessarily mean that VxWorks users are unhappy with their current RTOS and are ready to jump to (for example) LynxOS or Wind River's Platform NE Linux. We can't correlate the responses from the first question to the second; the person who said he's using VxWorks now may not be the same person who said he'd consider EPOC in the future. What we can say with certainty is that about 8% fewer people said they'd consider VxWorks compared with the number using it now. Whether or not those are the same people is impossible to tell. Microsoft's two embedded OSes didn't fare well, either. In fact, the eight top choices all lost ground in the game of "guess tomorrow's operating system." Reflecting a kind of Zen balance, almost all of the middle and low scorers gained share of mind in roughly equal proportion to the share lost by the big players. Whether accidentally or by design, the numbers reflect a zero-sum game. This gives us a hint as to the true nature of the data. Recall that more than 28% of embedded projects use no OS at all, and that this proportion has been shrinking steadily for years. Those developers have to go somewhere; what OS will they choose as their first? Logically they're going to choose a smaller, more inexpensive OS over a large and fully featured one. If you're upgrading your system from no OS at all it makes sense to start small. Thus, we see that the smaller RTOS vendors gain share of mind among potential next-generation projects. Will the current commercial vendors lose some customers? Sure, just as every supplier occasionally loses customers to a competitor. But they'll probably gain even more new customers. Nothing sinister lurks in the data here; nothing to trouble the sleep of the friendly neighbourhood RTOS marketing staff. OS loyalty is fairly low anyway. As the chart in Figure 8 shows, more than one-third (36%) of developers are using a different OS than they did in their previous project. Usually that's just because of a change in hardware (44%) or, more ominously, that the new OS was not the developers' choice and was forced upon them.

About two-thirds of the OS defections are what we might call voluntary changes. Twenty-seven percent said they'd switched operating systems because the new one "had better features," with 21% opting for "a better roadmap for growth" and 20% jumping ship for "better development tools." Another 15% said they bailed because the new OS was cheaper. Very few (8%) said their old OS was no longer available and even fewer (6%) switched because they were unhappy with their previous OS supplier. Fewer than 5% switched because the old system was too slow. The overall picture is therefore good for commercial OS suppliers. As the number and type of embedded systems increase, so will the total available market. As in-house and proprietary OS’s slowly ride into the sunset, development teams will be filling the gap mostly with commercial alternatives. And although open-source operating systems are well and truly established, with one-fifth of developers using one now, their growth seems to have flattened. Only about 17% of embedded systems developers would consider Linux who aren't already using it. What's certain is that the variety of embedded systems—and the operating systems that serve them—will continue to flourish.

Conclusion: Embedded Systems will play a key role to drive the technological evolution in the next decades. In this respect they stand on the same level as Nano technologies, bioelectronics, and photonics. The central role of embedded systems in the economy grows stronger and stronger. The starting point is the convergence between storage, security, video, audio, mobility and connectivity. Systems are converging and ICs are more and more converging with systems. This poses a number of

challenges for designers and technologists. A key issue is the definition of the right methodologies to translate system knowledge and competences into complex embedded systems, taking into account many system requirements and constraints. The key factor to win this challenge is to build the right culture. This means to be able to build the right environment to exploit existing design, architectural and technological solutions, and to favour the transfer of knowledge from one application field into another.

Reference:

Requirements Engineering for Embedded Systems1) Manfred Broy Technische Universität München, Institut für Informatik Capturing Requirements for Real-Time and Embedded Systems- Bruce Powel Douglass, Chief Evangelist, I-Logix Razouk, It., Stewart, T. & Wilson, M. (1986) Measuring Operating System Performance on Modern Micro-Processors, In: Perfor-mance 86, ACM, NY, pp. 193-202. DESIGN CONSTRAINTS ON EMBEDDED REAL TIME CONTROL SYSTEMS Philip J. Koopman Jr. Senior Scientist Harris Semiconductor 2525A Wexford Run Rd. Wexford, PA 15090 VHDL vs. Bluespec System Verilog: A Case Study on a Java Embedded Architecture Flavius Gruian, Lund University, Sweden Mark Westmijze, University of Twente, The Netherlands The Minimization of Hardware Size in Reconfigurable Embedded Platforms Nei-Chiung Perng, Genesys Logic, Taiwan Jian-Jia Chen, Swiss Federal Institute of Technology, Switzerland Tei-Wei Kuo, National Taiwan University, Taiwan Chi-Sheng Shih, National Taiwan University, Taiwan Embedded Systems Handbook, ed. R. Zurawski, CRC Press/Taylor & Francis, 2005. Proceedings of the IEEE, Special Issue on Industrial Communication Systems, guest editor R. Zurawski, vol. 93, no.6, June 2005. The Ubiquitious Embedded System-SCMS School of Technology and Management http://wiki.answers.com/Q/What_is_the_difference_between_RTOS_and_OS#ixzz1HLKhzdCP http://wiki.answers.com/Q/Advantages_disadvantages_of_embedded_operating_system#ixzz1HLkFchT6 http://www.control.com/thread/1026205354 Difference Between RTOS and OS | Difference Between | RTOS vs OS http://www.differencebetween.net/technology/difference-between-rtos-and-os/#ixzz1HLm3zaC5 http://belhob.wordpress.com/2007/10/12/rtos-vs-general-purpose-os/ http://www.emdebian.org/about/why.html http://www.microsoft.com/windowsembedded/en-us/develop/windows-embedded-products-for-developers.aspx http://www.answers.com/topic/embedded-system http://www.netrino.com/Embedded-Systems/Glossary http://embedsoftdev.com/ http://www.microcontroller.com/ http://www.flexerasoftware.com/promolanding/embedded-software-licensing.htm?gclid=CJf6wuz24qcCFUdP4QodFngV-A http://www.ni.com/academic/embedded.htm http://www.esacademy.com/

Assessment of Technical Report

Student’s name Mark overall Dinuka Wijesinghe

Criterion Weight

Demonstration of knowledge and understanding

25

Critical evaluation 30

Breadth and appropriateness of references (properly referenced) and bibliography

30

Presentation (in terms of structure) Grammar and Spelling

15

TOTAL

Comments.