Hardware Reference
In-Depth Information
Function names should follow the same principle. A few examples of function names are
sevenSegShift(), putcSPI(), putsSPI(), openLCD(), and putsLCD()
Named constants should be all uppercase using underscores to separate words. A few
examples of constant names are
SONG_TOTAL_NOTES, HI_DELAY_COUNT, LO_DELAY_COUNT
As in assembly language, C program errors can be divided into two categories:
•
Syntax/semantics errors
•
Logical errors
Many syntax/semantics errors can be discovered if the programmer follows the rules of C
language.
•
Undeclared variables.
A variable must be declared before it can be used. Most
errors of this type can be discovered easily.
•
Variable and symbol names are case sensitive.
Sometimes, the programmer has
declared a variable but still has an undeclared variable error with the same variable.
This error could occur because one or more characters of the variable name are in
the wrong case. For example, in the program segment
int
A1, A2, xyClk;
. . .
A1
5
A1 * xycLk;
the compiler would output the error message “undefined variable xycLk.”
•
Missing parenthesis (or brace or bracket).
A missing parenthesis can cause many
other errors. This type of error can be avoided by entering the matching parenthesis
whenever the left parenthesis is entered before entering statements between the
parentheses.
•
Mismatch of function name in function prototype declaration and function
definition.
The EGNU will generate the error message “unknown error—see
Make Log.” When the user clicks on
Make log
on the status pane of EGNU,
the message “undefined reference to . . .” will appear. ICC12 and CodeWarrior
C compilers would output the error message “reference functions without
prototype.”
Logical errors are harder to debug than syntax and semantic errors. Whenever the program
behavior is not what we expect, the first step is to read the program carefully to find out where
the most likely problem spot is. After identifying the potential problem spot, we can set a break-
point and examine the program execution result.
If the user has a source-level debugger (CodeWarrior) to debug the program, the following
actions can be taken to solve the problem:
•
Set breakpoints.
Breakpoints allow the user to examine program execution results
at the suspicious point.
•
Set up a watch list (in Data:1 and Data:2 windows in CodeWarrior IDE).
A watch
list is used together with the breakpoints. A watch list consists of pairs of program
Search WWH ::
Custom Search