Modularization programming of single-chip microcomputer in Keil

url:http://jyqcxl122621.blog.163.com/blog/static/61323392201172392519647/

Through the previous chapter of learning, I think you have mastered how to release the CPU in the program. I hope we can keep on going. A good start is half the success. All we do today is to do better in microcontroller programming.

Before talking about today's topic, let me tell you about some of my previous experiences. In the beginning of contact with the C language program, due to the limitations of the learning content, writing procedures are not very large, generally also hundreds of lines. So all the programs are done in a source file. Remember at that time freshman to participate in the school of an electronic design competition, debugging for one weeks, all the program add up about nearly 1000 lines, a long file, from the long time to browse down. Out of the wrong simple syntax error good positioning, other errors, often looking for a long day to find. At that time began to know the modular programming of this thing, but also try to start the program sub-module writing. At first, some functions of the same function (such as the 1602 LCD driver) are all written in a header file (. h) file, which is then required to be included in the call, but it is soon discovered that this method has its limitations and it is easy to make repeated errors.

And it's inconvenient to call it up. Soon summer's electronic design competition came, the school of our microcontroller software programming a number of training. As the school over the years to participate in national and provincial races, so accumulated a certain number of drive modules, those days, teachers will be assigned a quantitative task every day, let us use these modules together to complete a certain function. And it is those days of modular programming training, so I have a further understanding of modular programming. And the Code of procedure began to pay attention slowly. The following days, regardless of the size of the program, are programmed in a modular way to write. For a long time, has been a single-chip enthusiasts on the QQ and I communicate with. Sometimes, they will send over some problematic program source files, let me help to modify. The same is a long file, and the name is very irregular, from the beginning to look down, it is really painful, to tell the truth, it is not as good as I have to write a faster, this word to not fake, because at hand accumulated a certain amount of modules, in the completion of a new system, only need to according to the upper functional requirements, in the Can be done quickly and conveniently. Without the need to re-write brick by brick from beginning to end. Thus, one of the benefits of modular programming is the high level of repeatable utilization. Let's take a peek at the true face of the modular mystery.

C Language source file *.c

Mention of C language source files, everyone will not be unfamiliar. Because the program code that we normally write is almost in this xx.c file. The compiler also compiles it with this file and generates the corresponding target file. As the basis of modular programming, the source code of all the functions we want to implement is in this file. The ideal modularity should be seen as a black box. That is, we only care about the functionality provided by the module, regardless of the implementation details inside the module. Like we bought a cell phone, we just need to use the function provided by the mobile phone, do not need to know how it sent the text message, how to respond to the input of our keys, these processes for our users, is a black box.

In large-scale program development, a program consists of a number of modules, it is possible that the programming tasks of these modules are assigned to different people. While you are writing this module is likely to need to take advantage of other people to write a good block of excuses, this time we are concerned about the module implementation of what kind of interface, I how to call, as to how the module inside is organized, for me, there is no need to pay much attention. And the pursuit of the uniqueness of the interface, the unnecessary details as far as possible to the external shielding, is exactly what we need to pay attention to the place.

C Language Header file *.h

When it comes to modular programming, it will inevitably involve multi-file compilation, or engineering compilation. In such a system, there are often multiple C files, and each C file does not have the same effect. In our C file, because of the need to provide interfaces externally, some functions or variables must be provided to other external files for invocation.

Suppose we have a LCD.C file that provides the most basic LCD driver function

Lcdputchar (char cnewvalue); Outputs one character at the current position

And in one of our other files we need to call this function, so how do we do it.

This is where the header file works. It can be called an interface description file. The inside of the file should not contain any substantive function code. We can interpret this header file as a description of the interface function or interface variable that our module provides externally. The file also contains some important macro definitions and some structure information, leaving this information, it is likely that the interface function or interface variables will not be used properly. But the general principle is: should not let the outside world know the information should not appear in the header file, and the outside Call Module interface function or interface variables must be in the information necessary to appear in the header file, otherwise, the outside world will not be able to correctly invoke the interface function we provide. Thus, in order for an external function or file to invoke the interface functionality we provide, we must include the interface description file that we provide----the header file. At the same time, our own module also needs to include this module header file (because it contains the module source files required in the macro definition or structure), as we usually use the file is three copies of the same, the module itself needs to include this header file.

Here we define this header file, in general, the name of the header file should be consistent with the name of the source file, so that we can clearly know which file is which source file description.

So I got the LCD.C's head file LCD.h its contents as follows.

#ifndef _lcd_h_

