UNIT III

EMBEDDED FIRMWARE DEVELOPMENT

ENVIRONMENT
Embedded firmware
• Embedded firmware is the flash memory chip that stores specialized
software running in a chip in an embedded device to control its
functions.
• Firmware in embedded systems fills the same purpose as a ROM but
can be updated more easily for better adaptability to conditions or
interconnecting with additional equipment.
• Hardware makers use embedded firmware to control the functions of
various hardware devices and systems much like a computer’s
operating system controls the function of software applications.
• Embedded firmware exists in everything from appliances so simple
they had computer control, like toasters, to complex tracking systems
in missiles.
• The toaster would likely never need updating but the tracking system
sometimes does.
• As the complexity of a device increases, it often makes sense to use
firmware in case of design errors that an update might correct.
Embedded firmware
• Embedded firmware is used to control the limited, set functions of hardware
devices and systems of greater complexity but still gives more appliance-like
usage instead of a series of terminal commands.
• Embedded firmware functions are activated by external controls or external
actions of the hardware.
• Embedded firmware and ROM-based embedded software often have
communication links to other devices for functionality or to address the need
for the device to be adjusted, calibrated or diagnosed or to output log files.
• It is also through these connections that someone might attempt embedded
device hacking.
• Embedded software varies in complexity as much the devices it is used to
control.
• Although embedded software and embedded firmware are sometimes used
synonymously, they are not exactly the same thing.
• For example, embedded software may run on ROM chips. Also, embedded
software is often the only computer code running on a piece of hardware
while firmware can also refer to the chip that houses a computer’s EFI or
BIOS, which hands over control to an OS that in turn launches and controls
programs.
 SYLLABUS
• Embedded Product Development Life Cycle
• objectives, different phases of EDLC
• Modelling of EDLC
• issues in Hardware-software Co-design
• Data Flow Graph
• state machine model
• Sequential Program Model
• concurrent Model
• object oriented Model.
 Embedded Development Life Cycle (EDLC)
What is EDLC
• EDLC is an Analysis-Design-Implementation based problem solving approach
for the product development.
• Analysis – What product need to be developed
• Design – Good approach for building it
• Implementation – To develop it
Why EDLC(NEED for EDLC)
• Essential in understanding the scope and complexities involved in any
Embedded product development.
• Defines interaction and activities among Various groups of product
development sector.
• Project management
• System design and development (HW and FW)
• System testing
• Release management and quality assurance
 Objectives of EDLC
• Aim of any product development is the Marginal benefit
• Marginal benefit = Return on investment (ROI)
• Investment – Initial, man power, infrastructure)
• Product needs to be acceptable by the end user i.e. it has to meet the
requirements of the end user in terms of quality, reliability & functionality.
• EDLC helps in ensuring all these requirements by following three objective
• Ensuring that high quality products are delivered to user
• Risk minimization and defect prevention in product development through project
management
• Maximize productivity
 1. Ensuring high quality products

➢ The primary definition of quality in any embedded product development is

return on investment achieved by the product.
➢ The expense incurred for developing the product may fall in any of the
categories: Initial investment, developer recruiting, training etc.
➢ In order to survive in market, quality is very important factor to be taken care
of while developing the product.
➢ Qualitative attributes depends on the budget of the product so budget allocation
is very important.
➢ Budget allocation might have done after studying the market, trends &
requirements of product, competition .etc.
 2. Risk minimization & defect prevention through project
management
➢ Project management (PM)
➢ Adds an extra cost on budget
➢ But essential for ensuring the development process is going in right direction
➢ Projects in EDLC requires Loose project management or tight project management.
➢ Apart from resource allocation , project management also covers task allocation, scheduling,
monitoring and tracking
➢ Computer Assisted Software Engineering (CASE) and Gantt charts help the manager

