5.1. PIC16 C Application Design
• Program outline
• Debugging and testing
Formal design methods recommended for engineering projects may need to be applied in the professional design environment. Here, some basic methods are outlined as a starting point; these allow new applications to be developed with some degree of consistency and help communicate project concepts and design details clearly in reports and presentations.
Hardware Design
The block diagram is an effective way to show the general form of a microcontroller application design, and examples are seen throughout this book. Some simple rules are used to represent system blocks and their input and output signals:
• The direction of signal flow is represented by an arrowhead.
• The TTL level digital signal is the default (default arrow) style.
• Other switching levels (e.g., RS232 line) are indicated by labels.
• The analog voltage range is indicated by a label and arrow style.
• Parallel data are represented by a block arrow.
The block diagram (Figure 5.1) is easily constructed using only the drawing tools in a standard word processor. The example in Figure 5.1 might represent an analog-to-digital converter chip, with an “end of conversion” output.
Figure 5.1. Block Diagram Conventions
Once a block diagram has been created, defining the inputs and outputs of each block, a circuit schematic can be derived from it.
Software Design
The application program can be designed using various methods. A flowchart shows the overall program sequence in a visual manner and is good for illustrating simple program sequences. However, for C programs, some form of structured pseudocode is recommended, where the main program is outlined as a text file, which can then be converted directly to source code. Examples are again found throughout this book; the general content is described in Listing 5.1
Listing 5.1. General Control Program Outline
PROGNAME.C ///////////////////////////////////
Program header information
Author, date, version etc
Include MCU header file
Include function library files
Include user source files
Use function library files
Define constants
Declare global variables
Declare function prototypes
Main block //////////////////////////////////
Initialization sequence
Initialization function calls
etc
Main loop
Sequences
Function calls (level 1)
etc and repeat
Function block //////////////////////////////
Initialization sequence
Process sequences
Function calls (level 2)
etc and return
After the application program source code has been created in the MPLAB text editor, it can be compiled to generate the project file set. This includes the MCU machine code HEX file and the COF file, which incorporates the hex file with additional debugging information. It is necessary to have all the project files in the same folder, making copies of the resource files as necessary. All applications need an MCU header file, such as 16F877A.H.
The application source code, MCU header file and any other files to be included or used must be attached to the project in the project file window. The application can then be built and the HEX machine code file produced. This is downloaded to the target system to operate the application in hardware.
Application Debugging and Testing
The application program is tested and debugged in several stages. The main types of errors and the tools for detecting them are outlined next.
Syntax errors are mistakes in the source code, such as spelling and punctuation errors, incorrect labels, and so on, which cause an error message to be generated by the compiler. These appear in a separate error window, with the error type and line number indicated so that it can be corrected in the edit window.
When the program is successfully compiled, it can be tested for correct function in the target hardware so that any logical errors can be identified. However, it is preferable to test it in software simulation mode first, as it is quicker and easier to identify errors in the program sequence. Two simulation methods are available here, MPSIM and Proteus VSM.
MPSIM is the simulator provided with MPLAB. It allows the program source code to be run, stopped and stepped, and breakpoints set. The registers and source variables may be inspected at each step. When debugging C programs, breakpoints are the most useful, while stepping is more useful in assembly language. The program sequence and variable values are monitored and errors identified when the results obtained do not agree with those expected. Error information is provided principally in tabular form.
By comparison, the Proteus VSM debugging environment has significant advantages. The animated schematic gives a much more immediate indication of the overall program function. Interactive input and output devices operate in real or simulated time. The source code and breakpoints can be displayed.
In addition, if the VSM viewer is run from within MPLAB, the progress of the program can also be monitored simultaneously in MPSIM. Therefore, the more detailed debugging tools in MPSIM can be run alongside VSM and the most appropriate selected for any debugging task. The simulated hardware design is thus tested in conjunction with the MCU firmware (cosimulation), allowing circuit modifications at an early stage and hardware-software interaction to be studied on screen. When the program is eventually downloaded to the real hardware, it is now far more likely that it will work the first time.
The VSM Viewer is invoked from the debug tools menu in MPLAB, and the program is attached and tested. However, if circuit modifications are needed, VSM must be opened separately to run alongside MPLAB, so that the full set of ISIS schematic edit tools and component models are available. VSM still accesses the same COF file, so both software and hardware changes can be tested. More details on interactive debugging are given in Appendices A, B, and C.