156
Embedded
Systems
(BSc
IT)
(VS)
most
critical
timing
constraints,
even
at
the
cost
of
violating
others.
Real
Time
Operating
System:
Real
Time
Operating
System
(RTOS)
is
an
operating
system
that
supports
the
construction
of
real-time
systems.
Real-time
computing
is
where
system
correctness
not
only
depends
on
the
correctness
of
logical
result
but
also
on
the
result
delivery
time.
So
the
operating
system
should
have
features
to
support
this
critical
requirement-
to
render
it
to
be
termed
a
Real-time
operating
System
(RTOS).
The
RTOS
should
have
predictable
behavior
to
unpredictable
external
events.
"A
good
RTOS
is
one
that
has
a
bounded
(predictable)
behavior
under
all
system
load
scenario
ie.
even
under
simultaneous
interrupts
and
thread
execution.
A
true
RTOS
will
be
deterministic
under
all
conditions.
These
operating
systems
occupy
little
space
from
10
KB
to
100KB
as
compared
to
the
General
Operating
systems
which
take
hundreds
of
megabytes.
Most
of
the
commercial
embedded
operating
systems
available
today
are
designed
for
possible
inclusion
in
real-time
systems.
In
the
ideal
case,
their
worst-case
performance
is
well
understood
and
documented.
To
earn
the
distinctive
title
"Real-
Time
Operating
System"
(RTOS),
an
operating
system
should
be
deterministic
and
have
guaranteed
worst-case
interrupt
latency
and
context-switch
times.
Given
these
characteristics
and
the
relative
priorities
of
the
tasks
and
interrupts
in
your
system,
it
15
possible
to
analyze
the
worst-case
performance
of
the
software
using
a
technique
such
as
rate
monotonic
analysis.
(An
operating
system
is
said
to
be
deterministic
if
the
worst
case
execution
time
of
each
of
its
system
calls
is
calculable.
A
operating
system
vendor
that
takes
the
real-time
behavior
of
it
product
seriously
will
usually
publish
a
datasheet
providing
minimum,
average,
and
maximum
number
of
clock
cyc
cles
required
by
each
system
call.
These
numbers
may
be
different
r
for
Piori
SchcednNdoerio
dic,
tos
ks

P
e
r
i
p
h
e
r
a
l
s
159
Real
Time
Characteristics
O
5.7
As
we
studied
the
real
time
operating
systems
are
used
to
solvve
real
time
problems
and
conditions
in
embedded
systems.
Most
of
the
commercial
embedded
operating
systems
available
today
are
designed
for
possible
inclusion
in
real-time
systems.
In
the
ideal
case,
this
means
that
their
worst-case
performance
is
well
understood
and
documented.
To
earn
the
distinctive
title
"Real-
Time
Operating
System"
(RTOS),
an
operating
system
should
be
deterministic
and
have
guaranteed
worst-case
interrupt
latency
and
context
switch
times.
Given
these
characteristics
and
the
relative
priorities
of
the
tasks
and
interrupts
in
your
system,
it
is
possible
to
analyze
the
worst-case
performance
of
the
softwate.
Some
of
the
characteristics
of
embedded
system
OS
are
as
follows:
(1)
Large
and
Complex
alag
(2)
Concurrent
control
of
system
components
(3)
Facilities
for
hardware
control
RTDS
She
(4)
Extremely
reliable
and
safe
cely
r
e
&
prtdl
cr"
(5)
Real-time
facilities
(6)
Efficiency
of
execution
DE
md
miaimua
int
Lom
1
5.8
Selection
Process
One
of
the
most
critical
decisions
that
first
arise
when
starting
a
new
Embedded
Systems
Project
is
the
selection
of
the
Operating
System
(OS).
The
proper
or
improper
choice
of
an
OS
can
affect
every
aspect
of
the
development
project
-
from
licensing
costs
to
development
time.
Hardware
decisions
such
as
processor
selection
and
memory
S1ze
will
hinge
on
the
OS
selection.
And
in
today's
embedded
World,
there
a
r
e
so
many
choices.
If
cost
is
the
highest
priority,
Open
source
might
look
the
most
intriguing.
High
security
and

Embedded Systems(BScIT)(VS
160
tight performance might lead the decision towards a commercial
OS, but that might be too expensive.
The selection of embedded operating system depends upon the
hardware used and the function for which the system is designed
Some basic points for selection of an embedded operating system
are as follows.
Trends on OS selection tend to line up by industry:
Most consumer electronics devices that focus on small and
cheap most often opt for no operating system. These types of
devices are simple enough in function without the overhead of an
OS. Examples include a thermostat or microwave. On the other
hand, computer peripheralsand networking devices frequently
go with commercial OS offerings. An intelligent feature-rich
product is likely to require a commercial-grade OS, but not
always. Selecting a commercial OS could translate into higher
costs than if you had selected open-source.
For those developers using a commercial operating system,
what is the most popular?
According to a June 2006 Survey by Embedded.com,.for
Commercial OS users, VxWorks still holds a strong lead, but
Microsoft products XP Embedded and WindowsCE are rapidly
making headway This data does not include those 21% who
reported they use a home-grown operating system. But fewer
home-grown systems are around as compared to similar survey
data the previous year. An exception would be the automotive
industry, where commercial operating systems are selected only
33% of the time.
What about Open-Source Operating Systems?
Looking at the popularity distribution above, it is interesting
note that about 20% of developers (28% of those choosing an
0
are using Linux or some form of open-source, either commercia
rcial

161
P e r i p h e r a l s
fre
ar free. While this is a healthy percentage, it is lower than last
or
vear, which showed 37%% were open-source users. More telling is
that the number of people expecting to use Linux on their NEXT
project has dropped by 1/3rd. The caveat is that opinions are
skewed based upon industry. Manufacturing applications choose
Linux 38% of the time while Automotive is only 12%.
What type of OS is typically selected for your industry? There
aretypically reasons why certain industries use specific OSs. Buck
the trend and dare to be different, but you might be safer selecting
an OS that is widely accepted.
Other Considerations in OSSelection:
The next set of survey questions in the Embedded.com survey
focused on criteria developers used to select an OS. As expected,
real-tim performancewas the most important, followed closely
byprocessorcompatibility. w
The availability of software tools effectively tied for second
place, followed closely by royalty fees and purchase price. Whae's
interesting is that none of them has anything 'to do with the OS
itself. They're all "ecosystem" issues surrounding the OS and affect
the developer's quality-of-life. Non-technical criteria like support,
trust and reputation play an ever-larger role in previously
technicaldecisions. 2
Memory footprintand simplicity both ranked highly, echoing
the responses from earlier questions. Memory usage, like
performance, determines whether the OS is suitable for the task.
Simplicity determines whether the developer should even bother.
the
| 5.9 Summary
Control and Status Registers: An embedded processor
interac
ters.
witn a peripheral device through a set of control and status registeIS

pesign and Development
165
Introduction
6.1
In this chapter we will study about the embedded system
development and the tools used for developing the system. For
embedded system development we require the host which is also
known as development computer and acts as brain of the design
environment, Integrated Development Environment (IDE) which
is a tool for embedded firmware development and debugging
and the Electronic Device Automation (EDA) tool.
6.2 EmbeddedSystem DevelopmentEnvironment
The most important characteristic of embedded systems is the
cross-platform development technique. The primary components
in the development environment are the host system, the target
embedded system, and potentially many connectivity solutions
available between the host and the target embedded system, as
shown in Figure.
Host System
Target System
Connections
Target
Resident
Software
Host
Resident
******
Serial
Software Y 1 BDM/JTAG
Ethernet
Fig. 6.1
The development tools offered by the host system are the cross
compiler, linker, and
source-level debugger. The target
embedded
system might offer a dynamic
loader, a link loader, a
monitor,
and
a debug agent.

166 Embedded Systems (BSc I)(VS)
Set of connections are required between the development
Computer system and the target system. These connections are
used for downloading program images from the development
Computer systemto the targetsystem. These connections can also
be used for transmitting debugger information between the host
debugger and the target debug agent. The Programs including the
system software, the real-time operating system (RTOS), the
kernel, and the application code must bbe developed first,
compiled into object code, and linked together into an executable
image. Programmers writing applications that execute in the same
environment as used for development, called native development,
do not need to be concerned with how an executable image is
loaded into memory and how execution control is transferred to
the application. Embedded
development, however, are required to understand the target
system fully, how to store the program image on thearget
embedded system, how and where to load the program image
during runtime, and how to develop and debug the system
developers doing cross-platform
iteratively.
6.3 Integrated Development Environment (IDE) D
In context of embedded system the (integrated development
environment stands for an integrated environmentfor developing
and debugging of the processor specificfirmware. )O.
An integrated development environment (IDE) is also known
as integrated design environment, integrated debugginga
environment or interactive development environment(The IDE15
a software application that provides facilities tocomputer
Computer
programmers for software development."

eloem et
e.( UI olaA1n Uodn
Design and Development
167
Simulator
C-Editor
Emulator
RTOS
Logic Analyser Cross Assembler
Target System
Performance Evaluation Test Vector
AAN in ten
opehati Syn
Fig. 6.2
The IDE normally consist of
i s a meamo
oteath wid
(1 Text Editor or Source code editor
(2) A compiler and an
interpreter
(3) Buildautomationtools J e we isswes
(4) Debugger niki
Londi cemento to Pv
i n form e
Suceive u'nester
5) Simulators
(6) Emulators and logic analyzer
The example of IDE is Turbo C/C++ which provides platformm
on windows for development of application programs with
command line interface. There is anothercategory of IDE which is
known as Visual IDE which provides the platform for visual
development environment with mouse support on every action.
The
example of Visual IDE is Microsoft Visual C++. The Visual
DEs are more useful in firmware development. The IDEs usea in
embedded system development are different then generic lDEs
Basically generic IDEs are used for desktop application
development and the rarely supports the embedded hardware
nmal a
:TTrErsrETYRTRRTRTYN

170 Embedded Systems (BSc IT) (VS)
(3) Debugging the Code:
A debugger is a piece of software runningøn the PC, which
has to be tightly integrated with the emulaeor that you use to
validate your code. For that reason all emulator manufacturere
ship their own debugger software with their tools, but also
compiler manufacturers frequently include debuggers, which
work with certain emulators, into their development suites.
A Debugger allows you to download your code to the
emuator's memory and then control all of the functions of the
emulator from a PC.Common debuggingfeatures include the
capability to examine and modify the microcontroller's on-chip
registers, data- and program-memory; pausing or stopping
program executing at defined program locations by setting
breakpoints; single-stepping (execute one instruction at a time)
through the code; and looking at a history of executed code
(trace).
stopping
So far we've talked about several different pieces of software:
Text Editor, Assembler or Compiler, Linkers, Librarians and
Debugger. You can easily imagine that it can become quite a time
consuming challenge to alternate back and forth between áll of
these programs during the debugging process (discover a bug
edit the source code, compile it again, link it again, download the
modified code to the emulator, etc.). This is where an integratea
development environment (IDE) comes in.
An Integrated Developmernt Environment puts all of the
previously discuSsed software components under one commo
unified user interface, so that it becomes possible to make a cou
de
change and get the modified code loaded into the emulator with a
few mouse clicks, instead of dozens. A good IDE allows you i
example to click on a
syntax error
message produced by
ne
compiler and have the source code with the highlighted offernding
instruction pop up for editing in the text editor. One click a

pesign and Development
179
6.4 Cross Compilation Shy
(A cross compiler is a
compiler capable of creating executable
code for a
platform other than the one onwhich the compiler is
run. Cross compiler tools are used to generate executables fot
embedded system or
multiple platforms)It is used to compile for
a platform upon which it is not feasible to do the compiling, like
microcontrollers that don't support an
operating system. It has
become more common to use this tool for paravirtualization
where a
system may have one or more platforms in use.
Embedded computers where a device has extremely limited
resources. For example, a microwave oven will have an
extremely
small computer to read its touchpad and door sensor, provide
output, to a digital display and speaker, and to control the
machinery for cooking food. Thiscomputerwillnot be powerful
enough to run a
compiler, a file system, or a
development
environment. Since debugging and testing may also require more
resources than are available on an
embedded system, cross-
compilation can be less involved and less prone to errors than
native compilation.
The host system is the system on which the embedded
software is developed. The target system is the embedded system
under development. The main software tool that makes cross-
platform development possible is a cross
compiler. A cross
compiler is a
compiler that runs on one
type of processor
architecture but produces object code for a different type of
processor architecture.
Why do we need cross compiler?
There are several advantages of using cross compiler. Some of
them are described as follows

pesign and Development 181
Types of
Files generated on crosscompilation:
As we studied in crOss compilation that it is a process in which
the host processor is used to compile codes for some other target
P
DrOcessor. During this process various files are generated as
follows:
(1) Listing File
(2) Hex File
(3) Map File i n f o m m a
abt h e
conp)la
(4) Object File
(1) Listing File(.lst): At the time of cross compilation the lst file
is generated by the system which contains the information
code generated from the source file.
(2) Hex File: Basically the Hex files are binary files.The HEX file
is an ASCII text file with lines of text that fóllow the Intel1
HEX file format. Each line in an Intel HEX file contains one
HEX record. These records are made up of hexadecimal
numbers that represent machine language codey and/or
constant data. Intel HEX filesare often used to transfer the
program and data that would be stored in a ROM or EPROM.
Most EPROM programmers or emulators can use Intel HEX
files
(3) Map files: Map files are used to keep the information of
linking and locating process.
t is basically a text file
containing a list of topic 1Ds and map numbers that are
related to the interface in an application .Map files use the
extensions .H, .HH and .HM.
(4) Object files: An object file format is the lowest level fila
format for any platform. It is designed with the primary goal
of providing formatted binariesOtnachine codes, initialized
data and uninitialized data ror aut
execution vehicle. As a
secondary goal, it provides So evel debugging (SI n

Embedded Systems (BSc IT)Ve
182
information, such as line number information for
communication utility that links the host computer to
debugging engine.
a
er to the
6.5 Disassambler/Decompiler
DISASSEMBLER: e n S abbeTia
abbre tan
mne SG , )syb b, ID
e hca (SUB , tAD, ADD a1,
Subrah UD from or
A disassembler is a computer program thattranslatesmachine
language into assembly language it is the inverse operation to that
ofan assembler. A disassembler differs from adecompiler, which
targets a high-level language rather than an assembly language.
Disassembly, the output of a disassembler, is often formatted for
human-readability rather than suitability for input to an
assembler, making it principally a reverse-engineering tool.
Assembly language source code generally permits the use of
constants and programmer comments. These are usually removed
from the assembled machine. code by the assembler. If so, a
disassembler operating on the machine code would produce
disassembly lacking these constants and comments; the
disassembled output becomes more difficult for a human to
interpret than the original annotated source code. The Interactive
Disassembler allows the human user to make up mnemone
symbols for values or
regions of code in an interactive sessio
human insight applied to the disassembly process often paralleis
human creativity in the code writing process.
A disassembler may be stand-alone or interactive. A stan
alone disassembler, when executed, generates an assemo
assembly
language file which can be examined; interactive one shows u
effect of any change the user makes immediately. For example, tne
disassembler may inutially not know that a section of the progra
is actually code, and treat it as data; if the user specifies that it
is
code, the resulting disassembled code is shown immediately

Led dola
Giohlc- nNubna
Deslgnand Development Ses eroarorm1nirt,fue 3
m nè Programa likme
allowing the user to examine it and take further actíon during the
zithle aMerm
n
SOw
Code
Any interactive debugger will include some way of viewing e
same run.
eh
the disassembly of the program being debugged. Often, the same
disassembly tool will be packaged as a
standalone disassembler
distributed along with the debugger. For example, objdump, part
of GNU Binutils, is related to the interactive debugger gdb.
IDA
OllyDbg is a32-bit assembler level analysing debugger
OLIVER and SIMON include disassemblers for Assembler,
COBOL, and PL/1
DECOMPILER: stu
A decompiler is the name given to a
computer program that
performs, as far as possible, the reverse operation to that of, a
compiler. That is,it translates a file containing information at a
relatively low level of abstractioninto a form having a
higher
level of abstraction. The decompiler does not reconstruct the
original source code, and its output is far less intelligible to a
human than original source code.
To decompile is to convert executableprogram code into some
formofhigher-level programminglanguagesothatitcan be read
by a human. Decompilation is a type of reverse engineering that
does the opposite of what a compiler does. The tool that
accomplishes this is called a decompiler. A similar tool, called a
disassembler, trarnslates object code into assembler language.
There are a number of different reasons for Decompilation or
disassembly, such as understanding a program, recovering the
Source code for purposes ofarchiving orupdating, finding
viruses, debugging programs, and translating obsolete code.
Decompilation was first used in the 1960s to facilitate the
migration of a program from one platform to another.

w l o k e
184 pAd cl e O EmbeddedSysteris (BSc IT) (VS
Decompilation is not always successful for a number of
reasons. It is not possible to decompile all programs, and data and
code are difficult to separate, because both are represented
similarly in mosteufrent computer systems.
6.6 Simulator 0
Simulation as a tool has been used for a long time in many
areas of science and technology. The use of weather system
simulation to prdict the weather and mechanical system
simulation to predict the behavior of aircraft in flight are assumed
asgiven_today. In car design, the use ofvirtual crash testing
improves the safety of cars while radically reducing the number of
physical prototypes that need to be built and tested.
Simulator is a completely host-based program that simulates
the functionality and instruction set of the target processor. The
human interface is usually the same as or similar to that of the
remote debugger. Thefeatures of simulation based debugging are:
i Itis purely softwarebased
4i It will not require any real target system
ha
S Lack of real time behavior.
Simulation is used whenever trying things in the physical
world would be inconvenient, expensive, impractical or plain
impossible. Simulation allows experimenters to try things wi
more control over parameters and better insight into the results. I
reduces the cost of experiments, and makes it possible to work
with systems that do not yet exist in physical form. It cuts leaa
times and improves product quality. In a sense, we use simulation
and virtual systems because reality sucks.
In this section, we will discuss how simulation technology Cal
be used to develop embedded systems and the software
software
component of these projects in particular.

exeuC
Designand Developmeent
185 O.
Gimulating a
Computer System An embedded computer
ystem can be broken down into five main parts:
(a)The computer board itself: the piece of hardware
containing one or more processors, executing the
embedded software.
(b) The software running on this computer board. This
includes not just the user applications, but also the boot
ROM or BIOS, hardware drivers, operating system, and
various libraries and middleware frameworks used to
implement
thesoftware functions.
? LWEennol-/intenct
(c) The communications netwórk or networks that the board e
is connected to, and over which the software
communicates with software on other computers.
(d)The environment in which the computer operates and that
itmeasures using sensors and affects using actuators.
e) The user interface exposed to a human user of the system.
Communlcatdons
nebworks
Applications
Middleware, ibraries
Operating system
BootROM,drivers,HAL
Conroledd
wironmen
Human user interfac
BLOS 1S a npa
handwwnl. fothalizio. ir the boo
hpeli ahno P t
S
Ofu nA2ut t a
Keyb o nd, olipk

Embedded
Systems
(BSc
IT)
(VSI
186
A
simulation
effort
for
an
embedded
system
can
focus
on
iust
one
of
the
parts.
It
is
quite
common
to
mix
simulated
and
physical
parts,
to
achieve
"partial
reality."
Simulating
the
Environment:
Simulation
of
the
physical
environment
is
often
done
for
its
own
sake,
without
regard
for
the
eventual
use
of
the
simulation
model
by
embedded
software
developers.
It
is
standard
practice
in
mechanical
and
electrical
engineering
to
design
with
computer
aided
tools
and
simulation.
Simulating
the
Human
User
Interface:
The
human
interface
portion
of
an
embedded
device
is
often
also
simulated
during
its
development.
For
testing
user
interface
ideas,
rapid
prototyping
and
simulation
is
very
worthwhile
and
can
be
done
in
many
different
ways.
Simulating
the
Network:
Most
embedded
computers
today
are
connected
to
one
or
more
networks.
These
networks
can
be
internal
to
a
system;
for
example,
in
a
rack-based
system,
PCI,
PCI
Express,
Rapid1O,
Ethernet,
12C,
serial
lines,
and
ATM
can
be
used
to
connect
the
boards.
6.7
Emulator
and
Debugger
EMULATOR:
An
emulator
is
a
piece
of
hardware
that
ideally
behaves
exactiy
like
the
real
microcontroller
chip
with
all
its
integrated
integrated
functionality.
It
is
the
most
powerful
debugging
tool
of
all.
A
microcontroller's
functions
are
emulated
in
real-time
and
no
intrusively.
All
emulators
contain
3
essential
functions
in
different
implementation
forms
(1)
The
emulator
control
logic,
including
emulation
memory
(2)
The
actual
emulation
device

pesign and Development
187
(3) A pin adapter that gives the emulator's target connector
the same "package" and pin out as the microcontroller to
be emulated
Most emulators give you a
range of choices of exchangeable
pin adapters and emulation devices to build your own
customized emulator that supports the exact derivative and
package of your specific microcontroller.
An emulator is a pieceof hardware that lookslike a
processor,
has memory like a processor, and executes instructions like a
processor, but is not a processor. It often has the advantage that
you can probe points of the circuit that are not accessible inside a
chip. Generally it is a combination of hardware and software.
They are often quite expensive.
A debugger is a program that finds and fixes bugs in
programs. As a program it usually takes the form of a small
monitor that runs on the target processor, and can examine
memory, install breakpoints, and trigger on various conditions.
Sometimes it can allow changes in programs for fixing a problem
and trying again.
Emulation Memory: Because, depending on memory
technology, a microcontroller's program memory cannot (ROM)
or
only once (OTP) be programmed, an(emulator uses external
static RAM as the emulatedmicro'sprogrammemory)Evensome
Flashbased microcontrollers can, depending on manufacturer,
only be re-programmed 100 to 1000 times, which warrants the use
of external RAM memory rather than the micro's integrated Flash
tor
emulation. (RAM memory allows for code to be changedk
quickly and an "indefinite" number oftimes during the software
debugging process.)
Emulation ControlLogic:Contributing to the cost of emulators
1s the control logic required to recreate functions that might be lost
due to the emulator using those resources (e.g. some standard l/O

me, 2 (am watt m KpecdJ Hr an
dhe dab
eCme
ges
Sin8le
gns
instru
tes
t 88 xowad romene
t den w alo®, ullow You h set b rcaleP
Pgn'ns hne u,.
1csdfla
Embedded Systems (BSc IT) (vSP
pins). By recreating such functions with additional logic, those
emulators work truly transparent or
non-intrusive, which means
you have all the pins, all the memory
and all the peripheral
functions available like with the real microcontroller.
DEBUGGER:
Debugger is a special program
used to find errors (bugs) in
other programs. A debugger allows a programmer to stop a
programn at any point and examine and change the values of
variables. A debugger or debugging tool is a computer program
that is used to test and
debug other programs. The code to be
examined might alternatively be running on an instruction set
simulator, a technique that allows great power in its ability to halt
when specific conditions are encountered but which will typically
be somewhat slower than executing the code directly on the
appropriate (or the same) processor. Some debuggers offer two
modes of operation - full or partial simulation, to limit this impact.
A "crash" happens when the program cannot normally
continue because of a programming bug. For example, the
program might have tried to use an instruction not available on
the current version of the CPU or attempted to access unavailable
or protected memory. When the program "crashes" or reaches a
preset condition, the debugger typically shows the position in the
original code if it is a source-level_debugger or symbouc
debugger, commonly now seen in integrated development
enviroriments. isPaY
show oe o exp
6.8 Embedded ProductDevelopment Life Cycle O
nten
Me nemoi
The embedded system product development life cycle is
basically explains various phases of embedded development:
*
It
requires proper study of the system and accordingly designing

Design and Development
189
and maintenance of the system. The block
diagram of
development life cycle is shown in figure.
of
CONCEPT
REQUIREMENTS DESIGN
DEVELOPMENT
VAR &VAAL
DEVELOPMENT
INTEGRATION
MAIN/RETIRE
Fig. 6.4
(1) Concept Phase: A
comprehensive analysis of the market
trends is done here in the concept phase. The phase involves
brainstorming of innovative ideas driven by technology
trends and customer inputs. The customer here could be
strategic partners for an established company OR end- users
of similar product in the market.
(2) Requirements Gathering Phase: A critical stage for
Embedded Product as it determines what kind ofhardware
and software support is required to satisfy the scenarios
identified for the customer. The number of requirements will
eventually determine the scope of the product and what
problem areas are being addressed by your new version of
the product. A detailed feasibility (technical and business) is
done by soliciting feedback from all critical stake holders of
this project.
(3) Design Phase: During this phase, the product owner and
design team will identify the relationship between input and
output.A System Specification is written after investigating
the overall behavior of the embedded system. All the
requiredcomponents to duttd the embedded product are
identified and also(howthese components interactwitheach
other.Afunctional design document is written to compile tne
findings of all the above components. A detailed Hardware
a

190Cehomi o l n Embedded Systems (BSc IT) (VS)
u l
and Software partitioning is determined. Rapid Prototyping
is done in order to validate the identified and proposed
design
Architecture viz. target processor architecture and Host
O.S is also identified for the implementation purposes.
4) Development & Implementation Phase: Based on the
specification of embedded system regardingfunctionality &
power consumption and cost all the different hardware add
on components are chosen and hardware implemnentation
will start in the first sub-phase of implementation. Then the
software component, which deals with code running on a
microcontroller running together on a RTOS is done as a next
step in the development process. Some new development
approaches, recommend both the hardware implementation
viz, VHDL programming & Software Implementation using
C programming is done in parallel so that integration
becomes easier.
Integration Phase: The next step in the implementation
process is thetestingofthe entireembeddedsystem. This will
ensure whether the embedded system is complying Witn
(5)
entire systemspecification defined above.
6) Verification and Validation Phase: The Validation phase is
to ensure that the entire system is implemented as againstthe
design and eventually against the requirements. Enulatio
based approaches can be followed for verification.
Compliance testing and certification testing are carried on tne
target embedded system OR consumer device.
(7) Maintenance and Retire Phase: The Maintenance phast
ncludes hangesand additions as required by the users a
nd
-
also fixing bugs to keep the product up and running at
customer site.

CFut al hi ca belhaun
na{ nanaCken ís Hco 191 &
igial syslemS
esgn and Development
69 TrendsinEmbeddedIndustry
Lhe
The embedded systems development started with the
inerntion of microcontrollers. Embeddedsystems havebecome an
integral part of daily life. Be it a cell phone, a smartcard, a music
plaver. a router, or the electronics in an automobile - these
Svstems have been touching and changing modern lives like never
berore. Various classes of embedded systems such as home media
svstems, portable players, smart phones, embedded medical
devices and sensors, automotive embedded systems have
surrounded us and with continued convergence of
communications and computing functions within these devices,
embedded systems are transforming themselves into really
Complexsystems.
Consumer Electronics
Music players,
digital cameras,
DVD players,
set-top boxes,
PDA, VIdeo games,
GPS receivers,
home appliances
Automation Medical Electronics
Copier, Fax machines,
Printer, scanner,
multi-tunction peripherals,
point of sale terminals,
storage devices, smartcards
Patlent monitoring,
surgical systems,
diagnostic equipments,
imaging, electronic
stethoscopes
Remote Automatlon
Telecom/Datacom
Routers, switches,
bridges, cellularphones,
smart devices,
networking gateways
Building automation
e.g. heating, ventllation,
air-conditioning (HVAC),
home automation,
utilty meters
Embedded
Systems
MIlltary/Aerospace
Satellte systems,
radar, sonar, navigation,
Weather systems,
flight control system8,
alrcraft management
systems
Industrlal Controls
Smart sensors,
Automotlve Electronlcs
Electronlc control unlts
used In chassis, body
electronics, security,
power train, in-vahicle
entertainment and
Intotalnment systems
special purpose
controllers, networklng,
process controls
Fig. 6.5