#define _lcd_h_

extern Lcdputchar (char cnewvalue);

#endif

This is a bit like when we define a function in the source file. The difference is that the extern modifier is added before it to indicate that it is an external function that can be called by other external modules.

#ifndef _lcd_h_

#define _lcd_h_

#endif

This few conditional compilations and macros are defined to prevent duplicates from being included. If there are two different source files that need to call the Lcdputchar (char cnewvalue) function, they are included in the header file by the # include "Lcd.h" respectively. When the first source file is compiled, because _lcd_h_ is not defined #ifndef the _lcd_h_ condition is established, the _lcd_h_ is defined and the following declaration is included. At the time of compilation of the second file, _lcd_h_ has already been defined because the first file contains the time. Therefore #ifndef _lcd_h_ is not established, the entire header file content is not included. Assuming there are no such conditional compilation statements, two files contain the extern lcdputchar (char cnewvalue); Will cause a duplicate included error.

Have to say the typedef

A lot of friends seem to be accustomed to using the following statements to define data types

#define UINT unsigned int

#define UCHAR unsigned char

Then use this directly when defining variables.

UINT G_ntimecounter = 0;

Admittedly, this is really convenient, and for the transplant is also a certain convenience. But consider the following situation you would still think so.

#define PINT Unsigned int *//define unsigned int pointer type

PINT G_nptimecounter, G_nptimestate;

So are you defining a pointer variable of two unsigned int, or a pointer variable, an shaping variable? And what are your intentions, to define two pointer variables of type unsigned int? If that's the case, then it's probably going to be a little crazy to find a mistake soon.

Fortunately, the C language has taken this into account for us. The typedef was born for this purpose. In order to give the variable an alias, we can use the following statement

typedef unsigned int uint16; An alias that points to an unsigned shaping variable uint16

typedef unsigned int * PUINT16; Give an alias to an unsigned shaping variable pointer puint16

This can be defined when we define a variable:

UInt16 g_ntimecounter = 0; Defining an unsigned shaping variable

Puint16 G_nptimecounter; Defines a pointer to an unsigned shaping variable

When we use the 51 Microcontroller C language programming, the shape variable range is 16 bits, and in 32-based micro-processing under the shaping variable is 32 bits. If some of the code we write under a 8-bit microcontroller wants to be ported to a 32-bit processor, then it is likely that we need to modify the variable's type definition everywhere in the source file. This is a huge work, in order to consider the portability of the program, in the beginning, we should form a good habit, with the alias of the variable to define.

As in the 8-bit microcontroller platform, like the next variable definition

UInt16 g_ntimecounter = 0;

If you are porting a 32 microcontroller platform, the range you want is still 16-bit.

The definition of uint16 can be modified directly, i.e.

typedef unsigned short int uint16;

This is possible, without the need to find and modify the source files everywhere.

All of the commonly used data types are defined by this method, forming a header file, which is convenient for us to program and invoke directly later.

File name MacroAndConst.h

The contents are as follows:

#ifndef _macro_and_const_h_

#define _macro_and_const_h_

typedef unsigned int uint16;

typedef unsigned int UINT;

typedef unsigned int uint;

typedef unsigned int UINT16;

typedef unsigned int WORD;

typedef unsigned int word;

typedef int INT16;

typedef int INT16;

typedef unsigned long UInt32;

typedef unsigned long UINT32;

typedef unsigned long DWORD;

typedef unsigned long DWORD;

typedef long Int32;

typedef long INT32;

typedef signed CHAR int8;

typedef signed Char INT8;

typedef unsigned char byte;

typedef unsigned char BYTE;

typedef unsigned char Uchar;

typedef unsigned char UINT8;

typedef unsigned char uint8;

typedef unsigned char BOOL;

#endif

At this point, it seems that we have a little idea of the division of the source and header files and the modular programming. So let's take the strike, divide the LED flicker function we wrote in the previous chapter and reorganize it to compile.

Our main function in the previous chapter is that the LEDs driven by the P0 port blink at a frequency of 1Hz. The timer is used, as well as the LED driver module. As a result, we can easily divide the entire project into three modules, timer modules, LED modules, and main functions

The corresponding file relationships are as follows

Main.c

TIMER.C--? Timer.h

LED.C--? Led.h

Before we start rewriting our program, let's talk about how to create a project template in Keil, which I've been working on for so far. I hope we can give you a little inspiration.

The following content is mainly based on the picture. At the same time, supplemented by a small number of text description.

We take Chip at89s52 as an example.