g

n
i
r
e
e
n
i
g
d
e
n
d
E
d
s
e
b
m
e
m
t
s
E
y
o
S
t
A
h
c
a
n
o
g
r
i
p
s
p
e
A
D
s
m
e
t
s
y
S

In This Section

Introduction of Embedded System

Definition of embedded system
Introduce the design process
Define an embedded systems architecture
Discuss the embedded System Model

What Is an Embedded System?

An embedded system is an applied computer system, as distinguished from
other types of computer systems such as personal computers (PCs) or
supercomputers
Definition: An Embedded System is one that has computer
hardware with software embedded in it as one of its important
components.
Its software embeds in
ROM (Read Only Memory).
It
does
not
need
secondary memories as in
a computer
SOFTWARE PROGRAM

#include <16f876a.h>
#use delay (clock=20000000)
#byte PORTB=6
main()
{
set_tris_b(0);
portb=255;
//decimal
delay_ms(1000);
portb=0x55;
//hexadecimal

What Is an Embedded System?

Following are a few of the more common descriptions of an embedded
system:
Embedded systems are more limited in hardware and/or software
functionality than a personal computer (PC).
In terms of hardware limitations, this can mean limitations in
processing performance, power consumption, memory, hardware
functionality, and so forth. In software, this typically means limitations
relative to a PCfewer applications, scaled-down applications, no
operating system (OS) or a limited OS, or less abstraction-level code
An embedded system is designed to perform a dedicated function.
Most embedded devices are primarily designed for one specific
function. However, we now see devices such as personal data assistant
(PDA)/cell phone hybrids, which are embedded systems designed to be able
to variety of functions.

What Is an Embedded System?

An embedded system is a computer system with higher quality and
reliability requirements than other types of computer systems
Some families of embedded devices have a very high threshold of quality
and reliability requirements. For example, if a cars engine controller
crashes while driving on a busy freeway or a critical medical device
malfunctions during surgery, very serious problems result.
Some devices that are called embedded systems, such as PDAs or web
pads, are not really embedded systems
There is some discussion as to whether or not computer systems that
meet some, but not all of the traditional embedded system definitions are
actually embedded systems or something else
Why dont these definitions entirely apply, today?

Embedded systems and their markets

Embedded systems and their markets

Household appliances:
Microwave ovens, Television, DVD
Players & Recorders
Audio players
Integrated systems in aircrafts and
missiles
Cellular telephones
Electric and Electronic Motor controllers
Engine controllers in automobiles
Calculators
Medical equipments
Videogames
Digital musical instruments, etc.

Systems engineering point of

view:
When

approaching embedded
systems architecture design from a
systems engineering point of view,
several models can be applied to
describe the cycle of embedded
system design.
Most of these models are based upon
one or some combination of the
following
models:

four

development

System Engineering Life Cycle

Models
four

development models:

four development

models:
1.The big-bang model
2.The code-and-fix

model
3.The waterfall
model
4.The spiral model

big-bang model
The

big-bang model, in which there

no
planning
is essentially

or

processes in place before and during

the development of a system.
Ad HOC MODEL

Big-Bang Model
Developer

receives problem statement.

Developer

works in isolation for some

extended time period.

Developer

delivers result.

Developer

hopes client is satisfied.

code-and-fix model
The code-and-fix model, in which

product requirements are

defined
But

no formal processes
are in place before the start of
development.

waterfall model
The waterfall model,
in which there is a
process for developing
a system in steps,
where results of one

step flow into

the next step.

Waterfall Model
The waterfall model is a sequential
design process, in which progress is
seen as flowing steadily downwards
(like a waterfall) through the phases of
Conception, Initiation, Analysis, Design,
Construction, Testing,
Production/Implementation, and
Maintenance.

Waterfall Model with Back Flow

(sometimes this is implied by waterfall)

Requirements

Design

Implementation

Test
Adjustments made to immediately previous phase
based on issues with successive phase.

spiral model
The spiral model, in which
there is a process for
developing a system in steps,
and
throughout the various steps,

feedback

is obtained and
incorporated back into the
process.

Embedded Systems
Design and Development
Lifecycle Model

Lifecycle Model

Life Cycle Model

Embedded Systems Design & Development Cycle

The embedded system design and development
process is divided into four phases:
Creating the architecture
Implementing the architecture
Testing the system
Maintaining the system

Embedded Systems Design & Development Cycle

Creating the Architecture is made up of six stages :a) Having a strong technical foundation (Product Concept)
b) Understanding the Architectural Business (Preliminary analysis
of Requirements)
c) Defining the architectural patterns and models (Creation of
Architecture Design)

