Transcript Ch. 1 Intro to Embedded Microcomputer Systems

Ch. 1 Intro to Embedded
Microcomputer Systems
From the text by Valvano
Intro to Embedded Systems :
Interfacing to the Freescale9S12
Objectives (pg 1 of text)
• Introduce embedded microcomputer
systems
• Outline the basic steps in developing
microcomputer systems
• Define data flow graphs, flowcharts and
call graphs.
1.1 Basic Components of an
Embedded System
• Fig. 1.1 (page 2) Typical Metal Oxide
Semiconductor (MOS) Circuit (shows
on/off states)
• Fig. 1.2 Byte (8 bits)
• Fig. 1.3 Memory
– Sequential collection of data storage elements
• Fig. 1.4 (page 4)Microcomputer interfaced
to external devices—an embedded
system.
Checkpoints (answers on page
529)
• 1.1 What is an embedded system?
• 1.2 What is a microcomputer?
• 1.3 What are some input devices available
on a general purpose computer?
• 1.4 What are some output devices
available on a general purpose computer?
1.2 Applications
• An embedded computer system (p.9 of
text)
– Microcomputer
– Mechanical, Chemical, and Electrical Devices
– Programming is for a specific purpose.
1.3 Flowcharts and Structured
Programming
• Flowcharts
• Data Flow graphs
• Call graphs
Flow Charts
• Fig. 1.6 shows the basic building blocks of
structured programming.
– Sequence—rectangles are processing blocks.
– Conditional
– While-loop
Flowcharts
–
Fig. 1.7 (p. 9) illustrates the process of making toast
(Example 1.1)
• Ovals—entry/exit
• Parallelograms—input/output operations
• Diamond Shapes—decision blocks (branch
points)
• Rectangle with double lines—predefined
functions
• Circles—connectors
– Checkpoint 1.6—What safety feature might you add
to the toaster to reduce the chance of a fire? (p.529)
Example 1.2 (p.9)
• Design a flowchart to illustrate the process
of reading a book.
– Solution: Figure 1.8
– Concept of a subroutine is introduced.
– A complex system is broken down into smaller
components so it is easier to understand.
– Thread—a software task.
Thread in Ex. 1.2
• A—next word is read
• B –the word is not understood and the
subroutine Lookup is called.
• C—knowledge is recorded in a process block
(remember).
• D—dictionary is used to define the unknown
word.
• A simple thread is shown on page 10 (ten words
make up the book (A0,….,A9 and word 4 and
word 7 are not known.
1.4 Concurrent and Parallel
Programming
• Parallel Programming—the computer
executes multiple threads at the same
time.
• Fig. 1.9 illustrates the fork and join
process (p.10)
Concurrent Programming
• Concurrent Programming—multiple
threads can be executed, but sequentially.
• Fig. 1.9 illustrates the interrupt process.
• Interrupts have a hardware trigger, but this
allows the software to execute and
“handle” the interrupt.
• An interrupt can be thought of as a
subroutine without parameters passed.
Interrupt Service Routine (ISR)
• Foreground threads are considered the
main program.
• Background threads are the ISR’s.
Example 1.3 (p.11 of text)
•
Two tasks
1. Output apulse on PTT every 1.024 ms in
real time.
2. Find all the prime numbers (no time
constraint).
Solution to Example 1.3
• Figure 1.10 shows the flow chart for a
multithread solution.
– PTT is the output that the pulse will be placed.
– The timer will be set to generate an interrupt
every 1.024 seconds.
– The ISR (a background thread) causes the
output PTT to go high and then low.
– Tasks that are not time critical can be handled
in the foreground (such as the calculation of
the prime numbers.)
Solution to Example 1.3 (cont.)
• < --symbol used to indicate exiting of the main
program and the beginning of the ISR.
• >--symbol used to indicate the end of the ISR
and the return to the main program.
• Letters A-F indicate the software tasks, and the
subscript indicates n.
• A possible execution of the two threaded system
(page 12) illustrates the foreground and
background threads.
Example of Parallel Programming
• Figure 1.11 (page 12 of text) illustrate the
finding of the maximum value in a bufffer.
1.5 Product Development Cycle
•
Figure 1.12 (page 13) illustrates the
product development cycle.
1.
2.
3.
4.
Analysis—requirements and constraints
Design—specifications and constraints
Implementation
Testing
Development Cycle (cont.)
• Requirements—specific parameters that
the system must satisfy.
• Specifications—detail parameters that
describe how the system should work.
• Constraint—a limitation of the operation of
the system.
• Page 13 shows a list of measures often
considered during analysis.
Checkpoint
• Checkpoint 1.7 what’s the difference
between a requirement and a
specification?
Software Requirements Documents
• IEEE publisheds a number of templates
(IEEE STD 830-1998).
• Requirement documents describes what
the system will do, not how it is done.
• Can be a legally binding contract between
client and software developer.
• Page 14 illustrates an example.
High Level Design Phase
• Build a conceptual model of the
hardware/software system.
• Data flow graphs can be used as a high
level design (details are hidden).
• Figure 1.13 illustrate a data flow graph.
Engineering Design
• Call graphs can be used to graphically how
hardware/software modules interconnect.
• Figure 1.14 (page 15) shows a call-graph for the
position measurement system described in
Figure 1.13—here rectangles are hardware
components and ovals represent software.
• Arrows are drawn from the calling routine to the
module it calls.
• Data structures —includes both the
organization of information and mechanisms to
access the data.
Implementation
• Simulation can be used during the first iterations.
• Rapid prototyping allows for a more sophisticated
product to be produced in the early cycles.
• Embedded Systems
– Cross-assemblers and cross-compilers allow source code to be
produced for the target system.
– Machine code is then loaded into the target system.
– Debugging can be difficult.
– Simulation models the behavior of the hardware/software system
and allows study of the software/hardware interaction—
debugging can be less difficult.
Last Phases
• Testing –debug system and measure
performance.
• Maintenance
–
–
–
–
–
Correct mistakes
Add new features
Optimize execution speed and/or program size
Porting to new computers or operating systems
Reconfiguration of the system to solve problems
• Maintenance requires additional loops around
the development cycle.
Top-Down and Bottom-Up
• Figure 1.12 is a top-down cyclic design process.
• Figure 1.15 shows a bottom-up design.
• Bottom-up begins with a “solution” and ends with
a “problem statement”.
• Bottom-up could be inefficient if subcomponents
are developed but never used.
• If the problem is well understood, then top-down
could be quicker, but on the other hand, bottom
up allows for the problem to be learned at the
start (p.17 of text).
1.6 Successive Refinement
• Converting a problem statement into an
algorithm:
– Successive refinement
– Stepwise refinement
– Systematic decomposition
• All three are equivalent.
• Start with a task, decompose the task into
simpler tasks until the sub,…,subtask is so
simple it can be converted to source code.
Decomposing a Task
• Three ways using strucutred programming
– Sequential
– Conditional
– Iterative (while loop)
– See Figure 1.16, p. 17
• Time critical tasks can use interrupt
synchronization.
• On page 18 are a list of equations and
phrases that can be useful.
Example 1.4
• Build a digital door lock using seven
switches. (Page 18).
• Solution
– Seven binary inputs
– One binary output
– State (door locked, door unlocked)
– Figure 1.17 shows decomposition using the
structured programming blocks (Page 18)
– More in Chapter 5.
1.7 Quality Design
• 1.7.1 Quantitative Performance
Measurements
– Dynamic efficiency (how fast the program
executes)
– Static efficiency (memory required)
• Stack and global variables fit into RAM.
• Fixed constants and program must fit into ROM.
– Others: Requirements and Contraints
1.7 Quality Design (cont.)
• 1.7.2 Qualitative Performance
Measurements
– Parameters that cannot be assigned a direct
numerical value.
– Examples
• Prove the software works
• Is the software easy to understand?
• Is the software easy to change?
1.7.3 Attitude
•
•
“Writing quality software has a lot to do with
attitude.” (page 20 of text)
Ways to improve the software:
1.
2.
3.
4.
Test it now.
Plan for testing.
Get help.
Deal with the complexity.
–
–
OLD days—100’s of lines of code, 1000’s of bytes of
memory
By next decade—autos may have 10,000,000 lines of
code.
1.8 Debugging Theory
• Debugging instruments could be hardware or software.
• Hardware
– Probes like a logic analyzer
– In-circuit-emulator (ICE)
• Software
– Simulators
– Monitors
– Profilers
• Other—manual tools such as inspection and print
statements.
• Intrusiveness—if not invasive then the debugging tool
allows the software/hardware system to operate normally
as if the debugger did not exist.
Checkpoints
• Checkpoint 1.9 What does it mean for a debugging
instrument to be minimally intrusive? Give both a
general answer and a specific criterion (see p. 529.)
• Checkpoint 1.10 Consider the difference between a
runtime flag that activates a debugging command versus
an assembly/compile-time flag. In both cases it is easy
to activate/deactivate the degugging statements. For
each method, list one factor for which that method is
superior to the other.
• Checkpoint 1.11: What is the advantage of leaving
debugging instruments in a final delivered product?
1.9 Tutorial 1. Getting Started
• Action—a specific task to be performed
individually.
• Questions—answers are at the end of the
text (see page 542).
• Tutorial 1 introduces the TExaS simulator.
– Peform the tutorial
– Install TExaS
– Read the Getting started section in the help
menu.
Valvano’s Links (p. vi)
• Videos:
http://users.ece.utexas.edu/~valvano/Read
me.htm
• Examples:
http://users.ece.utexas.edu/~valvano/Less
ons/