Software Models and Planning

Appendices: P01

Using MPLAB® X Integrated Development Environment and chipKIT™Pro

Appendices: Software Models and Planning

Software models are an abstraction of the functionality of a computer program. The most common software abstractions are the data flow diagram (DFD), the control flow diagram (CFD)—more commonly called a flow chart, and the finite state machine diagram (FSM). An in-depth discussion of finite state machines is provided in Project 3.

Data flow diagrams convey how the problem is partitioned into single-purpose blocks of code or functions that complete a single action and the information that is exchanged between the partitions. A data flow diagram for the proposed design in this project is shown in Fig. 1. Each block represents a task, has a name describing the functionality, and the software function name in parenthesis. The heavy lines between blocks represent associations. The smaller vectored line represents data and the direction of flow. For example, the function “buttons” collects button status data and communicates that to the function “main.” A well designed and comprehensive DFD allows the software developer to construct a program shell without ever writing a line of operational code.

For example, from Fig. 1 we know the program will consist of five functions: main, syst_init, buttons, map, and leds. We also know that the function sys_init is called by function main, has no information passed to it, and no information returns from it. Hence, the prototype for the function sys_init is:

void sys_init(void);	// Initialize PIC32 for project 1 

Similarly, we see that the function map is also called from main. This function receives button status information and returns LED control information. The prototype for the map function is:

int map(int buttons);	// Determine which LED to turn on based on button status
Figure 1. Example data flow diagram.

Control flow diagrams convey the execution order of the control process, as illustrated in Fig. 2. Very effective control flow diagrams can be generated using four fundamental shapes. Boxes represent operations or processes, circles show where code execution paths join, diamonds show where execution paths diverge based upon a decision, and directed lines depict the control paths. A properly drawn control flow diagram constrains the program to be exclusively at one point on the graph at any given time. The control flow diagram describes the logic the controls the order in which the functions are executed. Figure 2 shows groupings of logic that correlate to the tasks depicted in the DFD.

Figure 2. Example control flow diagram.

After completing the DFD and CFD for a project or subset of a project, a basic outline of the code can now be generated. Starting with the code provided in Listing 1 in Project 1, we can begin to construct the outline structure of the program needed to complete Project 1. Normally, programs follow a standard order. First, provide comments that describe information concerning the purpose of the program, the author’s name, and date that the program was created. This is followed by a list of files that that need to be included so the compiler can resolve function declarations, references, and definitions that are not provided in the current file. Next, the function prototypes that instruct the compiler how to setup the interfaces between functions are contained in this file. This is followed by a listing of global definitions and global variable declarations, if any are required. Listing 1.1 is an example of the result of following this program's development process.

 /**************************************  Project1.c ************************************
 *
 *	This program controls the off/on status of the four LEDs on the chipKITPro MX7 based 
 *	on which combinations of buttons 1 and 2 are pressed.	
 *
 *	Author:		Richard Wall
 *	Date:		July 5, 2013
 *
 *****************************************************************************************/

#include <plib.h>
#include "config_bits.h"
#include "chipKIT_Pro_MX7.h"

void sys_init(void);     // Initialize PIC32 for project 1 
int buttons(void);       // Determine button status
int map(int buttons);    // Determine which LED to turn on based on button status
void leds(int led_ctrl); // Turn LEDs on or off 

int main(void)
{
   int button_status, led_ctrl;

   sys_init();

   /* Project initialization code goes here */

   while(1)
   {
      /* Project operational code goes here */
      button_status = buttons();
      led_ctrl = map(button_status);
      leds(led_ctrl);
   }
   return 1; /* This line of code will never be executed. */
}

void sys_init(void)  /* Initialize PIC32 for project 1 */
{
   Chip_KIT_Pro_Setup();  /* See the function Cerebot_mx7cK_setup() in
                           * CerebotMX7cK.c for details of configuration
                           * of the processor board */

   /* Add additional code to implement task initialization as needed */
}

int buttons(void)  /* Determine button status */
{
   /* Add code to implement task */
}

int map(int buttons)  /* Determine which LED to turn on based on button status */
{
   /* Add code to implement task */
}

void leds(int led_ctrl)  /* Turn LEDs on or off */
{
   /* Add code to implement task */
}
/* End of Project1.c */
 /************* Project 1 ***************
 *
 * File name: Project1.h
 * Author:    Richard W. Wall (C)opyright 2011
 * Date:      February 1, 2014
 *
 ****************************************/

#ifndef __PROJECT_1_H__
   #define __PROJECT_1_H__
#endif

/* Function prototypes */
void initialize_system();
int read_buttons(void);
int decode_buttons(int buttons);
void control_leds(int leds);

/* End of Projec1.h */

After completing the code as required for Listing 1.1, the project can be compiled and checked for syntax errors. At this point in time, the program will not generate any results because the execution details have not been added. Once the structure of the program has been defined, functionality details for each function is added and tested. Add code to one function at a time. Make sure that all compiler errors are resolved before you start working on the next function. Start with functions that generate data (inputs) and progress through to functions that use the data (outputs). If possible, make the development order follow the order described in your flow diagram.

More Resources for Code Organization

Although it is beyond the scope of this project to teach programming styles and techniques, using a consistent coding style is critical to good software development practices and results in fewer errors and less development time. Below are some suggested references to assist you in generating quality software.

  1. Code Organization
  2. Coding Standard
  3. Best coding practices

  • Other product and company names mentioned herein are trademarks or trade names of their respective companies. © 2014 Digilent Inc. All rights reserved.