Module 1

Introduction
Embedded System Introduction

Embedded Systems Characteristics
Embedded System Design Process
Object-Oriented Design
Unified Modeling Language (UML)
Design Example: Model Train Controller
Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 1


Definition
Embedded system: any device that
includes a programmable computer but is
not itself a general-purpose computer
e.g., PDA, printer, cell phone
e.g., TV, household appliances
e.g., automobiles: engine, brakes, etc
NOT-e.g., PC

Embedded System Example
output analog
input analog
CPU
mem
embedded
computer

2-layered System Architecture
THE Application
Operating
System Graphics
Kernel Subsystems Scheduler I/O Manager
Network Device Graphics

Drivers Drivers Drivers
Hardware

3-layered System Architecture
Processes Applications Applications
Operating Graphics
System Subsystems Scheduler I/O Manager
Kernel
Network Device Graphics
Drivers Drivers Drivers
Hardware

Early History (1/2)
Late 1940s: MIT Whirlwind computer was
designed for real-time operations
to control aircraft simulator
First microprocessor: Intel 4004 in early 1970s
microprocessor: a single-chip CPU
Key breakthrough: HP-35 (1972)
due to the high cost of VLSI design, reuse the HW
design by changing the SW
1st handheld calculator to compute complex math
functions
HP-35 uses several chips to implement the CPU

Early History (2/2)
Automobiles used microprocessor-based
engine controllers starting in 1970s.
Controlfuel/air mixture, engine timing, etc.
2 pushes: oil crisis & environment protection
low fuel consumption & low emission
Multiple modes of operation: warm-up,
cruise, hill climbing, etc.
sophisticated control can only be done with
microprocessors
Microprocessor Varieties
Microcontroller: includes I/O devices, on-
board memory
Players: Intel, ARM, Motorola, Hitachi
Digital signal processor (DSP):
microprocessor optimized for digital
signal processing
Players: Analog Devices, Motorola, TI
Typical embedded word sizes: 8-bit, 16-
bit, 32-bit
Application Examples
Front panel of microwave oven
Advanced thermostat systems
time-temperature settings
Canon EOS 3 has 3 microprocessors
32-bit RISC CPU runs auto-focus and eye-control
system
Analog TV: channel selection, etc
Digital TV: audio processing CPU
easier to design & debug
possibility of upgrades

Automotive Embedded Systems
Todays high-end automobile may have
100 microprocessors:
4-bitmicrocontroller checks seat belt
microcontrollers run dashboard devices
16/32-bit microprocessor controls engine

BMW 850i Brake & Control System
Anti-lock brake system (ABS): pumps
brakes to reduce skidding
Automatic stability control (ASC+T):
controls engine to improve stability
ABS and ASC+T communicate

BMW 850i
sensor sensor
brake brake
hydraulic
ABS
pump
brake brake
sensor sensor

Review Slides (1)
Embedded system definition? examples?
First microprocessor?
HP-35 significance?
Microprocessor usage in automobiles?
Microcontroller? DSP?


Embedded Systems Characteristics (1/2)
Complex algorithms
e.g., automobile engine control system
Sophisticated user interface
e.g., GPS navigation system
Real-time operation
hard-real-time
e.g. life-critical system
soft-real-time
e.g. GPS navigation system

Embedded Systems Characteristics (2/2)
Multirate functionality
e.g., multimedia applications (video & audio)
Low manufacturing cost
Low power
excessive power consumption increases system cost
Designed to tight deadlines by small teams
6-month market window is common
e.g. cannot miss back-to-school window for
calculators

Why use microprocessors?
Alternatives: field-programmable gate
arrays (FPGAs), custom logic, etc.
Microprocessors are often very efficient:
can use same logic to perform many
different functions
Microprocessors simplify the design of
families of products

The Performance Paradox
Microprocessors use much more logic to
implement a function than does custom logic
instruction cycle: fetch, decode, execute, write
however, for a set of family functions,
microprocessors may use less logic
But microprocessors are often at least as fast:
heavily pipelined
large design teams
aggressive VLSI technology
Microprocessors dominate new fabrication lines
custom logics have to wait and use old VLSI technology
Power
Custom logic is a clear winner for low
power devices
Modern microprocessors offer features to
help control power consumption
Software design techniques can help
reduce power consumption

