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/