➢ PM is required for
➢ Predictability
➢ Analyze the time to finish the product (PDS = no of person days )
➢ Co-ordination
➢ Resources (developers) needed to do the job
➢ Risk mimization
➢ Backup of resources to overcome critical situation
➢ Ensuring defective product is not developed
 3. Increased productivity
➢ It is a Measure of efficiency as well as ROI
➢ How many resources are utilized to build the product, how much investment required, how much
time is taken for developing the project
➢ It is based on total man power efficiency

Different ways to improve the productivity are

➢ Saving the manpower
➢ X members – X period
➢ X/2 members – X period

➢ Pay once use many time

➢ Use of automated tools where ever is required
➢ Re-usable effort – work which has been done for the previous product can be used if similarities
present b/w previous and present product.
➢ Use of resources with specific set of skills which exactly matches the requirements of the product,
which reduces the time in training the resource
➢ Use of Commercial Off-the shelf Components (COTS) where ever possible in a product is a very
good way of reducing the development effort
 Different phases of edlc
➢ A life cycle of product development is commonly referred as the “model”
➢ A simple model contains
➢ Requirement analysis
➢ Design
➢ Development and test
➢ Deployment and maintenance
➢ The no of phases involved in EDLC model depends on the complexity of the product
Classic Embedded product development life cycle model
NEED:
➢ Any embedded product may evolves as an output of a need.
➢ Need may come from an individual/from public/from company(generally speaking
from an end user/client)
➢ New/custom product development
➢ Product re-engineering (Change in business requirement, User interface enhancement and upgrades)
➢ Product maintenance

➢ After approval of concept approval

➢ It defines the scope of concept, performs cost benefit analysis, feasibility study and prepares project management
and risk management plans
CONCEPTUALIZATION: (Product concept development phase)
CBA – identifying, revealing and assessing the total development cost and
profit expected from the product. Loss- gain analysis. Uses the principles
like Common unit of measurement, Market choice based benefit
measurement, and target end users. Money is taken as the unit of
measurement.
 Feasibility study- analyse the technical
challenges, financial requirements,
funding etc.
Product type – what is in the scope of
the product and what is not in the scope
of the product.
Planning for next phase- if the product is
feasible, goto the next phase, if it is not
scrap
Resource planning – How many
resources should work
Risk mgt planning- technical work,
mitigation plans, etc.

Study activity
 ANALYSIS:

Analyze and
document functional
and non-functional
requirements

Requirement
Interface definition Document
specification
and documentation review
document

Define test plan

and procedure Rework on
requirements
and documents
 DESIGN:
DEDeals with the entire design of the product taking the requirements into
consideration and focuses on how the functionalities can be delivered.

Generates detailed architecture

•Detailed architecture also needs
•Only i/p & o/p are defined here approval
•Product will look like a black box
•Sent for approval from client
 DEVELOPMENT AND TESTING
. Development phase transforms the design into realizable product
. Design is transformed into hardware and firmware
. Look and feel of the device is very important

▪ Testing phase can be divided into

. Unit testing – independent testing of hardware and firmware
. Integration testing – testing after integrating hardware and firmware
. System testing – testing of whole system on functionality and non-functionality
basis
. User acceptance testing – testing of the product against the criteria mentioned by
the end-user/client
. Test reports
DEPLOYMENT:
➢ A process of launching fully functional model into the market
1. Notification of product deployment
2. Execution of training plan
3. Product Installation
4. Product post-implementation review
SUPPORT:
➢ Deals with the operation and maintenance of the product
➢ Support should be provide to the end user/client to fix the bugs of the product
1. Set up a dedicated support wing
2. Identify Bugs and areas of improvement
UPGRADES:
➢ Releasing of new version for the product which is already exists in the market
➢ Releasing of major bug fixes.
RETIREMENT/DISPOSAL:
➢ Everything changes, the technology you feel as the most advanced and best today may not be the same tomorrow
➢ Due to this the product cannot sustain in the market for long
➢ It has to be disposed on right time before it causes the loss.
 MODELLING THE EDLC