Embedded System Design Challenges (1/2)
How much hardware do we need?

How big is the CPU? Memory?
more hardware capabilities more money
How do we meet our deadlines?
Faster hardware or cleverer software?
How do we minimize power?
Turn off unnecessary logic? Reduce memory
accesses? run at slower clock rate?

Embedded System Design Challenges (2/2)
Does it really work?

Isthe specification correct?
Does the implementation meet the spec?
How do we test for real-time characteristics?
How do we test on real data?
How do we work on the system?

Observability,controllability?
What is our development platform?

Review Slides (2-1)
Embedded systems characteristics?
complex algorithms, complicated UI, real-time ops,
multi-rate functions, low powers, tight deadline &
budget
FPGA, ASIC, Microprocessor
manufacturing cost, power, efficiency, size,
development cost
Microprocessor efficiency factors
pipelined, large design teams, latest VLSI
Embedded system design challenges?
HW usage, efficiency, power, testing, platform
Review Slides (2-2)
FPGA ASIC Microproc
Manu Cost
Flexibility
Functions
Gate #
Design Team
VLSI Tech
Power Req
Exec Speed
Review Slides (2-2)
FPGA ASIC Microproc
Manu Cost Medium Cheap Expensive
Flexibility Medium Low High
Functions Medium Less More
Gate # Medium Low High
Design Team Small Medium Large
VLSI Tech Medium Low-end High-end
Power Req Medium Low Medium*
Exec Speed Medium Fast Fast*

Growth Rate of Embedded Software
already to-day, more than 98% of all
microprocessors are used within
factor
embedded systems
]
TI*
2
[D
w ]
la
e
yr ar e
s
r
5/ w
o o
2 . ft
)
[ M
(~ so
a r) >10 times more

e
ed
4 /y programmers will write

(1.
d
ed
embedded applications than

b
Em
computer software by 2010
1
*) Department of Trade and Industry, London
0 10 12 18 months

2004, reiner@hartenstein.de http://hartenstein.de
Submarine Programming Model
Algorithm
This model does not suport tware
S of
Hardware / Configware / procedural high level
Software partitioning Programming Language
Assembly Language
Hardware invisible:
under the surface
Hardware

Dominance of the Submarine Model ...
(procedural) structurally
disabled Hardware
... indicates, that our CS education

system produces zillions of
mentally disabled CS graduates
disabled to cope with

solutions other than
instruction-stream-based

Built From Bottom-Up
You cannot *teach have structural natural
Hardware to a
Programmer
*) efficiently
have not procedural
But to a Hardware Guy

you always can teach
Programming
Design Methodologies
A procedure for designing a system
Understanding your methodology ensures
you didnt skip anything
Compilers, software engineering tools,
computer-aided design (CAD) tools, etc.,
can be used to:
helpautomate methodology steps
keep track of the methodology itself

Design Goals
Performance.
Overall speed, deadlines
Functionality and user interface
Manufacturing cost
Power consumption
Other requirements (physical size, etc.)

Design Process Abstraction
requirements
top-down bottom-up
design specification design
architecture
component
design
system
integration
Top-down vs. Bottom-up
Top-down design:
startfrom most abstract description
work to most detailed
Bottom-up design:
work from small components to big system
Real design uses both techniques

Step-1: Requirements
Plain language description of what the
user wants and expects to get
May be developed in several ways:
talking directly to customers
talking to marketing representatives
providing prototypes to users for comment

Sample Requirement Form
name project name
purpose one or 2 sentences
inputs type of data? periodic
or non-periodic?
outputs I/O devices?
functions inputs outputs
performance real-time req?
manufacturing cost rough estimation
power battery or wall-
powered
physical size/weight e.g., PC or NB?
Example: GPS moving map requirements
Moving map
obtains position I-78
from GPS, paints
Scotch Road
map from local
database.
lat: 40 13 lon: 32 19

Step-1 of GPS moving map (1/3)
Functionality: Show major roads and
landmarks for automotive use
User interface: At least 400 x 600 pixel
screen. Three buttons max. Pop-up menu.
Performance: Map should scroll smoothly.
No more than 1 sec power-up. Lock onto
GPS within 15 seconds.
Cost: $500 street price = approx. $100
manufacturing cost.
Physical size/weight: Should fit in hand
Power consumption: Should run for 8
hours on four AA batteries