d) Defining the architectural structures(Develop versions of Architecture)

e) Documenting the architecture (Deliver Version of Architecture)
f) Analyzing and reviewing the architecture (Review and Obtain
feedback)

Embedded Systems Architecture

The architecture of an embedded system is an
abstraction of the embedded device, meaning that it
is a generalization of the system that typically doesnt
show detailed implementation information such as
software source code or hardware circuit design.
At the architectural level, the hardware and software
components in an embedded system are instead
represented as some composition of interacting
elements.
In short, an embedded architecture includes elements
of the embedded system, elements interacting with an
embedded system, the properties of each of the
individual elements, and the interactive relationships
between the elements.

Embedded Systems Architecture

In short, an embedded architecture includes elements of the
embedded system, elements interacting with an
embedded system, the properties of each of the
individual elements, and the interactive relationships
between the elements.

Architecture-level information is physically represented in the

form of structures. A structure is one possible
representation of the architecture, containing its own set of
represented elements, properties, and inter-relationship
information

Examples of architectural structures

Examples of architectural structures

Examples of architectural structures

Why Is the Architecture of an Embedded System

Important?
The most common of challenges include:

defining and capturing the design of a system

cost limitations
determining a systems integrity, such as reliability and safety
working within the confines of available elemental functionality
(i.e., processing power, memory, battery life, etc.)
marketability and sellability
deterministic requirements

The Embedded Systems Model

1. The visual representation of the main elements and their associated

functions.
The layered approach allows readers to visualize the various
components of an embedded system and their interrelationship.
2. Modular architectural representations are typically the structures
leveraged to structure the entire embedded project.
This is mainly because the various modules (elements) within this
type of structure are usually functionally independent.
These elements also have a higher degree of interaction, thus
separating these types of elements into layers improves the structural
organization of the system without the risk of oversimplifying
complex interactions or overlooking required functionality.

The Embedded Systems Model

Lifecycle Model

Embedded Systems Design & Development Cycle

Creating the Architecture is made up of six stages :a) Having a strong technical foundation (Product Concept)
b) Understanding the Architectural Business (Preliminary analysis
of Requirements)
c) Defining the architectural patterns and models (Creation of
Architecture Design)

d) Defining the architectural structures(Develop versions of Architecture)

e) Documenting the architecture (Deliver Version of Architecture)
f) Analyzing and reviewing the architecture (Review and Obtain
feedback)

Creating the Embedded System Architecture

Stage 1: Have a Solid Technical Foundation

An Engineer Should know about all of the elements that can be

implemented in an embedded system.
This includes the possible permutations of both the hardware and
software as represented in the embedded systems model.
The von Neumann model, reflecting the major components that can
be found on an embedded board or the possible complexities that can
exist in the system software layer.

Von Neumann and Embedded Systems

Model diagrams

System Software Layer and Embedded

Systems Model diagrams

Creating the Embedded System Architecture

Stage 2: Know the ABCs (Architecture Business Cycles) of Embedded
Systems

Stage 2: Know the ABCs (Architecture Business Cycles) of

Embedded Systems

The steps of Stage 2 include:

Step 1. Understanding that ABC influences drive the
requirements of an embedded system, and that these
influences are not limited to technical ones.
Step 2. Specifically identifying all the ABC influences
on the design, whether technical, business, political
and/or social.
Step 3. Engaging the various influences as early as
possible in the design and development lifecycle and
gathering the requirements of the system.
Step 4. Determining the possible hardware and/or
software elements that would meet the gathered
requirements.

Stage 2: Know the ABCs (Architecture Business Cycles) of

Embedded Systems
Step 3
Gathering the Requirements

The process by which information is obtained from the various influences in

the ABC can vary, depending on the project, from the informal, such as
wordof-mouth (not recommended), to formal methods in which requirements
are obtained from finite-state machine models, formal specification
languages, and/or scenarios, to name a few.
Some of the most useful methods for deriving and understanding
nonfunctional requirements are through outlining general ABC features and
utilizing prototypes.

General ABC features are the characteristics of a device that the various
influence types require.

Stage 2: Know the ABCs (Architecture Business Cycles) of

Embedded Systems

Stage 2: Know the ABCs (Architecture Business Cycles) of

Embedded Systems
A prototype can be developed from scratch or can be based upon a currently
deployed product in the market, which could be any similar devices or more
complex devices that incorporate the desirable functionality
For example, if you want to design a wireless medical handheld
device for doctors, consumer PDAs that have been successfully
deployed into the market could be studied