1. Linear waterfall model

2. Iterative model
3. Prototyping model
4. Spiral model
 1.Linear waterfall model
In this approach each phase of EDLC(Embedded Development Product Lifecycle) is executed
in sequence.
It establishes analysis and design with highly structured development phases.
The execution flow is unidirectional.
The output of one phase serves as the input of the nextphase
All activities involved in each phase are well planned so that what should be done in
The next phase and how it can be done.
The feedback of each phase is available only after they are executed.
It implements extensive review systems to ensure the process flow is going in the
Right direction.
One significant feature of this model is that even if you identify bugs in the current
Design the development process proceeds with the design.
Advantages
Product development is rich in terms of:
▪ Documentation
▪ Easy project management
▪ Good control over cost & Schedule
Drawbacks
▪ It assumes all the analysis can be done without doing any design or
implementation
▪ The risk analysis is performed only once.
▪ The working product is available only at the end of the development phase
▪ Bug fixes and correction are performed only at the maintenance/support
phase of the life cycle.
• Iterative and Incremental development is at the heart of a cyclic software development
process developed in response to the weaknesses of the waterfall model.
• The iterative model is the repetitive process in which the Waterfall model is repeated over
and over to correct the ambiguities observed in each iteration.
• The core set of functions for each group is identified in the first cycle, it is then built,
deployed and release. This release is called as the first release.
• Bug fixes and modification for first cycle carried out in second cycle.
• Process is repeated until all functionalities are implemented meeting the requirements.

Advatages:
• Data can be used as reference for similar product development in future.
• More responsive to changing user needs.
• Product development can be stopped at any stage with a bare minimum
working product.
Disadvantages:
• It assumes all the analysis can be done without doing any design or
implementation
• The risk analysis is performed only once.
• The working product is available at many stages
• It is similar to iterative model and the product is developed in multiple cycles.
• The only difference is that, Prototyping model produces a refined prototype of
the product at the end of each cycle instead of functionality/feature addition in
each cycle as performed by the iterative model.
• There won’t be any commercial deployment of the prototype of the product at
each cycle’s end.
• The shortcomings of the proto-model after each cycle are evaluated and it is
fixed in the next cycle.
• After the initial requirement analysis, the design for the first prototype is
made, the development process is started.
• On finishing the prototype, it is sent to the customer for evaluation.
• The customer evaluates the product for the set of requirements and gives
his/her feedback to the developer in terms of shortcomings and improvements
needed.
• The developer refines the product according to the customer’s exact
expectation and repeats the proto development process.
• After a finite number of iterations, the final product is delivered to the
customer and launches in the market/operational environment

• In this approach the product undergoes significant evolution

• as a result of periodic shuttling of product information between
• the customer and developer
• The prototyping model follows the approach-
• Requirement definition
• Proto-type development
• Proto-type evaluation
• Requirements refining
Issues in hardware – software co design
• Selecting the model
• Selecting the architecture
• Selecting the language
• Partitioning system requirements into HW and SW
 HW-SW Co-design Process

Edit Compile Debug

Specification

Capture Simulate

Place and Integrate

Route Hardware and
Software
Hardware
Verification
8/2/2001 NSF-CCLI Seminar, sld 34
HW-SW Co-design Process
Keil vision:
Edit Compile Debug IDE
C51
Specification dScope

Capture Simulate

Place and Integrate

Route Hardware and
Software
Hardware
Verification
8/2/2001 NSF-CCLI Seminar, sld 35
HW-SW Co-design Process
Edit Compile Debug
Specification
Mentor:
Capture Simulate Design Arch
Quicksim

Place and Integrate

Route Hardware and
Software
Hardware
Verification
8/2/2001 NSF-CCLI Seminar, sld 36
HW-SW Co-design Process
Edit Compile Debug
Specification

Capture Simulate

