Ch. 1 Intro to Embedded Microcomputer Systems

1. Ch. 1 Intro to Embedded Microcomputer Systems From the text by Valvano Intro to Embedded Systems : Interfacing to the Freescale9S12

2. 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.

3. 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.

4. 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?

5. 1.2 Applications • An embedded computer system (p.9 of text) • Microcomputer • Mechanical, Chemical, and Electrical Devices • Programming is for a specific purpose.

6. 1.3 Flowcharts and Structured Programming • Flowcharts • Data Flow graphs • Call graphs

7. Flow Charts • Fig. 1.6 shows the basic building blocks of structured programming. • Sequence—rectangles are processing blocks. • Conditional • While-loop

8. 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)

9. 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.

10. 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.

11. 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)

12. 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.

13. Interrupt Service Routine (ISR) • Foreground threads are considered the main program. • Background threads are the ISR’s.

14. Example 1.3 (p.11 of text) • Two tasks • Output apulse on PTT every 1.024 ms in real time. • Find all the prime numbers (no time constraint).

15. 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.)

16. 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.

17. Example of Parallel Programming • Figure 1.11 (page 12 of text) illustrate the finding of the maximum value in a bufffer.

18. 1.5 Product Development Cycle • Figure 1.12 (page 13) illustrates the product development cycle. • Analysis—requirements and constraints • Design—specifications and constraints • Implementation • Testing

19. 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.

20. Checkpoint • Checkpoint 1.7 what’s the difference between a requirement and a specification?

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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).

27. 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.

28. 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.

29. 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.

30. 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

31. 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?

32. 1.7.3 Attitude • “Writing quality software has a lot to do with attitude.” (page 20 of text) • Ways to improve the software: • 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.

33. 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.

34. 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?

35. 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.

36. Valvano’s Links (p. vi) • Videos: http://users.ece.utexas.edu/~valvano/Readme.htm • Examples: http://users.ece.utexas.edu/~valvano/Lessons/