name MGPS: GPS moving map
purpose consumer-grade moving map
for driving
inputs power button, two control
buttons
outputs back-lit LCD 400 X 600
functions 5-receiver GPS; three
resolutions; displays current
lat/lon
performance updates screen within 0.25
sec of movement
manufacturing cost $100 cost-of-goods-sold
power 100 mW
physical size/weight no more than 2 X 6, 12 oz.

Step-2: Specifications
A more precise description of the system:
should NOT imply a particular architecture
provides input to the architecture design process
Serve as a contract between customers and
architects
May include functional and non-functional
elements.
May be executable or may be in mathematical
form for proofs

Step-2 of GPS moving map
Should include:
What is received from GPS
map data
user interface
operations required to satisfy user requests
background operations needed to keep the
system running

Step-3: Architecture Design
Describe how the system implements the
required functions
Specifications: what the system does
Architecture: how the system does things
Hardware components:
CPUs, peripherals, etc.
Software components:
major programs and their operations.
Must take into account functional and non-
functional (cost, speed, etc) specifications
Step-3: GPS moving map block
diagram (1/3)
GPS search display

renderer
receiver engine
user
database interface

Step-3: GPS moving map Hardware
Architecture (2/3)
display frame CPU

buffer
GPS
receiver
memory
panel I/O

Step-3: GPS moving map Software
Architecture (3/3)
database pixels
renderer
search
user
position timer
interface

Step-3: Architecture Design (cont)
Functional block diagram first SW/HW
architecture
SW HW module mapping
Make sure both functional and non-functional
requirements are satisfied
Otherwise, redo Step-3 again
How to make sure non-functional requirements
are satisfied?
Experience
Modeling
Simulation
Step-4: Designing Hardware and
Software Components
Must spend time architecting the system
before you start coding
Some components are ready-made (e.g.,
CPU, topographic databases), some can
be modified from existing designs, others
must be designed from scratch

Step-5: System Integration
Put together the components
Many bugs appear only at this stage
Have a plan for integrating components
to uncover bugs quickly, test as much
functionality as early as possible

Summary
Embedded computers are all around us
Many systems have complex embedded
hardware and software
Embedded systems pose many design
challenges: design time, deadlines,
power, etc.
Design methodologies help us manage the
design process

Review Slides (3)
Common design goals?
Performance, functionality, user interface,
cost, power, size, weight
5-step design process?
Requirements? Requirement form?
Specification?
Architecture design?
Component design?
System integration?

System Modeling
Need languages to describe systems:
usefulacross several levels of abstraction;
understandable within and between
organizations
Block diagrams are a start, but dont
cover everything

Object-oriented (OO) design: A
generalization of object-oriented
programming
OO design is different from OO programming
Object = state + methods
State provides each object with its own
identity
Methods provide an abstract interface to the
object

OO implementation in C++
class display {
pixels : pixeltype[IMAX,JMAX];
public:
display() { } // constructor
pixeltype pixel(int i, int j) { return pixels[i,j]; }
void set_pixel(pixeltype val, int i, int j)
{ pixels[i,j] = val; }
}

Objects and Classes
Class: object type
Class defines the objects state elements
Class defines the methods used to
interact with all objects of that type
Each object has its own state (memory)

OO Design Principles
Some objects will closely correspond to
real-world objects
Some objects may be useful only for
description or implementation
Not every object is executable
Objects provide interfaces to read/write

state, hiding the objects implementation
from the rest of the system


UML
Developed by Booch et al.
Goals:
object-oriented
visual
usefulat many levels of abstraction
usable for all aspects of design

UML object
object name
class name
d1: Display
pixels is a pixels: array[] of pixels

2-D array elements
menu_items
comment
attributes

UML class
Display
class name
pixels
elements
menu_items
mouse_click()
operations
draw_box()

The class interface
The operations provide the abstract
interface between the classs
implementation and other classes
Operations may have arguments, return
values
An operation can examine and/or modify
the objects state

Class Derivation
May want to define one class in terms of
another
Derived class inherits attributes, operations
of base class
Derived_class
UML
generalization
Base_class