Place and Integrate

Route Hardware and
Software
Hardware QuicksimPro:
Verification Quicksim &
Modeltech
8/2/2001 NSF-CCLI Seminar, sld 37
HW-SW Co-design Process
Edit Compile Debug
Specification

Capture Simulate

Place and Integrate

Route Hardware and
Software
Hardware Xilinx
Verification Alliance
8/2/2001 NSF-CCLI Seminar, sld 38
Concurrent design
Traditional design flow Concurrent (codesign) flow
start

start

HW SW

HW SW
Designed by independent
groups of experts Designed by Same group of
experts with cooperation

Mahapatra - Texas A&M - Spring 04 39

Codesign motivation
Trend toward smaller mask-level geometries leads to:
• Higher integration and cost of fabrication.
• Amortize hardware design over large volume productions
Suggestion:
Use software as a means of differentiating products based on the
same hardware platform.

Mahapatra - Texas A&M - Spring 04 40

Why codesign?
• Reduce time to market
• Achieve better design
• Explore alternative designs
• Good design can be found by balancing the HW/SW
• To meet strict design constraint
• power, size, timing, and performance trade-offs
• safety and reliability
• system on chip

Mahapatra - Texas A&M - Spring 04 41

Typical codesign process

System
Description
Modeling

HW/SW Unified representation

Partitioning

Software Hardware
Interface synthesis
synthesis
synthesis

Instruction set level

System
HW/SW evaluation
integration
Steps in Codesign
HW-SW system involves
• specification
• modeling
• design space exploration and partitioning
• synthesis and optimization
• validation
• implementation

Mahapatra - Texas A&M - Spring 04 43

 Steps in codesign
Specification
• List the functions of a system that describe
the behavior of an abstraction clearly
without ambiguity.
Modeling:
• Process of conceptualizing and refining the
specifications, and producing a hardware
and software model.

Mahapatra - Texas A&M - Spring 04 44

 Modeling style
•Homogeneous: a modeling language
or a graphical formalism for
presentation
• partitioning problem used by the
designer
•Heterogeneous: multiple
presentations
• partitioning is specified by the models
Mahapatra - Texas A&M - Spring 04 45
Steps in codesign
Validation:
Process of achieving a reasonable
level of confidence that the system
will work as designed.
• Takes different flavors per application
domain: cosimulation for performance and
correctness

Mahapatra - Texas A&M - Spring 04 46

Steps in codesign
Implementation:
Physical realization of the hardware
(through synthesis)
and of executable software
(through compilation).

Mahapatra - Texas A&M - Spring 04 47

 Partitioning and Scheduling (where and
when)
• A hardware/software partitioning
represents a physical partition of system
functionality into application-specific
hardware and software.
• Scheduling is to assign an execution start
time to each task in a set, where tasks are
linked by some relations.

Mahapatra - Texas A&M - Spring 04 48

Computational models in embedded design
• What:
– A conceptual notion for expressing the function of a system
E.g. DFG, FSM, Petri net, Turing machine, etc.
• Computational Models & Languages
– Models express the behavior, languages capture models
– Models are conceptual, languages are concrete
• What is in a computational model
– A set of objects
– Rules
– Semantics
Data Flow Graph (DFG)
• A modem communications system

– Each box is a single function or sub systems

– The activity of each block in the chain depends
on the input of the previous block
– Data driven
• Each functional block may have to wait until it
receives a "certain amount" of information
before it begins processing
• Some place to output the results
 Definition
– A directed graph that shows the data dependencies
between a number of functions
– G=(V,E)
Nodes (V): each node having input/output data ports
Arces (E): connections between the output ports and input
ports
– Semantics
• Fire when input data are ready
• Consume data from input ports and produce data to its
output ports
• There may be many nodes that are ready to fire at a given
time
Data Flow Graph Construction
Control/Data Flow Graph (CDFG)
 Definition
