Embedded operating systems
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Embedded operating systems

on

  • 11,763 views

 

Statistics

Views

Total Views
11,763
Views on SlideShare
11,762
Embed Views
1

Actions

Likes
8
Downloads
415
Comments
1

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Embedded operating systems Document Transcript

  • 1. Embedded Operating Systems Dinuka Wijesinghe B00538290 University of Ulster, Jordanstown Systems Software COM 332 Assignment 2Abstract installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to veryThis paper presents a comprehensive in-depth study of high with multiple units, peripherals and networksEmbedded Operating Systems. This includes mounted inside a large chassis or enclosure.discussing typical requirements, constraints, andapplications of embedded systems. Typical characteristics , Typically, embedded systems are Reactive and Real timeissues and design requirements for an embedded systems. A Reactive system is one, which is in continualoperating systems and the relative advantages and interaction with its environment and executes at a pacedisadvantages of developing an embedded operating determined by that environment.system based on modifications to an existing operatingsystem compared to the development of a purpose-built Embedded system is application-oriented specialembedded operating system. This section should make computer system which is scalable on both software andreference to commercially available embedded operating hardware. It can satisfy the strict requirement ofsystems. functionality, reliability, cost, volume, and power consumption of the particular application.Keywords: Requirements engineering, specification,Embedded Operating Systems With rapid development of IC design and manufacture, CPUs became cheap. Lots of consumer electronics have embedded CPU and thus became embedded systems. For 1. Introduction 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 theLike the familiar Microwave Oven, an Embedded System is embedded system market. Some report expects that thedesigned to perform some dedicated function. A demand on embedded CPUs is 10 times as large as generalcombination of hardware and software, it forms an purpose PC CPUs.embedded part of a complete device. Since an Embeddedsystem has a limited range of applications, design As applications of the embedded systems become moreengineers face no problem to optimize both size and cost complex, the operating system support and developmentor enhance reliability and quality of performance. environment became crucial.Embedded systems range from portable devices such asdigital watches and MP3 players, to large stationary Figure 1: Generic embedded system.
  • 2. 2. Uses of Embedded Systems Characteristics • Embedded Systems are designed to do some specific task, rather than be a general-purposeThere are endless uses for embedded systems in consumer computer for multiple tasks. Some also have real-time performance constraints that must beproducts, with new methods of exploiting them presented met, for reason such as safety and usability;every year at such industry events as the MEDC and the others may have low or no performanceEmbedded Systems Conference. The most obvious requirements, allowing the system hardware tobeneficiaries are those enterprises concerned with the be simplified to reduce costs.manufacture and sale of electrical devices, as the inclusionof microcontrollers to replace general purpose • Embedded Systems are not always separatemicroprocessors can drive down unit manufacturing costs devices. Most often they are physically built-in to the devices they control.and end user prices dramatically, resulting in increasedsales and an improved profit margin. • The software written for embedded systems isThe use of embedded systems in electrical products can often called firmware, and is stored in read-onlyalso solve many problems of complexity and product size. memory or Flash memory chips rather than aFor example, a modern automobile may contain dozens of disk drive. It often runs with limited computerembedded systems to control a wide range of processes hardware resources: small or no keyboard,within the car, ranging from brake balance control to air screen, and little memory.conditioning to the ignition system. Without embedded • Must be dependable. Reliability R (t) =systems it would be impossible to computerise all of these Probability of system working correctly providedfeatures without the inclusion of a mass of complicated, that it was working at t=O. Making the systemfault prone electronics. dependable must not be an afterthought, it must be considered from the very beginningThe only realistic alternative to using embedded systemsin a modern automobile would be to install a fullyfunctional PC within the car to control all of the functions • Maintainability M (d) = Probability of systemcurrently managed by microcontrollers. working correctly d time units after error occurredExamples: • Availability A (t): Probability of system working • Audio like mp3 players and telephone switches at time t. for interactive voice response systems • Avionics, such as inertial guidance systems, flight control hardware/software and other • Safety: No harm to be caused. integrated systems in aircraft and missiles • Cellular telephones and telephone switches • Security: Confidential and authentic communication. Even perfectly designed • Electric or Electronic Motor controller for systems can fail if the assumptions about the Brushless DC motors, Induction motors and DC workload and possible errors turn out to be Motors wrong. • Engine controllers and antilock brake controllers for automobiles • Home automation products, such as • Must be efficient thermostats, air conditioners, sprinklers, and Energy efficient Code-size efficient (especially for systems on a security monitoring systems chip) • Handheld calculators Run-time efficient • Household appliances, including microwave Weight efficient ovens, washing machines, television sets, DVD Cost efficient players and recorders • Dedicated towards a certain application. • Medical equipment Knowledge about behaviour at design time can • Personal digital assistant be used to minimize resources and to maximize • Videogame consoles robustness. • Computer peripherals such as routers and printers • Dedicated user interface. (No mouse, keyboard • Industrial controllers for remote machine and screen) operation • Many Embedded System must meet real-time • Digital musical instruments (digital synthesizers constraints and digital pianos). • Security applications such as DVR and video • Frequently connected to physical environment server through sensors and actuators, Dortmund • The worldwide portable flash player market exploded in 2003 and is expected to grow fromGrowing importance of embedded systems 12.5 rnillion units in 2003 to over 50 rnillion units in 2008 • Worldwide mobile phone sales surpassed 156.4 • Global 3G subscribers will grow from an rnillion units In Q2 2004, a 35% increase from estimated 45 rnillion at the end of 2004 to 85 Q2 2003, rnillion in 2005,according to Wireless World Forum
  • 3. • The number of broadband lines worldwide should behaviour in a variety of circumstances. For increased by almost 55% to over 123 rnillion in example, the 12months to the end of June 2004, according to Point-Topic. · The system shall adjust the angle of the telescope under • Todays DVR (digital video recorders) users - 5% user control of households will grow to 41% within five years · The system shall deliver anaesthetic agent in gaseous • Embedded chips form the backbone of the form to a desired concentration. electronics driven world in which we live they · Locking clamps shall engage when the elevator cable are part of breaks. • almost everything that runs on electricity · The device shall alarm if the heart rate falls to less than • 79% of all high-end processors are used in 30 beats per minute. · The pacemaker shall pace in AAI mode (pace the atrium, embedded systems sense in the atrium, inhibit on an intrinsic heart beat detection).Application areas · The spacecraft shall downlink captured information periodically to the deep space network. • Automotive • Electronics Quality of Service (QoS) requirements specify how well a • Avionics functional requirement shall be accomplished. In real-time • Trains and embedded systems, QoS requirements may specify • Telecommunication properties of the system, e.g. range, speed, throughput, • Medical systems capacity, reliability, maintainability, evolvability, time to • Authentication market, safety, predictability, schedulability; or properties • Military applications of the process. As a rule of thumb, if it’s something that can be quantified, or optimized, then it is a QoS • Robotics requirement. For example (QoS requirements italicized), • Sensor technology • Mobile phones · The angle of the telescope shall be set in units of 0.1 • Mobile base station degrees with a maximum error of 0.01 degrees. • Telecom switch · The anaesthetic agent shall be controllable from 0.00% • Optical O copper connections to 5.00% by volume in units of 0.01% with an accuracy of • Smart welding machine 0.005%. • Sewing machine · 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 3. Requirements 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%, withThere are two kinds of requirements: functional and a single bit error detection/correction rate of 0.9999%quality of service. Functional requirements are and a multiple bit detection/correction rate of 0.99%.requirements about what the system should do and how itIndustrial Requirements Industrial requirements depend on applications; special requirements typically include:
  • 4. • Availability and reliability Need for: •Increased reliabilityAvailability (from Wikipedia): The degree to which a •Robustness •Re-configurabilitysystem, subsystem, or equipment is operable and in a •Maintainabilitycommittable state at the start of a mission, when the •Scalabilitymission is called for at an unknown, i.e., a random, time.Simply put, availability is the proportion of time a system Within the exception of these few common features, rest ofis in a functioning condition. the embedded hardware is usually unique and varies from application to application. Each system must meet aReliability: The IEEE defines it as ". . . the ability of a completely different set of requirements. The commonsystem or component to perform its required functions critical features and design requirements of an embeddedunder stated conditions for a specified period of time." In hardware include:general, in automation, availability and reliability are • Processing power: Selection of the processor isrequired to be very high, to minimize the cost of operation based on the amount of processing power to get(for instance to minimize scheduled and unplanned the job done and also on the basis of registermaintenance) width required. • Throughput: The system may need to handle a • Safety lot of data in a short period of time. • Response: the system has to react to eventsSafety: Absence of catastrophic consequences of a system quicklyfailure for property, humans, and environment • Memory: Hardware designer must make his best estimate of the memory requirement and must make provision for expansion.The (embedded) automation systems and plants have to be • Power consumption: Systems generally work onsafe operational over extended periods of time, even if they battery and design of both software andcontinue operation in a degraded mode in the presence of hardware must take care of power savinga fault. techniques. • Number of units: the no. of units expected to be • Survivability produced and sold will dictate the Trade-off between production cost and development cost • Expected lifetime: Design decisions likeSurvivability: Need for restricted modes of operation that selection of components to system developmentpreserve essential services in adverse operational cost will depend on how long the system isenvironments expected to run. • Program Installation: Installation of the • Security software on to the embedded system needs special tools.Operational IT security requirements: • Testability & Debug ability: setting up test Confidentiality: Protecting data from unauthorized conditions and equipment will be difficult and finding out what is wrong with the software will entities become a difficult task without a keyboard and Integrity: Protecting against unauthorized data the usual display screen. manipulation • Reliability: is critical if it is a space shuttle or a Availability: Data available when needed car but in case of a toy it doesn’t always have to work right. • Real-time, deterministic responseTypically, (networked) embedded systems are required tooperate in a reactive way (for instance, systems used forcontrol purposes) requiring to respond within a predefinedperiod of time, mandated by the dynamics of the process 4. System Limitationsunder control. Most embedded systems place severe constraints on theA response, in general, may be: processor in the terms of requirements for size, weight, power, cooling, performance, reliability, and cost.•Periodic - to control a specific physical quantity by This is because the processor is just a component of aregulating dedicated end-effectors larger system, which has its own operating requirements and manufacturing constraints.•Aperiodic - arising from unscheduled events such as out-of-bounds state of a physical parameter or any other kind Size and Weightof abnormal conditions. Size and weight restrictions can greatly limit the complexity of the hardware which can be brought to bear • Power consumption on solving a particular embedded control problem. Platforms such as aircraft, spacecraft, and portableLow-power design: extending life time of electronic equipment may have strict weight limitations. Most othercomponents (lifecycle). Wireless sensor networks need for applications also have size limitations of some sort. Aself-sustained energy source. typical embedded controller may have a size budget of a few cubic inches, and a weight budget of a few pounds (includingSources of wireless power: the power supply requirements).•Batteries, fuel cells, etc. The problem with size and weight restrictions is that•From local environment: light, heat, vibration, high performance processing systems tend to be larger and•Transmitted by optical and radio frequencies, sound heavier than slower systems. At the CPU level, a processor that has a large number of pins takes up a large printed • Lifetime issues 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.Typical lifetime of a device in an industrial environment is The key to the size and weight issue is keepingaround 10 - 20 (plus) years component count small. This is best accomplished by using
  • 5. the highest integration level possible. But, even with Embedded processing applications are notorious forcustom VLSI chips and surface- mount technology the extreme operating conditions, especially in automotivefact remains that in embedded system, high complexity and military equipment. The processing system must dealmeans problems with size and weight budgets. The with vibration, shock, extreme heat and cold, and perhapssmallest systems are those which have on-chip memory for radiation. In remotely installed applications, such assome or all of the system requirements, do not require spacecraft and undersea applications, the system must beexternal support chips (especially cache memory support), able to survive without field service technicians toand which allow small, efficient encodings of programs. make repairs. The general techniques used for avoiding problems causedPower and Cooling by operating environments are to keep the component count and number of pins as low as possible. It is alsoThe processor complexity can affect the power helpful to keep the systems cool as possible to inhibit agingconsumption of the system. High power consumption of the systems components.increases the size and weight requirements of the powersupply. Since essentially all power consumed by a Costcomputer is eventually given off as heat, increased powerconsumption results in increased cooling requirements. The cost of the processor itself may be very important to The amount of power used by the processor is related low- and medium-performance systems, especiallyto the number of transistors and pins on the processor consumer electronics products. Since the cost of a chip ischip. Processors that rely on exotic process technology for related to the number of transistors and to the number ofspeed usually consume too much power to be useful. pins on the chip, low complexity processors have anProcessors that need huge numbers of power consuming inherent cost advantage.high speed memory devices likewise can exceed a power In high-performance systems, the cost of the processorbudget. may be overwhelmed by the cost of the multi-layered Consequently, CMOS components are usually used printed circuit boards, support chips, and high-whenever possible. Newer CMOS technology runs at high speed memory chips. In these cases, overall systemspeed, yet dissipates little power in comparison to other complexity must be reduced to keep system costs down.technologies. Static CMOS is often selected because it canoperate with a slow or stopped clock to save power when thesystem is idle. Architectural FeaturesComputing Performance Many of the computer architects techniques to improve system performance, such as cache, branch targetComputing performance in a real time embedded control buffers, and pre-fetch queues, work on statisticalenvironment is not simply an instructions per-second principles. They assume things such as temporal andrating. While raw computational performance is spatial locality, which tend to be true on large workstationimportant, other factors which are vital to system programs when run for long periods of time. They giveperformance include interrupt response characteristics, relatively uniform performance when used in a CAD orcontext switching overhead and I/O performances. Since office automation environment.real time tasks are characterized by frequent, often However, the constraints of hard real time controlunpredictable events, the performance of a processor at applications have requirements which make standard,handling interrupts is crucial to its suitability for real time statistically good speedup techniques inappropriate. Realprocessing. Since a control application usually involves a time control of periodic events requires absolutereasonable amount of communication with the outside predictability, often down to a single clock cycle. Deadlinesworld (such as reading sensors and activating control must be guaranteed to be met 100% of the time. Having acircuits), good IJO performance is also important. situation where an unfortunate interaction between Two key considerations for more difficult real time two different routines contending for cachecontrol applications are predictability and determinacy. memory causes an increase in cache misses is simplyPredictable systems have behavior at run-time that is unacceptable. In a tightly scheduled environment, even theeasily understandable from examination of the original time taken by a single cache miss can cause a missedsource code program; deadline.In other words, there are no surprises to a user of average Inappropriate Architectural Featuressophistication. Deterministic systems hove instructionswhose behavior does not vary; in other words, the There are many reasons that an architectural feature isexecution speed of an instruction does not depend on included in a processor. Today, usually the feature isexecution history of the program. For real time control added in order to support "general purpose" computing,with hard deadlines, a designer must be able to predict which usually means engineeri n g w o r k s t a t i o nwith absolute certainty the running time of the piece of a p p l i c a t i o n p r o g r a m s . T h e problem is that this definition of "general purpose" is often at odds withcode responding to an external event. If a system has requirements for the systems we have just described. Thevariable performance elements, such as cache memory, the list of architectural features that are inappropriatedesigner must be extremely pessimistic about the for hard real time embedded control systems seemsperformance of these features, and plan on the worst case. similar to a catalogue of modern processor design techniques. They are listed here along with a briefIn some systems, it is important to exactly determine the explanation of the problems they can cause. The focus heretime for a sequence of instructions to execute, with no is on determinism and predictability, although the readerpossibility for variation allowed. Processors with should not forget that most of these features also contribute substantially to system complexity as well.extremely consistent execution speeds can use software toreduce system complexity by replacing hardware such asUART chips, disk controller chips, or video memory se- Cache memory: Data and instruction cache m e m o r i e squencers with programmed transfers using carefully timed a r e t h e b i g g e s t s o u r c e s o f u n p r e dictability andcode. indeterminacy. Modern compiler technology is just beginning to address the issue of schedulingSince program memory space may be extremely limited, instruction cache misses. Furthermore, it isprograms may be highly compacted by using subroutine impossible to characterize data cache misses for programscalls to reuse common code sequences. In fact, many of interesting complexity. Because the time required toembedded applications use threaded languages such as process a cache miss is approximately an order ofForth because they produce exceedingly compact code. magnitude slower than the time required for a cache hit,This suggests that an embedded processor should have significant execution speed degradation takes placeefficient support for subroutine calls as a means of with even a small percentage of cache misses. Figure 1conserving program memory. shows relative execution time variations that may take
  • 6. place with varying numbers of cache misses. In this memory in turn either requires the use of cache memoryfive-instruction example, assuming that a cache or a significant expense in making all program memorymiss costs five clock cycles, execution time may vary out of cache-grade memory chips for high guaranteedbetween 5 and 25 clock cycles for the same code. In hard system performance.real-time systems, often the worst case of all cache missesmust be assumed for time-critical sections, resulting Variable length execution times of instructions: Manyin designing hardware with only fast static memory instructions can take a variable number of clock cycles tochips that render the cache management hardware super- execute, often depending on the data input to thefluous. On-chip caches add to system debugging concerns instruction. An example of such an instruction is abecause they are often not visible outside the chip. multiply routine that has an "early-out" feature.Low semantic content of instructions: Low semanticcontent of instructions greatly increases the number of Write buffers: Write buffers allow the CPU to perform ainstructions that must be executed to accomplish a given write to memory without pausing for an actual memorytask. This, in turn, increases demands for high-speed cycle to take place. The problem is that this write must thenmemory. A requirement for large amounts of high speed wait for spare bus cycles.If no spare bus cycles are forthcoming, the processor number of wait states or cache misses in programmust be stalled when the write buffer overflows. memory. For example, if there is latency for filling anAdditional stalls can be caused if a memory read could empty pre-fetch queue, adding a one- cycle wait statepossibly correspond to a memory location that has yet that causes the pre-fetch queue to be emptied may addto be updated by the write buffer. Interaction between more than one clock cycle to program execution time.the write buffer and cache misses for instruction anddata fetches can cause indeterminacy in programexecution. Pipelines: Deep instruction pipeline increases interrupt response latency. Even if the first instruction of anBranch target buffers: This is a special case of an interrupt service routine can be inserted into theinstruction cache, in which past program execution pipeline within one clock of the interrupt being asserted, ithistory is used to cache instructions at branch targets for still takes several clock cycles for the instruction toquick access. This type of instruction cache operates pass through the pipeline and actually do its job. Ain a manner dependent on input data, and so is pipeline also requires some sort of handling ofbeyond the ability of compilers to manage effectively. data dependencies and delays for memory access, whichBranch target buffers are sometimes used in results either in compiler-generated flops, instructionconjunction with branch prediction strategies, in which rearrangement, or hardware-generated pipelinethe compiler encodes a guess as to whether a stalls. All of these dependency-resolution techniquesparticular branch is likely to be taken into the decrease predictability, determinacy, or both.instruction itself, causing either the branch target orthe next consecutive instruction to be fetched beforethe outcome of the branch is resolved. The actual time Pure load/store architectures: Load/store RISCto perform a branch then depends on whether the architectures can by their very nature makes nocompiler guessed the branch outcome correctly, and provision for atomic read/modify/write instructions. Thiswhether the branch target buffer value corresponds to generally required the addition of external hardwarethe guess made by the compiler. for implementing semaphores, locks, and other inter-process communication devices, increasingPre-fetch queues: Pre-fetch queues greatly affect the system complexity.predictability of execution because the execution timefor an instruction depends on whether or not the Scoreboards: Scoreboards attempt to speed up programpreceding instructions were slow enough to allow the execution by allowing several instructions to be inpre-fetch queue to accumulate new instructions. Thus, execution concurrently. Score boarding usually impliesdetermining whether a particular instruction will out-of-order execution, which may make it impossible toexecute quickly from the pre-fetch queue or slowly from correctly determine the correct system state in the event ofprogram memory requires cycle counting of several an exception or interrupt (the term usually used herepreceding instructions to see if spare memory cycles would is that the system has imprecise interrupts).have been available for the pre-fetch queue to fill. This Furthermore, the execution time of an instructioncycle counting is subtly affected by data-dependent depends on the resources being used by the previousexecution paths through the program as well as the several instructions, and can vary considerably.
  • 7. Supers cater instruction issue: Newer-generation implies the use of a cache memory to performmicroprocessors are beginning to implement address translation (a Translation Look aside Buffer),"superscalar" instruction execution, in which multiple which has the same problems as other caches. If ainstructions may be issued in a single clock cycle. disk-paging system is used, the problem of speedUnfortunately, the number of instructions that may be degradation can become much worse than for simpleissued depends on the types of the instructions, the cache misses.available hardware resources, and the executionhistory of the program. All these factors make it Use of DRAM access technology: Some processorvery difficult to determine any single instructions implementations exploit special access techniques toexecution time. DRAM chips in order to achieve high average throughput with a low system coat. The use of static- column, paged, and video DRAMs creates realDependence on sophisticated compiler technology: Most problems in predictability because access to theseRISC designs depend implicitly on complex and DRAMs becomes much slower whenever page boundariesambitious optimizing compilers for fast op erating must be crossed. The use of DRAM memory chips alsospeeds. This t radeoff between hardware and requires performing memory refresh, which cansoftware complexity is a part of the RISC design interact with other accesses to cause performancephilosophy. The problem is that the optimizing compilers degradations that are worse than expected.make it difficult to establish a correspondence betweensource code and the code that actually is executed Autonomous I/O processors: The use ofbecause of the large number of program transformations autonomous I/O processors and DMA hardware thatperformed. This c o m p l i ca t es p r o g ra m d eb u g g i n g , steal bus cycles can cause non-determinism as thea s w el l a s decouples the programmers source code processor is stalled for bus accesses. Consequently, it ischanges f ro m eff ect s on f in a l p ro g ra m sometimes desirable to perform I/O directly from thep erf o rm a n ce, decreasing predictability. A surprising CPU.side-effect of the complexity of these compilers is thatthey add a level of indeterminacy in the mapping ofsource to object code. The use of heuristics for The Challenge to Processor Designersblock-level and global optimization techniques canactually cause the same exact sequence of source code The above list of architectural characteristics containsstatements to generate significantly different object code elements of design found in virtually every RISC orin two places of the same program module (Razouk CISC processor made today. These architecturaletal. 1986). characteristics are truly valuable for speeding up average system performance, especially in workstationLarge register file: The use of a large number of environments. The problem is that hard embeddedregisters allows programs to execute quickly, hut real time control applications do not have the samegreatly increases the amount of information (the characteristics and requirements as workstation-basedmachine state) that must be saved on context switches and engineering design applications, and so theseinterrupts. This adversely affects responsiveness to characteristics actually hurt s ystem p erformance.external events. Therefo re, what is needed are new CPU designs that make tradeoffs in favor of the requirements of real time embedded control, even at the expense of performance ofVirtual memory: The use of virtual memory workstation-type applications. 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 5. Embedded OS vs. General behaviour was simply not a design goal for these general- computing operating systems. Purpose OS 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-independentThe key difference between general-computing operatingsystems and real-time operating systems is the need for timing: In other words, the algebraic formula is as simple“deterministic " timing behaviour in the real-time as: T(message send) = constant , irrespective of the lengthoperating systems. Formally, "deterministic" timing means of the message to be sent, or other factors such as thethat operating system services consume only known and numbers of tasks and queues and messages beingexpected amounts of time. In theory, these service times managed by the RTOS.could be expressed as mathematical formulas. These Many RTOS proponents argue that a real-time operatingformulas must be strictly algebraic and not include any system must not use virtual memory concepts, becauserandom timing components. Random elements in service paging mechanics prevent a deterministic response. Whiletimes could cause random delays in application software this is a frequently supported argument, it should be notedand could then make the application randomly miss real- that the term "real-time operating system" andtime deadlines – a scenario clearly unacceptable for a real- determinism in this context covers a very wide meaning,time embedded system. Many non-real-time operating and vendors of many different operating systems applysystems also provide similar kernel services. these terms with varied meaning. When selecting an operating system for a specific task, the real-time attributeGeneral-computing non-real-time operating systems are alone is an insufficient criterion, therefore. Deterministicoften quite non-deterministic. Their services can injectrandom delays into application software and thus cause behaviour and deterministic latencies have value only ifslow responsiveness of an application at unexpected times. the response lies within the boundaries of the physics ofIf you ask the developer of a non-real-time operating the process that is to be controlled. For example,system for the algebraic formula describing the timing controlling a combustion engine in a racing car hasbehaviour of one of its services (such as sending a message different real-time requirements to the problem of filling a 1,000,000 litre water tank through a 2" pipe.from task to task), you will invariably not get an algebraic
  • 8. Real-time operating systems are often uses in embedded While real-time operating systems are typically designedsolutions, that is, computing platforms that are within for and used with embedded systems, the two aspects areanother device. Examples for embedded systems include essentially distinct, and have different requirements. Acombustion engine controllers or washing machine real-time operating system for embedded systemcontrollers and many others. Desktop PC and other addresses both sets of requirements.general-purpose computers are not embedded systems.The most common operating system for process a huge number of instructions within a given timepersonal computer include Windows from Microsoft, OS X span. Examples of which are computer that scan levels andfrom Apple, and the wide variety of Linux variants that can states in a facility. It is important that the monitors seebe obtained from their respective developers. What most changes occur at the instant that they do.people do not know are Real-time Operating Systems orgenerally referred to by the acronym RTOS. These are Most operating systems use a time sharing architectureoperating systems that are used for more specialized where each task is assigned a small slice of time to executeapplications that demand response that is as close to real its instructions before switching to another task. Thetime as possible. The most significant difference between switching process is too fast that it often appears as realthe two is in how they approach each task. Standard time to users. Some RTOS’s also use this design but withoperating systems focus on doing as much computation in much lower density of tasks to ensure that the processorthe shortest span of time while RTOS’s emphasize on never gets to loaded, which can increase the response time.having a predictable response time. Another design that is used for an RTOS is an event-driven architecture. In this design, the system only switches tasksStandard operating systems are widely used nowadays, once an event or interrupt occurs.partly due to the rapid spread of personal computers.Devices that use standard operating systems, aside from Coding practices for an RTOS is much stricter compared tocomputers and laptops, are also beginning to appear. a standard OS as the code needs to perform consistently allRTOS’s are used in more specialized fields where the the time. Standard OS’s are not that concerned sinceresponse time is much more important than the ability to response time is not of great importance in its application.An RTOS is not required for an embedded system but it A well-architected RTOS will handle these functions muchcan offer powerful advantages to the system developer. more efficiently that a programmer could write the code.Without an RTOS the developer must write his own code RTOS developers are expert in how to handle operations with a minimum of processor cycles.to handle all of these functions. There are many questions when adapting a GPOS (General Purpose Operating System) RTOS:• Enables real-time, deterministic scheduling and task prioritization • What does an RTOS have that a GPOS does not?• Abstracts away the complexities of the processor • How useful are the real-time extensions now• Provides a solid infrastructure constructed of rules available for some GPOSs? and policies • Can such extensions provide a reasonable• Simplifies development and improves developer facsimile of RTOS performance? productivity• Integrates and manages resources needed by Task scheduling communications stacks and middleware Let’s begin with task scheduling. In a GPOS, the scheduler• Optimizes use of system resources typically uses a fairness policy to dispatch threads and• Improves product reliability, maintainability and processes onto the CPU. Such a policy enables the high quality overall throughput required by desktop and server• Promotes product evolution and scaling applications, but offers no guarantees that high-priority, time critical threads will execute in preference to lower-
  • 9. priority threads. For instance, a GPOS may decay the Avoiding priority inversionpriority assigned to a high-priority thread, or otherwisedynamically adjust the priority in the interest of fairness to Even in an RTOS, a lower-priority thread canother threads in the system. A high-priority thread can, as inadvertently prevent a higher priority thread froma consequence, be pre-empted by threads of lower priority. accessing the CPU – a condition known as priorityIn addition, most GPOSs have unbounded dispatch inversion. Generally speaking, priority inversion occurslatencies: the more threads in the system, the longer it when two tasks of differing priority share a resource, andtakes for the GPOS to schedule a thread for execution. Any the higher priority task cannot obtain the resource fromone of these factors can cause a high-priority thread to the lower-priority task. To prevent this condition frommiss its deadlines – even on a fast CPU. exceeding a fixed and bounded interval of time, an RTOS In an RTOS, on the other hand, threads execute in order may provide a choice of mechanisms including priorityof their priority. If a high-priority thread becomes ready to inheritance and priority ceiling emulation. We could notrun, it will, within a small and bounded time interval, take possibly do justice to both mechanisms here, so let usover the CPU from any lower-priority thread that may be focus on a simple example of priority inheritance. Toexecuting. Moreover, the high-priority thread can run begin, we first must look at the blocking that occurs fromuninterrupted until it has finished what it needs to do – synchronization in systems, and how priority inversionunless, of course, it is pre-empted by an even higher can occur as a result. Let us say two jobs are running, andpriority thread. This approach, known as priority-based that Job 1 has the higher priority. If Job 1 is ready topre-emptive scheduling, allows high-priority threads to execute, but must wait for Job 2 to complete an activity,meet their deadlines consistently, no matter how many we have blocking. This blocking may occur as a result ofother threads are competing for CPU time. synchronization – waiting for a shared resource controlled by a lock or a semaphore – or as a result of requesting aPre-emptily kernel service. The blocking allows Job 2 to run until the condition thatFor most GPOSs, the OS kernel is not pre-emptily. Job 1 is waiting for occurs (for instance, Job 2 unlocks theConsequently, a high-priority user thread can never pre- resource that both jobs share). At that point, Job 1 gets toempty a kernel call, but must instead wait for the entire execute. The total time that Job 1 must wait may vary, withcall to complete – even if the call was invoked by the a minimum, average, and maximum time. This interval islowest-priority process in the system. Moreover, all known as the blocking factor. If Job 1 is to meet any of itspriority information is usually lost when a driver or other timeliness constraints, this factor cannot vary according tosystem service, usually performed in a kernel call, executes any parameter, such as the number of threads or an inputon behalf of a client thread. Such behaviour causes into the system. In other words, the blocking factor mustunpredictable delays and prevents critical activities from be bounded. Now let us introduce a third job that has acompleting on time. In an RTOS, on the other hand, kernel higher priority than Job 2 but a lower priority than Job 1operations are pre-emptily. There are still windows of time (Figure 1). If Job 3 becomes ready to run while Job 2 isin which pre-emption may not occur, but in a well- executing, it will pre-empty Job 2, and Job 2 will not bedesigned RTOS, those intervals are extremely brief, often able to run again until Job 3 blocks or completes. This will,on the order of hundreds of nanoseconds. Moreover, the of course, increase the blocking factor of Job 1; that is, itRTOS will impose an upper bound on how long pre- will further delay Job 1 from executing. The total delayemption is held off and interrupts disabled; this allows introduced by the pre-emption is a priority inversion. Indevelopers to ascertain worst-case latencies. fact, multiple jobs can pre-empt Job 2 in this way, resulting in an effect known as chain blocking. UnderTo achieve this goal, the RTOS kernel must be simple and these circumstances, Job 2 might be pre-empted for anas elegant as possible. indefinite period of time, yielding an unbounded priorityOnly services with a short execution path should be inversion, causing Job 1 to fail to meet any of its timelinessincluded in the kernel itself. Any operations that require constraints. This is where priority inheritance comes in. Ifsignificant work we return to our scenario and make Job 2 run at the(For instance, process loading) must be assigned to priority of Job 1 during the synchronization period, thenexternal processes or threads. Such an approach helps Job 3 will not be able to pre-empty Job 2, and the resultingensure that there is an upper bound on the longest non- priority inversion is avoided (Figure 2).pre-emptily code path through the kernel. In a few GPOSs,such as Linux 2.6, some degree of pre-emptibility has been Duelling kernelsadded to the kernel. However, the intervals during whichpre-emption may not occur are still much longer than GPOSs – Linux, Windows, and various flavors of UNIX –those in a typical RTOS; the length of any such pre- typically lack the Mechanisms we have just discussed.emption interval will depend on the longest critical section Nonetheless, vendors have developed a number of real-of any modules incorporated into the kernel (for example, time extensions and patches in an attempt to fill the gap.networking and file systems). Moreover, a pre-empt kernel There is, for example, the dual-kernel approach, in whichdoes not address other conditions that can impose the GPOS runs as a task on top of a dedicated real-timeunbounded latencies, such as the loss of priority kernel (Figure 3). Any tasks that require deterministicinformation that occurs when a client invokes a driver or scheduling run in this kernel, but at a higher priority thanother system service. 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.
  • 10. Unfortunately, tasks running in the real-time kernel canmake only limited use of existing system services in the Modified GPOSsGPOS – file systems, networking, and so on. In fact, if areal-time task calls out to the GPOS for any service, it will Rather than use a second kernel, other approaches modifybe subject to the same pre-emption problems that prohibit the GPOS itself, such as by adding high-resolution timersGPOS processes from behaving deterministically. As a or a modified process scheduler. Such approaches haveresult, new drivers and system services must be created merit, since they allow developers to use a standard kernelspecifically for the real-time kernel – even when (albeit with proprietary patches) and programming model.equivalent services already exist for the GPOS. Moreover, they help address the requirements of reactive,Also, tasks running in the real-time kernel do not benefit event-driven systems.from the robust Memory Management Unit (MMU) Unfortunately, such low-latency patches do not addressprotected environment that most GPOSs provide for the complexity of most real-time environments, whereregular, non-real-time processes. Instead, they run real-time tasks span larger time intervals and have moreunprotected in kernel space. dependencies on system services and other processes thanConsequently a real-time task that contains a common do tasks in a simple event-driven system. For instance, incoding error, such as a corrupt C pointer, can easily cause systems where real-time tasks depend on services such asa fatal kernel fault. To complicate matters, different device drivers or file systems, the problem of priorityimplementations of the dual kernel approach use different inversion would have to be addressed. In Linux, forAPIs. In most cases, services written for the GPOS cannot example, the driver and Virtual File System (VFS)be easily ported to the real-time kernel, and tasks written frameworks would effectively have to be rewritten alongfor one vendor’s real-time extensions may not run on with any device drivers and file systems employing them.another’s real-time extensions. Without such modifications, real-time tasks could
  • 11. experience unpredictable delays when blocked on a by Linux and UNIX – is an important first step. So isservice. As a further problem, most existing Linux drivers providing well-documented source and customization kitsare not pre-empting. To ensure predictability, that address the specific needs and design challenges ofprogrammers would also have to insert pre-emption embedded developers. The architecture of the RTOS alsopoints into every driver in the system. All this points to comes into play. An RTOS based on a microkernel design,the real difficulty and immense scope of modifying a GPOS for instance, can make the job of OS customizationso it is capable of supporting real-time behaviour. fundamentally easier to achieve. In a microkernel RTOS,However, this is not a matter of RTOS good, GPOS bad. only a small core of fundamental OS services (such asGPOSs such as Linux, Windows XP, and UNIX all serve signals, timers, and scheduling) reside in the kernel itself.their intended purposes extremely well. They only fall All other components (such as drivers, file systems,short when they are forced into deterministic protocol stacks, and applications) run outside the kernel asenvironments they were not designed for, such as those separate, memory protected processes (Figure 4). As afound in automotive telemetric systems, medical result, developing custom drivers and other application-instruments, and continuous media applications. specific OS extensions does not require specialized kernel debuggers or kernel gurus. In fact, as user space programs,What about an RTOS? such extensions become as easy to develop as regular applications, since they can be debugged with standardStill, there are undoubted benefits to using a GPOS, such source level tools and techniques. For instance, if a deviceas support for widely used APIs, and in the case of Linux, driver attempts to access memory outside its processthe open source model. With open source, a developer can container, the OS can identify the process responsible,customize OS components for application-specific indicate the location of the fault, and create a processdemands and save considerable time troubleshooting. The dump file viewable with source-level debugging tools. TheRTOS vendor cannot afford to ignore these benefits. dump file can include all the information the debuggerExtensive support for POSIX APIs – the same APIs used needs to identify the source line that caused the problem,Along with diagnostic information such as the contents of Consequently, does the RTOS support primitive graphicsdata items and a history of function calls. This architecture libraries, or does it provide an embeddable windowingalso provides superior fault isolation. If a driver, protocol system that supports 3D rendering, multi-layer interfaces,stack, or other system service fails, it can do so without and other advanced graphics? Can you customize thecorrupting other services or the OS kernel. In fact, GUI’s look-and feel? Can the GUI display and inputsoftware watchdogs can continuously monitor for such multiple languages simultaneously? And does the GUIevents and restart the offending service dynamically, support an embeddable web browser? The browser shouldwithout resetting the entire system or involving the user in have a scalable footprint, and be capable of rendering webany way. Likewise, drivers and other services can be pages on very small screens. It should also support currentstopped, started, or upgraded dynamically, again without a standards such as HTML 4.01, XHTML 1.1, SSL 3.0, andsystem shutdown. WML 1.3.A strategic decision Tool considerationsAn RTOS can help make complex applications both On the tools side, does the RTOS vendor offer diagnosticpredictable and reliable. In fact, the predictability made tools for tasks such as trace analysis, memory analysis,possible by an RTOS adds a form of reliability that cannot application profiling, and code coverage? What of thebe achieved with a GPOS (if a system based on a GPOS development environment? Is it based on an opendoes not behave correctly due to incorrect timing platform like Eclipse, which lets you readily plug in third-behaviour, then we can justifiably say that the system is party tools for modelling, version control, and so on? Or isunreliable). Still, choosing the right RTOS can itself be a it based on proprietary technology? On one point, there iscomplex task. The underlying architecture of an RTOS is no question. The RTOS can play a key role in determiningan important criterion, but so are other factors. Consider how reliable your system will be, how well it will perform,Internet support. Does the RTOS support an up-to-date and how easily it will support new or enhancedsuite of protocol stacks such as IPv4, IPv6, IPSec, SCTP, functionality. And it can support many of the rich servicesand IP filtering with NAT? What about scalability? Does traditionally associated with GPOSs, but implemented in athe RTOS support a limited number of processes, or does way to address the severe processing and memoryit allow hundreds or even thousands of processes to run restraints of embedded systems.concurrently? And does it provide support for distributedor symmetric multiprocessing?GUI considerationsGraphical User Interfaces (GUIs) are becoming 6. Embedded GPOS Examplesincreasingly common in embedded systems, and thoseinterfaces are becoming increasingly sophisticated.
  • 12. Windows XP 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 andBenefits: Windows® XP Embedded is built on upon the ROM. Windows XP Embedded also provides support forproven code base of Windows XP, which features a 32-bit DiskOnChip Flash, PCMCIA-ATA, Compact Flash,computing architecture and a fully protected memory MultiMediaCard, and MemoryStick.model. Key reliability, security, and performance featuresinclude Device Driver Rollback, a pre-emptive Multi- Enhanced Write Filter Enhanced Write Filter (EWF)tasking Architecture, and Encrypting File System (EFS) re-routes selected disk I/O to memory or another storagewith Multi-user Support. medium, thus providing the appearance to the operating system that your read-only storage is writable.By componentizing Windows® XP Professional, WindowsXP Embedded enables developers to use the latest Internet Explorer 6 Provides the latest Web browsingtechnologies the Windows platform has to offer, while at technologies including visual refresh, playback support forthe same time achieving a reduced footprint. Embedded Flash and Shockwave files, and privacy enhancements.developers can take advantage of all the great featuresavailable in Windows XP such as multimedia capabilities. 802.11 Windows XP Embedded supports 802.11 wirelessFeatures include Universal Serial Bus (USB) and Internet LAN technologies that provide high bandwidthExplorer 6.0. connectivity without wires.Windows XP Embedded also includes embedded-enabling 802.1X 802.1X provides secure access to the network tofeatures, such as Flexible Boot and Storage Options, and support wireless LANs and Ethernet. It enablesEnhanced Write Filter. Rich networking capabilities and interoperable user identification, centralizedmanagement features provide Windows® XP Embedded authentication, and dynamic key management and candevices seamless integration with PCs, servers, Web secure both wired and wireless LAN access.services, and other devices. Comprehensive networkingprotocol support includes Infrared Data Association(IrDA) Support, 802.11 and 802.1x, and Universal Plug Infrared Data Association (IrDA) Support Windowsand Play. 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 twoWindows® XP Embedded includes a completely devices are in line sight of each other.redesigned tool set that enables devices based on WindowsXP Embedded to be brought to market faster. The newWindows Embedded Studio streamlines the end-to-end Embedded-Specific Features Windows XP Embeddeddevelopment process enabling developers to rapidly with Service Pack 1 incorporates the latest embedded-configure, build, and deploy smart designs with rich enabling capabilities, focusing on remote deployment andapplications. maintenance scenarios.Features: 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 imageDevice Driver Rollback If issues occur when new downloaded from a server. It also enables Windows XPdevice drivers are added, a copy of the previously installed Embedded-based devices to operate without requiringdriver is saved, enabling a user to roll back to the original persistent storage, such as a hard drive or Flash RAM.device. Device Update Agent Windows XP Embedded withUniversal Serial Bus (USB) Supports a wide array of Service Pack 1 enhances support for in-field servicing withUSB peripherals such as scanners, mice, keyboards, and so Device Update Agent (DUA). DUA is designed to addresson. scenarios where it is necessary to incrementally update or service a Windows XP Embedded device that has beenUniversal Plug and Play (UPnP) Universal Plug and previously deployed to the field.Play (UPnP) is architecture for pervasive peer-to-peernetwork connectivity of devices of all form factors, Footprint Estimator Using Footprint Estimator,including intelligent appliances and wireless devices. embedded developers can now estimate the footprint sizeUPnP is a distributed, open networking architecture that of individual components and their dependencies, as wellleverages TCP/IP and the Web to enable seamless- as macro components, prior to adding them to aproximity networking in addition to control and data configuration. This enables developers to proactively knowtransfer among networked devices in the home, office, and what the impact of a given component will have on theeverywhere in between. image size, thereby avoiding guesswork and saving development time.Pre-emptive Multi-tasking Architecture Designedto allow multiple applications to run simultaneously. System Deployment Image (SDI) Manager: TheIncludes enhancements to ensure great system response System Deployment Image (SDI) service enables you toand stability. quickly deploy run-time images to your Windows XP Embedded-based devices. The SDI feature enables easierEncrypting File System (EFS) with Multi-user staging of runtime images on your developmentSupport Encrypts each file with a randomly generated workstation and preparation of images for fastkey. The encryption and decryption processes are deployment. It also provides an easier method fortransparent to the user. In Windows XP Embedded, EFS transferring the runtime image from the developmentcan allow multiple authorized users access to an encrypted system to the device.document. Multilingual User Interface (MUI) LanguageFlexible Boot and Storage Options In addition to Packs Windows XP Embedded with Service Pack 1 hasmagnetic disk, boot capability is offered for alternative support for over 20 languages. Windows XP Embeddednonvolatile (persistent) read/write storage devices such as MUI Language Packs enable you to save time and effort in
  • 13. localizing your solution for multiple markets by enabling configurations. It is the inclusion or exclusion ofyou to develop your customized operating system image components that ultimately determines the feature-set ofonly once rather than requiring you to localize each the embedded target. Using the familiar Windows NT userversion from the ground up. By simply adding the desired interface, the tool set guides you through the process oflanguage pack to your base English configuration, the user profiling, defining, and generating customized softwareinterface will be localized into your chosen language. system.Hardware Requirements 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 exposeCPU: Computer with 300 megahertz or higher processor either a traditional user interface (e.g. Windows-based orclock speed recommended; Pentium II 233 MHz minimum DOS-based PC) or, in many instances, any local userrequired (single or dual processor system);* Intel interface whatsoever. Windows NT requires a displayPentium/Celeron family, or AMD K6/Athlon/Duron driver to interface between the graphics sub-system andfamily, or compatible processor recommended. Some the video hardware. All currently available video displayslower CPUs are supported but will cause limitations of drivers assume and rely on the existence of underlyingthe build particularly in multimedia applications. video hardware. Windows NT Embedded does not require this.RAM: 256 Megabytes (MB) of RAM or higher (256megabytes recommended) (128 MB minimum supported; Read-Only Boot Support — many embedded devicesbut will limit performance and some features) utilize ROM to support stateless operation, lower the unit cost and improve reliability. Windows NT EmbeddedFlash: 200 megabytes or more of available storage space 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.Video: Super VGA (800 × 600) or higher-resolutionvideo adapter and monitor Solid-State Media Support — Due to environmental factors such as shock or vibration, many embeddedUser Interface: Keyboard and Microsoft Mouse or devices use bootable non-volatile storage media with nocompatible pointing device moving parts to increase mean time between failure (MTBF) ratings and to improve overall device robustness.Typical requirements for a Full standard NT Embedded supports solid state disks and flashworkstation XPE build: A system with a Pentium III memory.or better processor 256MB of memory and at least 2GB offlash for a Full Standard build with SP3 and .Net 3.0 Remote Management — in an embedded system, access toframeworks. Builds running multimedia will require a the operating system and/or application is often through afaster processor and more memory, typically at least remote system of some type, since a user interface on the512MB, to run smoothly. device itself does not exist or is not practical to access. Windows NT Embedded provides both character-modeMinimum recommended system for a Full and graphical management solutions using serial, dial-up,standard workstation XPE build: LX800 500MHz and network connections.CPU, 512MB of memory 4GB of High-speed DMA Flash Error Recovery — Robustness and fault-resilience haveMinimum recommended system for a partial always been design criteria of Windows NT. For example,workstation XPE build: VDX 800MHz CPU, 256MB Windows NT possesses characteristics such as protectedof memory 1GB Embed disk Flash 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 errorWindows NT conditions normally displayed on the console that require user interaction. These errors can not only be logged, butFEATURES & BENEFITS can be used to trigger application software events.Scalable Functionality; Supports Both Workstation and TECHNICAL OVERVIEWServer Features — Windows NT Embedded can be scaledfrom a workstation with no GUI to a full-server, based on A developer configures a device-specific NTE image bythe requirements of the application. There are four using Target Designer to select the Windows NT binarieslicensing configurations: Headless Workstation, Full needed by the application, the binaries associated with theWorkstation, Headless Server, and Full Server. special NTE features required by the application, and the application itself. In some cases, Component Designer isAuthoring Tool Set — Windows NT offers a broad needed to recreate reusable components not found in NTEspectrum of functionality with many opportunities for (e.g. device drivers). Once created, new components are"componentization". To take advantage of this, Windows imported into Target Designer, dependencies are checked,NT Embedded includes an authoring tool set that is and an OS image is built that can be downloaded onto thecurrently composed of two tools, the Target Designer and device.the Component Designer. The Target Designer is theprimary authoring tool, allowing you to define the target Windows NT Embedded does not compete with Windowsconfiguration of the OS and build the run-time CE but rather provides a complementary choice forenvironment for the device. While the Target Designer embedded developers. There are a number of designdefines the set of files and configuration information to be considerations that will help to select the best version ofincluded on the target system, the Component Designer Windows for your device:allows you to define elements of the OS into components.One or more components comprise a capability andcapabilities are grouped together to form overall system Platform
  • 14. Windows NT Embedded is currently only available for supporting a range of embedded, mobile or multimediaIntel Pentium and compatible microprocessors. Windows product lines. Windows CE also has integrated powerCE supports X86 microprocessors as well as RISC management, enabling long battery life on mobile devices.processors such as MIPS, ARM and StrongARM, SHx, and Standard communications support is built into WindowsPPC. 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 Footprint Desk-Top Windows user interface is also available, facilitating ease-of-use for end users. If a device needs a small footprint, Windows CE is the best choice, requiring as little as 4MB of KEY FEATURES & BENEFITS RAM. Windows NT Embedded requires a device with the specifications listed below: Sub-set of Win32 API – Windows CE supports more than 700 of the most-frequently-used Win32 APIs, enabling Class 1 — Headless Workstation developers to take advantage of vast amounts of third- party programming resources, tools, software examples, Standard Install and documentation for their Windows CE-based development. With more than 500,000 developers worldwide using Win32, there are many experienced Memory: 32 to 256 MB of RAM programmers who already know how to develop for the Storage (min.): 128 MB Microsoft Windows CE platform, which lowers training (Build size is about 92 MB.) costs and shortens your time to market. Specialized Install Low-cost, familiar development tools – Windows CE requires two inexpensive, basic development tools. The Memory: 16 to 256 MB of RAM first development tool is for the operating system itself: Storage (min.): 32 MB Platform Builder which is required if you are generating (Build size is about 32 MB.) 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- Class 2 — Standard Workstation compilers, assemblers, remote debugger tools, boot loaders, sample device drivers (keyboard, LCD, serial, Standard Install IrDA, touch screen, etc.), sample platforms, and operating system components. The second development tool Windows Visual Studio is used for developing Memory: 32 to 256 MB applications. Storage (min.): 128 MB (Build size is about 90 MB.) Scalable, full-featured operating system – Windows CE can be customized for a product by selecting from a set of Specialized Install available software modules. In addition, some of the modules are componentizable, which means that you can Memory: 16 to 256 MB further customize the modules by selecting from a set of Storage (min.): 32 MB available components for that module. Because the (Build size is about 30 MB.) Windows CE operating system is componentized, you can design embedded system platforms using the minimum set of software modules and components needed to Windows NT Embedded supports up to 256 MB support the platforms system requirements. This of RAM Maximum. 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 Feature Set GUI. Windows CE is the best choice if the device Extensive and Extensible Device Support – Windows CE requires semi-real-time capabilities, instant on, directly supports many kinds of hardware peripherals and and the ability to operate in a disconnected devices, such as keyboards, mouse devices, touch panels, state. Windows NT Embedded would be the serial ports, Ethernet, modems, USB devices, audio better choice if the device requires the full devices, parallel ports, printer devices, and storage devices Win32 API, built-in networking, Windows NT (ATA or flash media). At the same time, as Windows CE security, remote administration and extends to new industries and device categories, there is management, POSIX support, and extensive tremendous potential for embedded developers to easily device driver support. Real-time capabilities for add new device types and peripherals. This is made NT and NT Embedded can be added using third possible through the simple and well-defined Windows CE party solutions. There is no USB support for Device Driver model, which provides a well-documented Windows NT Embedded, all drivers for USB set of device driver interfaces (DDIs) and sample code that support must be custom written. 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 supportedWindows CE processor architectures include: NEC, Philips, Toshiba MIPS 39xx and 4xxx, Motorola PowerPC 821, 823, 850,The Windows CE operating system is a 32-bit, 860, Hitachi SH3 and SH4, Intel 486 and Pentium (andmultitasking, multithreaded operating system that has a compatibles: AMD, Cyrix, SGS Thomson), ARM, and Intelscalable, open architecture design, providing support for a X-Scale. The wide choice enables OEMs to selectvariety of devices. Windows CE is compact, providing high architecture with the best price/performance for theirperformance in limited memory configurations, specific application. New processors are being added
  • 15. regularly. For the complete list of supported processors, Available object stores include file systems,including specific model numbers, visit the Microsoft registry, and databaseWindows CE website. Database provides storage and retrieval of database records, with up to four sort keys andTECHNICAL OVERVIEW support for transaction logging and rollback File System Access is through Win32 APIOEM Adaptation Layer (OAL) Supports FATFS, including multiple FAT volumes (up to 99 volumes)Windows CE is adapted for a specific hardware platform Installable block Device Drivers (ATA Flash andby creating a thin layer of code that resides between the SRAM drivers included)kernel and the hardware platform. This layer is known as True Flash File System supportthe OEM Adaptation Layer (OAL). The OAL isolatesdevice-specific hardware features from the kernel. The Installable file systemsWindows CE kernel, in turn, contains processor-specific Databases on mounted file systemscode to handle processor core functions. The OAL isspecific for a particular CPU and hardware platform. RegistryThe primary purpose of the OAL is to expose the targetplatforms hardware to the kernel. This includes managing Win32-like registrythe hardwares timers and device interrupts, and Access is through Win32 Registry APIimplementing power management across the devicesperipherals. Windows CE handles interrupts by GDI and USERassociating each hardware interrupt request line (IRQ)with one interrupt service routine (ISR). When interruptsare enabled and an interrupt occurs, the kernel calls the Configurable from nothing to full-blown GDI &registered ISR for that interrupt. The ISR, the kernel- User, with intermediate points:mode-portion of interrupt processing, is kept as short as display-less, message passingpossible. Its responsibility is primarily to direct the kernel (mininput)to schedule and launch the appropriate interrupt service graphics but no windowing (mingdi)thread (IST). The IST, implemented in the device driversoftware module, gets or sends data and control codes minimalist window managerfrom or to the hardware and acknowledges the device (minwmgr)interrupt. GDI - resolution-independent graphics Raster and TrueType Font support o1 to 32 BPP Color Pixel depths w/ palettesDevice Drivers Printing (device-side rendering) User - windowing, dialogs, messaging Built-in support for the keyboard, touch panel, Additional: Controls, clipboard, cursors, caret, notification LED, display, audio (including idle time out, hot keys, etc. Sound Blaster™), battery drivers, and a rapid GDI and user export a subset of the Win32 API development model that allows these devices to be ported quickly to your platform. Support for wireless and wireline Ethernet LAN Communications Support connectivity Statically replaceable keyboard layout Windows Sockets APIs Extended interrupt processing interface or WinInet with FTP, HTTP and HTTPS support device drivers based on the Win32 event model Secure Sockets Layer (SSL) with Server Gated Network printing Cryptography support Support for serial and parallel devices TCP/IP, PPP, SLIP, and IrDA, including Fast IR Host support for Universal Serial Bus (USB) TAPI modem support devices Serial APIs PCMCIA Card and Socket Services for Direct connection, dial-up and device-to-device removable or built-in storage cards connectivity LAN connectivity using NDIS and MicrosoftKernel Network client software (to access remote file and print servers) Multi-threaded; preemptive multitasking Remote access services (RAS) to support remove connectivity Preemptive priority-based thread scheduling based on the Win32 process and thread model; Remote debugging over LAN, serial or parallel supports eight levels of thread priority connections Support for priority inheritance to correct Built-in support for communication hardware priority inversion (built-in modems, Ethernet chips, etc.) Demand paging supported by ROM, RAM, and Windows NT® LAN Manager-based FAT file systems authentication Execute in place from ROM Support for synchronization objects Remote Connectivity (WaitForSingleObject, WaitForMultipleObjects) Low ISR and threat latency Remote networking Portable across microprocessors Direct connection to PC Heap size that is limited only by available Dial-up access to Internet, PCs, and Servers memory ShellObject Store
  • 16. Includes a minimum shell that supports WINDOWS CE - Based HARDWARE application launching and switching REQUIREMENTS The shell can be included to serve as the basis of an embedded application At a minimum, a Windows CE-based device must have a Key UI components included to allow rapid supported processor, memory and an internal timer for development of custom embedded shells scheduling. No other hardware is specifically referenced by the operating system, but most devices will have a number of peripherals.Internationalization/Localization Windows CE is a small-footprint, flexible operating Support for localization of the operating system, system. The memory needed by a Windows CE-based including built-in support for French, German, system is totally dependent on which components the Italian, Portuguese (Brazilian), Spanish, Dutch, designer of the system selects. A Typical CE build may Swedish, Japanese and Chinese (Beta) require 32 Meg of Flash and 32 Meg of RAM. 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 7. Commercial RTOS brandsAdditional Component Features Among commercial embedded operating systems, Wind Rivers VxWorks was the undisputed leader, as shown in Figure 6. With more than 25% of all the votes, it scored ActiveX® and COM/OLE particularly well in avionics applications (where it ranked Microsoft Virtual Machine for Java for Windows well above average) but somewhat poorer in automotive, CE computer-related, and industrial segments (where it Microsoft Foundation Classes for Windows CE 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 several popular embedded OSes with single-digit marketfor Embedded and Windows CE (there were separated by shares. ThreadX is deliberately listed twice: once for theone vote). In a predictable reversal, WinXP and WinCE Green Hills distribution and once for Express Logicswere most popular where VxWorks was weakest: product. Oddly, Green Hills appears to sell more copies ofindustrial and computer-related applications. XPe was ThreadX than the company that developed it.especially strong in manufacturing industries, where Looking ahead, we asked those same survey takers whatVxWorks also made a good showing. OS theyd consider using in their next project. Would theyIn the number four spot we have Texas Instruments stay with their current OS or switch to another? We alsoDSP/BIOS, a product with obvious hardware ties. Thats asked non-OS users the same question to see if they werefollowed by Red Hats Linux, the first of the many Linux considering a commercial OS for the first time. The resultsvariants to make the list. are summarized in Figure 7.After that, the numbers all drop to below 8%. QNX, RTX,C/OS, and Mentor Graphics Nucleus RTOS head the list of
  • 17. The chart shows the delta between the "would consider"responses and the "using now" responses from theprevious graph. In brief, the winners lose and the loserswin. How is that possible and what does it all mean?First, the responses dont necessarily mean that VxWorksusers are unhappy with their current RTOS and are readyto jump to (for example) LynxOS or WindRivers Platform NE Linux. We cant correlate theresponses from the first question to the second; the personwho said hes using VxWorks now may not be the sameperson who said hed consider EPOC in the future. Whatwe can say with certainty is that about 8% fewer peoplesaid theyd consider VxWorks compared with the numberusing it now. Whether or not those are the same people isimpossible to tell.Microsofts two embedded OSes didnt fare well, either. Infact, the eight top choices all lost ground in the game of"guess tomorrows operating system."Reflecting a kind of Zen balance, almost all of the middle About two-thirds of the OS defections are what we mightand low scorers gained share of mind in roughly equal call voluntary changes. Twenty-seven percent said theydproportion to the share lost by the big players. Whether switched operating systems because the new one "hadaccidentally or by design, the numbers reflect a zero-sum better features," with 21% opting for "a better roadmap forgame. This gives us a hint as to the true nature of the data. growth" and 20% jumping ship for "better developmentRecall that more than 28% of embedded projects use no tools." Another 15% said they bailed because the new OSOS at all, and that this proportion has been shrinking was cheaper. Very few (8%) said their old OS was nosteadily for years. Those developers have to go somewhere; longer available and even fewer (6%) switched becausewhat OS will they choose as their first? Logically theyre they were unhappy with their previous OS supplier. Fewergoing to choose a smaller, more inexpensive OS over a than 5% switched because the old system was too slow.large and fully featured one. If youre upgrading your The overall picture is therefore good for commercial OSsystem from no OS at all it makes sense to start small. suppliers. As the number and type of embedded systemsThus, we see that the smaller RTOS vendors gain share of increase, so will the total available market. As in-housemind among potential next-generation projects. and proprietary OS’s slowly ride into the sunset,Will the current commercial vendors lose some development teams will be filling the gap mostly withcustomers? Sure, just as every supplier occasionally loses commercial alternatives. And although open-sourcecustomers to a competitor. But theyll probably gain even operating systems are well and truly established, with one-more new customers. Nothing sinister lurks in the data fifth of developers using one now, their growth seems tohere; nothing to trouble the sleep of the friendly have flattened. Only about 17% of embedded systemsneighbourhood RTOS marketing staff. OS loyalty is fairly developers would consider Linux who arent already usinglow anyway. As the chart in Figure 8 shows, more than it. Whats certain is that the variety of embedded systems—one-third (36%) of developers are using a different OS and the operating systems that serve them—will continuethan they did in their previous project. Usually thats just to flourish.because of a change in hardware (44%) or, moreominously, that the new OS was not the developers choiceand was forced upon them.
  • 18. challenges for designers and technologists. A key issue isConclusion: the definition of the right methodologies to translateEmbedded Systems will play a key role to drive the system knowledge and competences into complextechnological evolution in the next decades. In this respect embedded systems, taking into account many systemthey stand on the same level as Nano technologies, requirements and constraints. The key factor to win thisbioelectronics, and photonics. The central role of challenge is to build the right culture. This means to beembedded systems in the economy grows stronger and able to build the right environment to exploit existingstronger. The starting point is the convergence between design, architectural and technological solutions, and tostorage, security, video, audio, mobility and connectivity. favour the transfer of knowledge from one application fieldSystems are converging and ICs are more and more into another.converging with systems. This poses a number of 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/
  • 19. Assessment of Technical ReportStudent’s name Mark overallDinuka WijesingheCriterion WeightDemonstration of knowledge 25and understandingCritical evaluation 30Breadth and appropriateness ofreferences (properly 30referenced) and bibliographyPresentation (in terms ofstructure) Grammar and 15SpellingTOTALComments.