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 tasks1. 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. Analysis—requirements and constraints

2. Design—specifications and constraints

3. Implementation

4. 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. Test it now.2. Plan for testing.3. Get help.4. 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/Readme.htm

• Examples: http://users.ece.utexas.edu/~valvano/Lessons/