– A directed graph that represents the control dependencies among the functions
• branch
• fall-through
– G=(V,E)
• Nodes (V)
– Encapsulated DFG
– Decision
• Arces (E)
– flow of the controls
fun0();
if (cond1) fun1();
else fun2();
fun3();
switch(test1) {
case 1: fun4();
break;
case 2: fun5();
break;
case 3: fun6();
break;
}
fun7();
 State machine model
• A program flow in system can be modeled simply by an inter-state
transition
(from one state to another).
Assumed that there are states and state transition functions, which
produce the states.
A state transition function is a function, which changes a state to its
next state
 Example
Three states in a washing machine:
‘Washing, ‘Rinsing and Drying,
A telephone process five states:
Idle, Receiving a ring, Dialing, Connected and Exchanging
messages
States of a process (function or interrupt service routine
(ISR) or task: Idle, Running, Blocked, Finished
 state transition
A programming model is to assume that the running
process (program flow) can be considered as running of
a machine in a particular state, which will lead to other
states. or thread on an event(s) resulting into state
transition
ACVM
Elevator
 System interface
up
down
Unit
open

Control floor
req

b1 Buttons inside
... b2
bN elevator
Request up1
up2 up/down
dn2 buttons on each
Resolver up3
dn3 floor
...
dnN
• State machine model
FSM
FSM model for Automatic Tea/Coffee
vending machine
SEQUENTIAL PROGRAMMING MODEL
Sequential Program model (seat belt
warning)
Flow chart - Seat belt warning system
• Sequence diagram
 Sequential programming model
• Use of multiple function calls sequentially
Sequential Programming Model of an ACVM
Concurrent model
 Concurrent process model
• Describes functionality of system in terms of two or more concurrently executing subtasks
• Many systems easier to describe with concurrent process model because inherently multitasking
• E.g., simple example:
• Read two numbers X and Y
• Display “Hello world.” every X seconds
• Display “How are you?” every Y seconds
• More effort would be required with sequential program or state machine model

PrintHelloWorld
Enter X: 1
ReadX ReadY
Enter Y: 2
Hello world. (Time = 1 s)
PrintHowAreYou
Hello world. (Time = 2 s)
How are you? (Time = 2 s)
Hello world. (Time = 3 s)
time How are you? (Time = 4 s)
Hello world. (Time = 4 s)
...
Subroutine execution over time
80
Sample input and output
 ConcurrentProcessExample() {
x = ReadX()
y = ReadY()
Call concurrently:
PrintHelloWorld(x) and
PrintHowAreYou(y)
}
PrintHelloWorld(x) {
while( 1 ) {
print "Hello world."
delay(x);
}
}
PrintHowAreYou(x) {
while( 1 ) {
print "How are you?"
delay(y);
}
}
Simple concurrent process example
Concurrent running of the processes in an
ACVM
Concurrent processing program model
Object oriented model
• Use cases:
• User
presses the floor button to summon the lift
• presses the elevator button to make the lift move to the desired floor
Floor Button/Elevator Button
illuminates when pressed
• places a elevator request when pressed
Elevator
• Moves up/down as per instruction
• Opens/closes the door
 Object Oriented Programming Model
A class can thus create many objects by copying the group and
making it functional.
Each object is functional.
Each object can interact with other objects to process the
states as per the defined behavior.
A set of classes and their objects then gives
the application program
Example of the ACVM classes and objects
1.Class GUI for graphic-user interaction. It has two methods
display_menu( ) and
get_user_input ( ) and for obtaining input for the choice of
chocolate from the child. It has method set_choice ( ) to set
the choice
selected
2. Class Read_Coins ( ) for reading the coins
inserted. It has a method read ( ), read ( ) and
read to read one, two and five rupee coins
from three ports and a method sum ( ) for
summing the total coins
3. It has methods, get_choice ( ) to get the choice and deliver ( ) for delivering
the chocolate.
4. It has methods display_wait ( ) and
display_thanks ( ) for display wait message
and thank message.
Class GUI for graphic-user interaction.
It has two methods display_menu ( ) and get_user_input ( ) and for obtaining
input for the choice of chocolate from the child.
It has method set_choice ( ) to set the choice selected
• both software and hardware are being designed in parallel
• Time flows from the left and proceeds through seven phases:
1. Product specification
2. Partitioning of the design into its software and hardware components
3. Iteration and refinement of the partitioning
4. Independent hardware and software design tasks
5. Integration of the hardware and software components
6. Product testing and release
7. On-going maintenance and upgrading
Considerations for choosing the right microprocessor for
an embedded application.
• Is it available in a suitable implementation?
• Is it capable of sufficient performance?
• Is it supported by a suitable operating system?
• Is it supported by appropriate and adequate tools?
 Device Drivers
• The availability of device drivers often is tied to the need to develop a board
support package (BSP).
• The BSP consists of the set of drivers and the integration of those drivers into
the RTOS kernel so that the RTOS operates smoothly with your hardware
during development and in the field.
• You must be experienced to create a BSP because it can be an extremely
difficult, defect-prone, and time consuming activity.
• Many RTOS customers are influenced by the availability of a BSP for their
hardware.
• This is particularly true if most of the processing hardware is a commercial off-
the-shelf (COTS), single-board computer.
• Alternatively, the design team might choose to have the RTOS vendor’s
engineering team develop the BSP.
• Although it’s an attractive alternative that can significantly reduce the
development risks, it also can be costly.
 Debugging Tools
• RTOS vendor is in the customer’s decision process at an early stage, they
have the opportunity to influence strongly how the development budget is
apportioned.
• Although this can be self-serving because the RTOS vendor realizes a
significant portion of its revenue from the sale of debugging tools, it also can
be good for the customer.
• Debugging real-time software running under a commercial RTOS is not an
easy process.
• In most cases, the user doesn’t have visibility into the RTOS code itself, so the
engineer must attempt to guess what’s going on in the system. Having RTOS-
aware tools is a great help in debugging this class of problems.
• If an RTOS vendor recommends its tool as the tool of choice, it’s legitimate to
question the assertion, but it’s also important to ask other vendors about
their abilities to debug code running under this RTOS.
 Standards Compatibility
• Because many embedded systems control devices that are mission
critical, it makes sense to be sure the RTOS software you choose has
already gone through a certification process and is deemed safe.
• For example, one RTOS vendor prominently advertises that its RTOS was
chosen for the Mars Rover.
• This fact might or might not be relevant for your application, but it does
convey a certain message about the reliability of the vendor’s code base.
 Technical Support
• For most people, reading a technical manual is a painful experience.
• First, you’re not even sure the information is in there.
• If the information happens to be in the manual, it’s either hard to find or
incredibly obtuse, so you phone the vendor.
• Don’t underestimate the need for first-class tech support.
• Your next project could be at risk of failure without it.
 Tool Chain Availability
• Choosing the embedded design and debug development tools is as important as choosing the
processor and RTOS.
• In some ways, the tool choices are even more important.
• If you don’t select the right tools up front, when design decisions also are being made, debugging
your design might take so long that the product will miss its market window.
• If you miss Comdex and are unable to show off your next generation of laser printer, for example,
it might not be worth your while to continue the product development.
• Multiprocessor designs are perfect examples of the necessity for debug strategies.
• Some telecommunications switches today contain more than 200 independent microprocessors,
happily sending terabytes of data per second back and forth to each other.
• An engineering team has no hope of debugging such a system if they didn’t design a debug
strategy at the same time they designed the system.
• When evaluating the tool chain, we should look for good, integrated coverage of these three
broad categories:
• Compiler tools
• Hardware and software debugging tools
• Performance measuring tools
 Iteration and Implementation
• The iteration and implementation part of the process represents a somewhat blurred area between
implementation and hardware/software partitioning (refer to in which the hardware and software paths diverge.
• This phase represents the early design work before the hardware and software teams build “the wall” between
them.
• The design is still very fluid in this phase. Even though major blocks might be partitioned between the hardware
components and the software components, plenty of leeway remains to move these boundaries as more of the
design constraints are understood and modeled.
• Earlier in this chapter, Mann represents the iteration phase as part of the selection process. The hardware
designers might be using simulation tools, such as architectural simulators, to model the performance of the
processor and memory systems.
• The software designers are probably running code benchmarks on self-contained, single-board computers that use
the target micro processor.
• These single-board computers are often referred to as evaluation boards because they evaluate the performance
of the microprocessor by running test code on it.
• The evaluation board also provides a convenient software design and debug environment until the real system
hardware becomes available.
• We can learn more about this stage in later chapters. Just to whet your appetite,
• however, consider this: The technology exists today to enable the hardware and software teams to work closely
together and keep the partitioning process actively engaged longer and longer into the implementation phase.
• The teams have a greater opportunity to get it right the first time, minimizing the risk that something might crop
up late in the design phase and cause a major schedule delay as the teams scramble to fix it.
 Detailed Hardware and Software Design
• This isn’t intended to teach you how to write software or design hardware.
• However, some aspects of embedded software and hardware design are unique to
the discipline and should be discussed in detail.
• For example, after one of lectures, a student asked, “Yes, but how does the code
actually get into the microprocessor?” Although well-versed in C, C++, and Java, he
had never faced having to initialize an environment so that the C code could run in
the first place.
• Therefore, I have devoted separate chapters to the development environment and
special software techniques.
• I’ve given considerable thought how deeply I should describe some of the
hardware design issues.
• This is a difficult decision to make because there is so much material that could be
covered.
• Also, most electrical engineering students have taken courses in digital design and
microprocessors, so they’ve had ample opportunity to be exposed to the actual
hardware issues of embedded systems design.
• Some issues are worth mentioning, and I’ll cover these as necessary.
 Hardware/Software Integration

• The hardware/software integration phase of the development cycle must

have special tools and methods to manage the complexity.
• The process of integrating embedded software and hardware is an
exercise in debugging and discovery.
• Discovery is an especially apt term because the software team now finds
out whether it really understood the hardware specification document
provided by the hardware team.
 Product Testing and Release
• Product testing takes on special significance when the performance of the
embedded system has life or death consequences attached.
• You can shrug off an occasional lock-up of your PC, but you can ill-afford a
software failure if the PC controls a nuclear power generating station’s
emergency system.
• Therefore, the testing and reliability requirements for an embedded
system are much more stringent than the vast majority of desktop
applications.
• Consider the embedded systems currently supporting your desktop PC: IDE
disk drive, CD-ROM, scanner, printer, and other devices are all embedded
systems in their own right.
 Maintaining and Upgrading Existing Products

• The embedded system tool community has made almost no effort to develop
tools specifically targeted to products already in service.
• At first blush, you might not see this as a problem.
• Most commercially developed products are well documented, right?
• The majority of embedded system designers (around 60 percent) maintain and
upgrade existing products, rather than design new products.
• Most of these engineers were not members of the original design team for a
particular product, so they must rely on only their experience, their skills, the
existing documentation, and the old product to understand the original design
well enough to maintain and improve it.
• Embedded system design can be divided into four major tasks:
• partitioning the function to be implemented into smaller, interacting
pieces;
• allocating those partitions to microprocessors or other hardware
units, where the function may be implemented directly in hardware
or in software running on a microprocessor;
• scheduling the times at which functions are executed, which is
important when several functional partitions share one hardware
unit;
• mapping a generic functional description into an implementation on
a particular set of components, either as software suitable for a given
microprocessor or logic which can be implemented from the given
hardware libraries.