Step 4
Deriving the Hardware and Software from the Requirements
Understanding and applying the requirements to derive feasible hardware
and/or software solutions for a particular design can be accomplished
through:
1.Defining a set of scenarios that outlines each of the requirements.
2. Outlining tactics for each of the scenarios that can be used to bring
about the desired system response.
3. Using the tactics as the blueprint for what functionality is needed in
the device, and then deriving a list of specific hardware and/or software
elements that contain this functionality.

Stage 3: Define the Architectural Patterns and Reference

Models

An architectural pattern (also referred to as architectural idioms or

architectural styles) for a particular device is essentially a high-level
profile of the embedded system.

This profile is a description of the various types of software and

hardware elements the device could consist of, the functions of these
elements within the system, a topological layout of these elements
(a.k.a. a reference model), and the interrelationships and external
interfaces of the various elements.

Figure is an example of architectural pattern information. It starts from the

top down in defining the elements for a digital TV set-top box (DTV-STB).

Stage 4: Define the Architectural Structures

The 4+1 model states that a system architect should create five
concurrent structures per architecture at the very least, and each
structure should represent a different viewpoint of the system.
What is literally meant by 4+1 is that four of the structures are
responsible for capturing the various requirements of the system. The fifth
structure is used to validate the other four, insuring that there are no
contentions between the structures and that all structures describe the
exact same embedded device, from their various viewpoints .

Stage 4: Define the Architectural Structures

Structure 1. One logical structure, which is a modular structure of

the key functional hardware and software elements in the system,
such as objects for an object-oriented based structure, or a processor,
OS, etc
Structure 2. One process structure, which is the component and
connector structure reflecting the concurrency and synchronization of
processes in a system that would contain an OS. A process structure is
recommended because it demonstrates how nonfunctional
requirements, such as performance, system integrity, resource
availability, etc., are being met by an OS.
Structure 3. A development structure describing how the hardware
and software map into the development environment. A development
structure is recommended because it provides support for
nonfunctional requirements related to the buildability of the hardware
and software

Stage 4: Define the Architectural Structures

Structure 4. A deployment/physical structure showing how software

maps into the hardware. A deployment/physical structure is
recommended because, like the process structure, it demonstrates how
nonfunctional requirements such as hardware resource availability,
processor throughput, performance, and reliability of the hardware are
met by demonstrating how all the software within the device maps to
the hardware.

Stage 5: Document the Architecture

Step 1: A document outlining the entire architecture.

This step involves creating a table of contents that outlines the
information and documentation available for the architecture, such
as: an overview of the embedded system, the actual requirements
supported by the architecture, the definitions of the various
structures, the inter-relationships between the structures, outlining
the documentation representing the various structures, how these
documents are laid out (i.e., modeling techniques, notation,
semantics, etc.), and so on.
Step 2: A document for each structure.
This document should indicate which requirements are being
supported by the structure and how these requirements are being
supported by the design, as well as any relative constraints, issues,
or open items.

Some of the most common include the Universal Modeling Language

(UML) by the Object Management Group (OMG) that defines the
notations and semantics for creating state charts and sequence diagrams
that model the behavior of structural elements, and the attribute driven
design (ADD) that, among other templates, provides a template for
writing the interface
information.

Step 3: An architecture glossary.

This document lists and defines all of the technical terms used in all of the
architectural documentation.
Stage 6: Analyze and Evaluate the Architecture
The most common of these approaches typically fall under an
architecture-oriented approach, a quality attribute-based approach, or
some combination of these two approaches.
In architecture-oriented approaches, scenarios to be evaluated are
implemented by the system stakeholders and/or an evaluation team (with
stakeholder representatives as a subset of the team).
A quality attribute approach is typically considered either qualitative
or quantitative. Under the qualitative-analysis approach, different
architectures with the same quality attributes (a.k.a. features of a system
that nonfunctional requirements are based upon) are compared by an
architect and/or by an evaluation team depending on the specific
approach.

Microprocessors:
General-purpose microprocessor

CPU for Computers

No RAM, ROM, I/O on CPU chip itself

Example Intels x86, Motorolas 680x0

CPU
GeneralPurpose
Microprocessor

Many chips on mothers board

Data Bus

RAM

ROM

I/O
Port

Address Bus
General-Purpose Microprocessor System

Timer

Serial
COM
Port

Microcontroller :
A smaller

