Transcript Document
ELN5622
Embedded Systems
Class 1
Spring, 2003
Kent Orthner
[email protected]
Course Description
This course introduces students to the hardware and
software tools available for the design and debug of
microcontrollers (RISC and Fixed instruction
set)based circuit packs. The generic concepts of
embedded systems are discussed with an emphasis
on the Motorola HC11 and Intel series 8052(2)
families. Control techniques of peripherals (stepper
motors and displays) round out the course. This
course has a lab component.
Course Objectives
Develop an in-depth understanding of the operation
and design of embedded systems, including
– Hardware
– Software
– System Architecture
Develop a thorough understanding of the Motorola
68HC11 microcontroller
– Apply the knowledge to the labs and the design project
What is an Embedded
System?
What is an Embedded System?
A computing system embedded within a
device.
A system intended for a single purpose,
which includes a general purpose
processor.
Hard to define. Nearly any computing
system other than a desktop computer
What is an Embedded System?
Billions of units produced yearly, versus
millions of desktop units
Perhaps 50 per household and per
automobile
Often used for
– providing user control over a product
– to observe or control something in the “real
world” (i.e. analog)
Computer Systems are common.
PC’s
PDA’s
Laptops
Mainframes
Servers
Embedded Systems are
everywhere.
Anti-lock brakes
Auto-focus cameras
Automatic teller machines
Automatic toll systems
Automatic transmission
Avionic systems
Battery chargers
Camcorders
Cell phones
Cell-phone base stations
Cordless phones
Cruise control
Curbside check-in systems
Digital cameras
Disk drives
Electronic card readers
Electronic instruments
Electronic toys/games
Factory control
Fax machines
Fingerprint identifiers
Home security systems
Life-support systems
Medical testing systems
Modems
MPEG decoders
Network cards
Network switches/routers
On-board navigation
Pagers
Photocopiers
Point-of-sale systems
Portable video games
Printers
Satellite phones
Scanners
Smart ovens/dishwashers
Speech recognizers
Stereo systems
Teleconferencing systems
Televisions
Temperature controllers
Theft tracking systems
TV set-top boxes
VCR’s, DVD players
Video game consoles
Video phones
Washers and dryers
Characteristics of Embedded
Systems
Processor Based
Application-specific functionality
– specialized for one or one class of
applications
Interact with their environment
Characteristics of Embedded
Systems
Tight Design Constraints
– Power, Size, Timing, Cost to
manufacture
Tight Economic Constraints
– Low design costs (NRE) , faster time to
market, flexible product lines
– Not User Programmable
Stable / Reliable / Correct
Real-time Operation
Must finish processing by a deadline.
– Hard Real-time
• Missing deadlines causes a failure
• Eg. Aircraft navigation system, ABS
– Soft Real-time
• Missing deadlines causes degraded performance
• Eg. Network routers, cell phones
– Multi-rate
• Different operations have different priorities & deadlines
– Not all embedded systems are real-time systems
Why use processors?
Easy to design with.
Area & Cost Efficient : Can use the same
logic for multiple functions or tasks.
Tools are widely available.
Upgradeable
Code is reuseable.
Cheap!
Why use processors?
Alternatives:
– Custom Silicon
• Very expensive NRE
• Very long design cycle
• Complex design
– Pure Hardware Design
• Design seldom re-useable
• Debugging may require board re-spin.
• Longer design cycle
– FPGA
•
•
•
•
Complex Design
Expensive parts
Design seldom reuseable
High performance is not often required
Embedded System
Design
Embedded System Design
Requirements
Specification
Architecture
Implementation
System Integration
Verification
Hand-off to Manufacturing
Requirements
What the system is intended to do, what needs it
meets, what features it will include.
May be developed in several ways:
– talking directly to customers
– talking to marketing representatives
– providing prototypes to users for comment
Often takes the form of a ‘feature sheet’ of
‘requirements document’
Functional Requirements
–
–
–
–
–
–
What will it do
What won’t it do
Performance
Flexibility
Testability
Upgradeability
– Power
– Size
– Unit Cost (Cost to
manufacture)
– Reliability
– Correctness
Non-functional Requirements
– NRE (Non Recurring Engineering) cost
• Cost to design
– Time to prototype
– Time to Market
– Maintainability
Specification
Detailed explanation of what the system will do.
– The users / customers will get a variation of this
document,
– Includes how the user will interact with the system.
– Eg: User interface, power consumption, response
times.
The feature list often included as the first part of
the specification.
Architecture Description
Detailed explanation of how the system will
work.
– The users / customers usually do not get this
information.
– Includes data flow descriptions, block diagrams, etc.
– Eg. Software tasks, interfaces to components, etc.
Specification should not dictate an architecture.
The specification stage and the architecture stage
tend to overlap significantly.
Often, the System Specification and the
Architecture description are parts of the same
document.
Implementation
Capture the schematic, write the software, write the RTL.
– Writing the software, doing the schematc & PCB layout, writing
and verifying the RTL, etc.
This is what most people associate with “design”.
Different components may be done by different people or
teams.
Each person or team ‘unit tests’ his or her own design.
Caution: It is very tempting, and very common, for
designers to implement a system, and then document it.
This commonly leads to design problem because of the
system not being well thought out.
– Eg. Doesn’t meet power & response requirements, code size is
too big, etc.
Top Down vs. Bottom Up
Top down
– Begin at the most abstract layer, and design
successively detailed components until the design is
complete.
Bottom up
– Begin with small components and put them together to
build up the system.
Real System design mixes both
– You can’t do a proper abstract design if you don’t
know what the components are going to be, and you
can’t design proper components if you don’t know
how the system will be put together,
System Integration
Putting the different parts of the system together.
All the design teams have to work together to get
the overall system to run.
Often requires going back to the implementation.
Involves a considerable amount of testing to
make sure the product works correctly.
Verification
Making sure the product meets the requirements &
specification.
Verification Team
– The people verifying the design should be different from the designers,
and preferably, should not be too familiar with the architecture.
– The designer knows the system intimately; it is natural for him or her
to avoid errors, or to simply not see them.
Verification Hand-off
– This should not be done in parallel with integration. Instead there
should be a formal ‘hand-off’ from the system integration team to the
verification team.
– If the design fails verification and has to return to a previous stage, the
design needs to be re-verified to prevent new bugs from being
introduced.
Hand-off to Manufacturing
The designer has finished the design, and
it is time for it to be produced in numbers,
and sold.
Hand-off documents consist of:
–
–
–
–
Bill of Materials
Assembly Instructions
Troubleshooting information
Test plan / test checklist
Embedded System
Design:
Case Study
System Design Case Study
Digital Camera
Anti-lock brakes
Cruise Control
VCR Controller
Microwave
Requirements
Functionality
Performance
Size
Cost
Testability
Upgradeability
Reliability
NRE
Time to Market
Specification
Inputs
Outputs
Operations
Interfaces
Development Tools
Cost breakdown
Architecture
Processor
Hardware Components
Software Components
Software Processes
Implementation
Capture Schematic
Write & compile code
System Integration
Verification
Meet all requirements?
– Does it do what it’s supposed to?
– Does it meet stability / reliability requirements?
Microprocessor
Technology
Computer System Architecture
Input
Device
Output
Device
Processor
Processing
Subsystems
Memory
Busses
Output
Device
Processor
Input
Device
Processing
Subsystems
Memory
Input Devices
Keyboard
Mouse
Button
Touch Sensors / Touch Pad
Microphone
Camera
Scanner
Communications Receiver
Voltage Sensor
Output Devices
Display (Monitor, LCD Display)
LED
Motor
Speaker / Sound Card
Printer
Voltage output
Communications Transmitter
Peripheral Subsystems
Math coprocessor
DSP Coprocessor
Timer Subsystem
Watchdog
Memory
Volatile Memory
– Cache
– RAM
Non-volatile Memory
– ROM
– EEPROM, Flash
Mass Storage
– Hard drive
– Compact Flash
– CD / DVD
Memory Addressing
0x0002
Inst 1
Inst 2
0x0003
Inst 3
0x10F7
Inst n
Data 1
Data 2
0x0001
0x10F8
0x10F9
Memory Mapped I/O
0x0001
0x0002
0x003
Inst 1
Inst 2
Inst 3
0x10F7
0x10F8
0x10F9
Inst n
Data 1
Data 2
0x2000
0x2001
0x2002
Config
Data_In
Data_Out
4 Registers
UART 0x2000 to 0x2003
2 Address bits
0x2800
0x2801
0x2802
Config 1
Config 2
Data_Out
256 Registers
Display 0x2800 to 0x28FF
8 Address Bits
Memory
8 kBytes
0x0000 to 0x1FFF
13 Address bits
Memory Maps
0x3FFF
0x3000
0x2FFF
Display (CS2)
Total Memory Space:
= 0x0000 to 0x3FFF
= 16383
= 16kByte
0x2800
0x27FF
14 Address Lines
0x2004
0x2003
0x2000
UART (CS1)
0x1FFF
Memory
(CS0)
0x0000
Address Decoding & Chip selects
A[1:0]
UART
A[13:0]
Processor
CS1
CS2
CS0
A[7:0]
A[12:0]
Display
Memory
A[15:0]
Processor
‘Heart’ of the system – where the intelligence
and decision making lies.
Processor Characteristics:
–
–
–
–
Architecture (Harvard vs. Von Neumann)
Instruction Set (CISC, RISC, VLIW)
Pipelining
Programmer’s Model (accumulator based,
general purpose registers, stack based)
Instruction Execution
2 Basic Functions:
–
–
Move data from one location to another
Perform data transformation
Steps
1. IF: Fetch the next instruction from memory
pointed to by PC. Increment PC.
2. ID: Decode the instruction.
3. EX: Instruction Execution or Address
Calculation
4. MEM: Data Memory Access
5. WB: Write Back
Instruction Execution
Not all instructions require all stages.
–
Eg. ‘Jump’ instructions don’t read or write
memory.
Different instructions can take a different
number of clock cycles to complete.
Pipelining
The different instruction execution steps are
(mostly) independent.
Different steps can be done in parallel.
Non-Pipelined Execution:
Inst 1
IF
ID
EX MEM WB
Inst 2
t|inst
IF
ID
EX MEM WB
t|inst
Pipelining
Inst 1
Pipelined Execution:
IF
ID
EX MEM WB
Inst 2
IF
ID
EX MEM WB
Inst 3
IF
ID
EX MEM WB
Inst 4
IF
ID
EX MEM WB
Inst 5
IF
ID
EX MEM WB
Inst 6
IF
ID
t|inst
EX MEM WB
t|inst
Von Neumann Architecture
Output
Device
Processor
Input
Device
Processing
Subsystems
Memory
Von Neumann Architecture
The architecture used for all general purpose
computers.
Characteristics:
– Single Read-write memory space for data &
instructions
– The memory is addressable by location, and the
addressing scheme is not affected by the
contents.
Harvard Architecture
Instruction
Memory
Output
Device
Processor
Input
Device
Data
Memory
Harvard Architecture
Separate Instruction & Data Memories
Individual busses for each
I/O is mapped into the Data Memory
Space
More efficient
– Avoids the memory bus bandwidth
problem
Instruction Set
CISC
– Complex Instruction Set Computer
– Many different instructions, different addressing
modes.
• Eg: Can read operations from memory, perform an
operation, and write back to memory with one
operation.
– Can take many clock cycles per instruction.
Instruction Set
RISC
– Reduced Instruction Set Computer
– Very few instructions, only.
• Eg: Load from memory is one instruction, do an
operation is a second operation, and write back to
memory is a third operation.
– Usually only one clock cycle per instruction.
– Can support higher clock frequencies.
Microprocessors vs.
Microcontrollers
Microprocessor
–
–
–
–
–
–
Used in general-purpose systems
Optimized for performance
Does just the processing
No on-chip peripherals
Minimal On-chip memories
Eg. Pentium
Microprocessors vs.
Microcontrollers
Microcontroller
–
–
–
–
–
Used in special-purpose systems
Optimized for cost
On-chip peripherals & I/O components
Includes on-chip RAM, ROM, etc.
Motorola 68HC11
Microprocessors vs.
Microcontrollers