1 / 31

Ch.5 Modular Programming

Ch.5 Modular Programming. From the text by Valvano: Introduction to Embedded Systems: Interfacing to the Freescale 9S12 Published by CENGAGE, 2010. Chapter 5 Objectives. Present an introduction to modular programming Use conditional branching to perform decisions

ataret
Download Presentation

Ch.5 Modular Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ch.5 Modular Programming From the text by Valvano: Introduction to Embedded Systems: Interfacing to the Freescale 9S12 Published by CENGAGE, 2010

  2. Chapter 5 Objectives • Present an introduction to modular programming • Use conditional branching to perform decisions • Implement for-loops, macros and recursion • Implement modular programming using subroutines • Present functional debugging as a method to test software

  3. 5.1 Modular Design • Successive refinement was introduced in Section 1.6 of the text. • Reasons for Modular Design • Functional Abstraction allows resuse of software modules. • Complexity Abstraction allows the division of a complex system into less complicated components. • Portability—hardware details can be isolated—sometimes called Hardware Abstraction. • Security—the hiding of details and restriction of access makes the system more secure.

  4. 5.1.1 Definitions and Goals • Program Module —a self-contained task with clear entry and exit points. • Entry Point —In C this is the header file; in assembly it is the list of public subroutines that can be called. • Exit Point —ending point of a software module. • In most embedded systems the main program does not exit. • An object could be a subroutine or data element; a public object is one that is shared by multiple modules; a private object is not shared. • I/O devices should be private—i.e. used by only one module.

  5. 5.1.2 Functions, Procedures, methods, and Subroutines • A subroutine is the assembly language version of a function, and may or may not have input or output parameters. • A subroutine begins with a label (the name). • A subroutine ends with the rts instruction. • A bsr or jsr instruction is used to call a subroutine if there are input parameters. • Registers can be used to implement “call by value.” (see Figure 5.1 on page 155.)

  6. 5.1.3 Dividing a Software Task into Modules • Coupling—the influence one module’s behavior has on another module. • Coupling is to be minimized enhance clarity and to make modules more independent. • Quantitative measurement of coupling—the number of bytes per second (bandwidth) that are transferred from one module to another. • It is poor design to pass data through public global variables—a FIFO queue is better.

  7. 5.1.3 (cont.) • Each module should be assigned a logically complete task. • A module is logically complete when it can be separated from one system and placed into a second system.

  8. Checkpoint • Checkpoint 5.2 List some examples of coupling. • Parameters passed • Shared globals • Functions called • Shared I/O devices

  9. Example—Breaking a Software System into Modules • Figure 5.2 of Volvano (page 157). • System goal • Sample ADC • Perform calculations on the data • Output results • From the figure– set of tasks at the beginning, followed by a long list of tasks. • Linear approach is shown on the left. • Modular approach (main program—3 modules)

  10. Modular Approach Example • Subroutines • ADC_Init, ADC_In (module 1) • SCI_Init, SCI)_Out (module 2) • Module 3 • Math_Calc (has private subroutines, Sort and Average) • Sort (called twice by Math_Calc) • Average • Easier to understand and debug.

  11. Possible Changes/Debugging/Reuse • SCI subroutine could be replaced directly with LCD subroutine (LCD_Init, LCD_Out). • Debugging • Each subroutine can be debugged. • Then each module can be debugged. • Then debug the entire system. • Reuse • Example, the ADC module could be used in another system.

  12. Call Graph and Data Flow Graph for the Example System • Figure 5.3,Call Graph, Valvano’s text, page 159. • Figure 5.4, Data Flow Graph

  13. 5.2 Making Decisions • 5.2.1 Conditional Branch Instructions • Chapter 3 introduced the following: bcc, bcs, beq, bne, bmi, bpl, bra, brn, bvc, bvs, and jmp. • Unsigned branches that follow a subtract, compare, or test instruction: • blo—branch if unsigned less than • bls—branch if unsigned less than or equal to • bhs—branch if unsigned greater than or equal to • bhi—branch if unsigned greater than

  14. More Conditional Branches • Signed branch instructions follow a subtract, compare or test. • Signed branch instructions: • bit—branch if signed less than • bge—branch if signed greater than or equal to • bgt—branch if signed greater than • ble—branch if signed greater than or equal to

  15. 5.2.2 Conditional if-then Statements • Performing Comparisons • Read first value into a register. • Compare the first value with the second. • Subtract (suba, subb subd) • Compare (cmpa, cmpb, cpd, cpx, cpy) • Conditional Branch (CCR is set after above operations.) • Program 5.1, page 163 of Valvano (G1, G2 are the two variables)

  16. 5.2.3 Conditional if-then-else Statements • Unconditional Branch • Can be used to provide “else” • See Figure 5.7, page 166. • See Program 5.6, page 166.

  17. 5.2.4 While Loops • While and Do-While Structure • Microcomputer is waiting for some event. • Program 5.7 (page 167) • Figure 5.8 (page 166).

  18. 5.2.5 For Loops • Special case of Do-While. • Convenient way to perform repetitive operations. • Figure 5.9 illustrates two ways: counting up and counting down. • Freescale has convenient set of instructions: dbeq, dbne, ibeq, ibne, tbeq, tbne. • See bottom of page 167 • (3-byte instructions) • Example: dbeq r, target; decrement register r, and branch to target if r is equal to zero.

  19. 5.3 Macros • Definition—a template for a sequence of instructions. • Name • Code Sequence • A macro is invoked using its name—then the code sequence is placed in the assembly language program by the assembler—a “copy and paste” –like proceedure.

  20. Three Parts of a Macro • The header—MACRO directive and label. • The code sequence, including arguments as needed. • The ENDM directive, terminating the macro.

  21. Macro Example • See text, page 168 and 169. • negd: MACRO coma comb addd #1 ENDM

  22. Recursion • Recursive Program—one that calls itself. • The stack can be used to separate the parameters, variables, and register values for each instantiation.

  23. 5.3 Writing Quality Software • 5.5.1 Assembly Language Style • Names should have Meaning • Avoid Ambiguities—do not use variable names that are vague or have more than one meaning. • Give hints about the type • DataPt (pointer) • timeBuf(data buffer)

  24. 5.5.1 Assembly Language Style (cont.) • 4. Use the same name to refer to the same type of object (i,j,k as indices, V1 and R1 could refer to voltage and resistance). • 5. Use a prefix for public objects (MIN_PRESSURE) • 6. Use upper and lower case to specify the scope of an object. • 7. Use capitalization to delimit words • Table 5.3 gives other examples.

  25. 5.5.1 Assembly Language Style (cont.) • 8. The single entry point is at the top of a subroutine—comments could be used. • 9. A single exit point is at the bottom. • 10. Write structured programs—use if, if-else, do-while, while, for, and switch structures. • 11. Register values should be saved.

  26. 5.5.1 Assembly Language Style (cont.) • 12. Use high-level languages whenever possible. • 13. Minimize conditional branching.

  27. 5.5.2 Comments • Valvano says that comments are the least important aspect involved in writing quality software. • The assumption is that it is better to write well-organized software with simple interfaces (see bottom of page 177). • Examples are shown on page 177-188.

  28. 5.5.3 Inappropriate I/O and Portability • “Portability is diminished when it is littered with user input/output.”—page 179

  29. 5.6 How Assemblers Work • Usually two passes are required. • First—a mapping between symbolic names and their numeric values is made—a Symbol Table. • Second—the object file is created. • Definitions to remember: • Source code —a file of characters usually created with an editor—assembler processes the label, opcode, and operands field. • Object code is the binary values produced. • Listing —address, object code, and source code.

  30. Checkpoints • Checkpoint 5.20: What does the assembler do in pass 1? • Checkpoint 5.21: What does the assembler do in pass 2?

  31. 5.7 Functional Debugging • Stabilize the system—create a test routine that fixes (stabilizes) all the inputs. • Single Stepping • Breakpoints—software will execute up to this point and then stop for logging information. Scanpoints record data when executed, but do not stop the execution. • Conditional Breakpoints • Instrumentation: Print Statements (problems discussed—page 181.

More Related