computer
On-chip RAM, ROM, I/O ports...
Example Motorolas 6811, Intels 8051, Zilogs Z8 and PIC 16X

CPU
I/O
Port

RAM ROM
Serial
Timer COM
Port

A single chip
Microcontroller

Microprocessor

Microcontroller

Microprocessor Contains ALU ,

General Purpose Registers, SP,
PC Clock Timing Circuit and
Interrupt control Circuit

Microcontroller Contain the

Circuitry of P and in Addition it
has built in ROM, RAM , I/O
Ports, Timers and Counters

It has one or two Bit handling

Instructions

It has many Bit handling

Instructions

The Instruction set of

microprocessor is complex with
large number of instructions.

The instruction set of a

Microcontroller is very simple
with less number of
instructions.

Less Number of pins are

Multifunctional

More Number of pins are

Multifunctional

Access Time for Memory & I/O

devices are more

Less Access time for Built in

Memory and I/O Devices

It has Single memory map for

data and Code.

Separate Memory Map for data

and Code

Microprocessors are most

commonly used as the CPU in
microcomputer systems

Microcontrollers are used in

small, minimum component
designs performing controloriented embedded

History of microcontroller
The first microcontroller TMS1000 was introduced

by Texas Instruments in the year 1974.

In The year 1976, Motorola designed a
Microprocessor chip called 6801
In 1976, Intel company produced its first
Microcontroller 8048
In 1980 , Intel produced most popular controller
8051 .
INTEL introduced a 16 bit microcontroller 8096 in
the year 1982
Microchip, another company has introduced an 8bit Microcontroller PIC 16C64 in the year 1985.
59

TYPES OF
MICROCONTROLLERS
Microcontrollers can be classified on:the basis of internal

bus width, architecture, memory and instruction set as 4bit,8-bit,16-bit and 32-bit microcontrollers.

4-bit Microcontrollers: These 4-bit microcontrollers are

small size, minimum pin count and low cost controllers

which are widely used for low end applications like LED &
LCD display drivers ,portable battery chargers etc.. Their
power consumption is also low. The popular 4-bit controllers
are Renasa M34501, ATAM862 series from ATMEL.
8-bit Microcontrollers : 8-bit microcontroller has 8-

60

bitinternal bus .The well known 8-bit microcontroller is

8051 which was designed by Intel in the year 1980 for the
use in embedded systems. Other 8-bit microcontrollers are
Intel 8031/8052 and Motorola MC68HC11 Microchips PIC
Microcontrollers 12C5XX ,16C5X and 16F8XX

TYPES OF
MICROCONTROLLERS :
16-bit Microcontrollers : The internal bus width of 16-bit

microcontroller is of 16-bit. These microcontrollers are having

increased memory size and speed of operation when
compared to 8-bit microcontrollers. These are most suitable
for programming in High-level languages like C or C ++ .
Examples of 16-bit microcontrollers are Intel 8096 family and
Motorola MC68HC12 and PIC 24F Family.

32-Bit Microcontrollers :These microcontrollers used in

high-end applications like Automotive control,

Communication networks,Robotics,Cell phones ,GPRS & PDAs
etc..For EX:PIC32,ARM 7,ARM9 ,,ATMEL 32 (AVR) ,Texas
Instruments . TMS320F2802x/2803x etc.are some of the
popular 32-bit microcontrollers.
61

MICROCONTROLLER
DEVELOPMENT TOOLS
1. Editor : An Editor is a program which allows us to create a

file containing the assembly language statements for the

program. Examples of some editors are PC write WordStar..
After typing all the program we have to save the program .
This we call it as source file. The next step is to process the
source file with an assembler
2.Assembler : An Assembler is used to translate the

assembly language mnemonics into machine language( i.e.

binary codes). When you run the assembler it reads the
source file of your program from where you have saved it.
The assembler generates a file with the extension .hex. This
file consists of hexadecimal values encoding a sequence of
data and their starting offset or absolute address.
62

MICROCONTROLLER
DEVELOPMENT TOOLS
3.Compiler : A compiler is a program which converts the

high level language program like C into binary or

machine code. Using high level languages it is easy to
manage complex data structures which are often required
for data manipulation. Compilers like Keil ,Ride and IAR
workbench are very popular.

4. Debugger/Simulator : A debugger is a program

which allows execute the program, and troubleshoot or

debug it. The debugger allows to look into the contents of
registers and memory locations after the program runs.
63

64

Criteria for Choosing a Micro- Controller

Criteria for Choosing a Micro Controller