Class Derivation Example
Display
base
pixels class
elements
menu_items
pixel()
derived class set_pixel()
mouse_click()
draw_box
BW_display Color_map_display

Multiple Inheritance
base classes
Speaker Display
Multimedia_display
derived class

Links and Associations
Link: describes relationships between
objects
Association: describes relationship
between classes

Association Example
# contained messages # containing message sets
message message set

0..* 1
msg: ADPCM_stream
count : integer
length : integer contains
0 or more messages

Link Example
Link defines the contains relationship:
m1:message
msg = msg1 ms1:message set
length = 1102
count = 2
m2:message
msg = msg2
length = 2114

State Machines
transition
a b
state state name

Event-Driven State Machines
Behavioral descriptions are written as
event-driven state machines
Machine changes state when receiving an
input
An event may come from inside or
outside of the system

Event Type
Signal: asynchronous event
Call: synchronized communication
Timer: activated by time

Signal Event
<<signal>>
mouse_click a
leftorright: button
mouse_click(x,y,button)
x, y: position
b
declaration
event description

Call Event (Procedural Call)
draw_box(10,5,3,2,blue)
c d

Timer Event
State change after a certain amount of time
time-value = amount of time to expire
tm(time-value)
e f

Example State Diagram
start input/output
mouse_click(x,y,button)/ region = menu/
find_region(region) which_menu(i) call_menu(i)
region got menu called
found item menu item
region = drawing/
find_object(objid) highlight(objid)
found object
object highlighted
finish
Sequence Diagram
Shows sequence of operations over time
Relates behaviors of multiple objects

Sequence Diagram Example
m: Mouse d1: Display u: Menu
mouse_click(x,y,button)
which_menu(x,y,i)
time
call_menu(i)
lifeline

Summary
Object-oriented design helps us organize
a design
UML is a transportable system design
language
Provides structural and behavioral
description primitives


Model train setup
rcvr motor
power
supply
console
header address command ECC

Step-1: Requirements (1/2)
Console can control 8 trains on 1 track
Throttle has at least 63 levels
Inertia control adjusts responsiveness
with at least 8 levels ()
Emergency stop button
Error detection scheme on messages

Step-1: Requirements Form (2/2)
name model train controller
purpose control speed of <= 8 model trains
inputs throttle, inertia, emergency stop,
train #
outputs train control signals
functions set engine speed w. inertia;
emergency stop
performance can update train speed at least 10
times/sec
manufacturing cost $50
power wall powered
physical console comfortable for 2 hands; < 2
size/weight lbs.

Step-2: Conceptual Specification
Before we create a detailed specification,
we will make an initial, simplified
specification
Gives us practice in specification and UML.
Good idea in general to identify potential
problems before investing too much effort in
detail

Basic System Commands
command name parameters
set-speed speed
(positive/negative)
set-inertia inertia-value (non-
negative)
estop none

UML Sequence Diagram
:console :train_rcvr
set-inertia
set-speed
set-speed
estop
set-speed

Class Diagram
command
set-speed set-inertia estop

value: unsigned-
value: integer
integer

Subsystem Collaboration Diagram
Shows relationship between console and
receiver (ignores role of track):
One console can control up to 8 receivers
1..n: command
:console :receiver

System Structure Modeling
Some classes define non-computer
components
Denote by *name
Choose important systems at this point to
show basic relationships

Major Subsystem Roles
Console:
read state of front panel
format messages
transmit messages
Train:
receive message
interpret message
control the train

Console System Class Diagram
console
1 1
1 1 1
1
panel formatter transmitter
1 1 1 1
Knobs* sender*

Console class roles
panel: describes analog knobs and
interface hardware
formatter: turns knob settings into bit
streams
transmitter: sends data on track

Train System Class Diagram
train set
1
1..t
1 1
train
1 1 motor
receiver interface
1 1
1 controller 1
1 1
detector* pulser*

Train class roles
receiver: digitizes signal from track
controller: interprets received commands
and makes control decisions
motor interface: generates signals
required by motor

Detailed Specification
We can now fill in the details of the
conceptual specification:
more classes
behaviors
Sketching out the spec first helps us

understand the basic relationships in the
system

