Transcript 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
Implement for-loops, macros and recursion
Implement modular programming using
subroutines
• Present functional debugging as a method to
test software
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.
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.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.)
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.
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.
Checkpoint
• Checkpoint 5.2 List some examples of
coupling.
– Parameters passed
– Shared globals
– Functions called
– Shared I/O devices
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)
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.
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.
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
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
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
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)
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.
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).
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.
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.
Three Parts of a Macro
• The header—MACRO directive and label.
• The code sequence, including arguments
as needed.
• The ENDM directive, terminating the
macro.
Macro Example
• See text, page 168 and 169.
• negd: MACRO
coma
comb
addd #1
ENDM
Recursion
• Recursive Program—one that calls itself.
• The stack can be used to separate the
parameters, variables, and register values
for each instantiation.
5.3 Writing Quality Software
•
5.5.1 Assembly Language Style
1. Names should have Meaning
2. Avoid Ambiguities—do not use variable
names that are vague or have more than
one meaning.
3. Give hints about the type
•
•
DataPt (pointer)
timeBuf(data buffer)
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.
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, ifelse, do-while, while, for, and switch
structures.
• 11. Register values should be saved.
5.5.1 Assembly Language Style
(cont.)
• 12. Use high-level languages whenever
possible.
• 13. Minimize conditional branching.
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.
5.5.3 Inappropriate I/O and
Portability
• “Portability is diminished when it is littered
with user input/output.”—page 179
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.
Checkpoints
• Checkpoint 5.20: What does the
assembler do in pass 1?
• Checkpoint 5.21: What does the
assembler do in pass 2?
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.