Console Physical Object Classes
knobs* pulser*
train-knob: integer pulse-width: unsigned-
speed-knob: integer integer
inertia-knob: unsigned- direction: boolean
integer
emergency-stop: boolean
sender* detector*
send-bit() read-bit() : integer

Panel and Motor Interface Classes
panel motor-interface
speed: integer
train-number() : integer
speed() : integer
inertia() : integer
estop() : boolean
new-settings()

Class Descriptions
panel class defines the controls
new-settings() behavior reads the controls
motor-interface class defines the motor
speed held as state

Transmitter and Receiver Classes
transmitter receiver
current: command
send-speed(adrs: integer, new: boolean
speed: integer)
send-inertia(adrs: integer, read-cmd()
val: integer) new-cmd() : boolean
set-estop(adrs: integer) rcv-type(msg-type:
command)
rcv-speed(val: integer)
rcv-inertia(val:integer)

Class Descriptions
transmitter class has one behavior for
each type of message sent
receiver function provides methods to:
detect a new message
determine its type
read its parameters (estop has no parameters)

Formatter Class
formatter
current-train: integer
current-speed[ntrains]: integer
current-inertia[ntrains]:
unsigned-integer
current-estop[ntrains]: boolean
send-command()
panel-active() : boolean
update-panel()
Formatter Class Description
Formatter class holds state for each train,
setting for current train
The operate() operation performs the
basic formatting task
Control Input Cases
Use a soft panel to show current panel
settings for each train
Changing train number:
must change soft panel settings to reflect
current trains speed, etc.
Controlling throttle/inertia/estop:
read panel, check for changes, perform
command
Control Input Sequence Diagram
:knobs :panel :formatter :transmitter
change in read panel
change in change in speed/
control panel-active
train number inertia/estop
settings panel settings

send-command
read panel
send-speed,
panel settings send-inertia.
read panel send-estop
change in
train number panel settings
new-settings
set-knobs
Formatter Operate Behavior
update-panel()
panel-active() new train number

idle
send-command()
other
Panel-active behavior
T current-train = train-knob
panel*:read-train() update-screen
changed = true
F
T
panel*:read-speed() current-speed = throttle
changed = true
F
... ...
Controller Class
controller
current-speed: integer
current-inertia: unsigned-integer
set-speed(integer)
set-inertia(integer)
new-speed(integer)
Setting the Speed
Dont want to change speed
instantaneously
Controller should change speed gradually
by sending several commands
Set-Speed Sequence Diagram
:receiver :controller :motor-interface :pulser*
new-cmd
cmd-type
rcv-speed new-speed set-pulse
set-pulse
set-pulse
set-pulse
set-pulse
Refined Command Classes
command
type: 3-bits
address: 3-bits
parity: 1-bit
set-speed set-inertia estop

type=010 type=001
type=000
value: 7-bits value: 3-bits
Summary
Separate specification and programming
Small mistakes are easier to fix in the spec
Big mistakes in programming cost a lot of
time
You cant completely separate
specification and architecture
Make a few tasteful assumptions
Useful Links
http://www.uml.org/
Official UML resource page
You will find many good links here
http://www.raba.com/~jcstaff/oodev/presents
/uml/intro_uml/
A pretty good introduction to UML
http://www.softdocwiz.com/UML.htm
UML Dictionary
http://uml.tutorials.trireme.com/
A relatively complete UML tutorial

Module 1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Module 1

Încărcat de

Drepturi de autor:

Formate disponibile

Introduction

Embedded System Introduction

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 1

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 2

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 3

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 4

Network Device Graphics

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 5

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 6

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 7

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 10

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 11

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 12

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 13

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 14

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 15

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 16

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 17

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 18

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 20

How much hardware do we need?

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 21

Does it really work?

How do we work on the system?

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 22

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 26

a r) >10 times more

4 /y programmers will write

embedded applications than

computer software by 2010

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 27

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 28

... indicates, that our CS education

disabled to cope with

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 29

have not procedural

But to a Hardware Guy

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 31

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 32

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 34

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 35

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 37

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 39

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 40

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 41

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 42

GPS search display

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 44

display frame CPU

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 45

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 46

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 48

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 49

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 50

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 52

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 53

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 54

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 55

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 56

Objects provide interfaces to read/write

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 57

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 58

Module-1 Embedded Computing Embedded System Design - NTHU EOS Lab 59