Файл: Introduction to Microcontrollers. Architecture, Programming, and Interfacing of the Motorola 68HC12 (G.J. Lipovski, 1999).pdf

Figure 63. Changing a Global Variable before It Has Been Completely Used

illustrates a program segment using TEMP to store a variable to be recalled later. Before that value is recalled, however, TEMP has been changed by subroutine B, which is called by subroutine A, which itself is called by the program segment. This case is difficult to debug because each subroutine will work correctly when tested individually but will not work when one is called, either directly or indirectly through other subroutines, from within the other. This technique also confuses documentation, specifically the meaning of the local variable TEMP, generally making the program less clear.

With the other technique, the local variables will be put in different memory locations, having different symbolic names. See Figure 6.5. This approach is superior to the last approach, because differently named local variables, stored in different locations, will not interfere with the data stored in other locations. The names can be chosen to denote their meaning, reducing the need for comments. However, memory is taken up by these local variables of various program segments, even though they are hardly ever used. In a single-chip 'A4 or 'B32, only IK bytes of SRAM are available. Using all these bytes for rarely used local variables leaves less room for the program's truly global data.

Figure 6.4. Inner Product Utilizinga Global Variable such as TEMP (a Bad Example)

Figure 6.11. Defining Symbolic Names for Stacked Local Variables by Sizes

Another technique, shown in Figure 6.12, uses the DS directive to play a trick on the assembler. The technique uses the DS directive to bind the stacked local variables partially with the stack pointer SP, using the location counter and the ORG directive to modify the location counter. Recall that ALPHA DS 2 will normally allocate two bytes for the variable ALPHA. The location counter is used to bind addresses to labels like ALPHA as the assembler generates machine code. The location counter and hence the address bound to the label ALPHA correspond to the memory location where the word associated with the label ALPHA is to be put. A DS statement, with a label, binds the current value of the location counter to the label (as the name of the container, not the contents) and adds the number in the DS statement to the location counter. This will bind a higher address to the next label, allocating the desired number of words to the label of the current directive. Note that ALPHA EQU * will bind the current location counter to the label ALPHA but not affect the location counter. Also, recall that the ORG directive can set the location counter to any value. These can be used as shown in Figure 6.12.

You can reset the location counter to zero many times, and you should do this before each group of DS directives that are used to define local storage for each program segment. These DS statements should appear first in your program segment. Each set should be preceded by a directive such as LCSAVE DS 0 to save the location counter using LCSAVE and an ORG 0 directive to set the location counter to 0; and each set

Figure 6.12. Declaring Symbolic Names for Local Variables Using DS Directives

Before we begin, however, we reiterate that these techniques are quite similar to those used in Section 6.1 to store local variables. However, these techniques are used between subroutines,while the latter were used entirely within asubroutine.

c. Another calling sequence

Figure 6.15. A Subroutinewith Parameters in Registers

In this section we examine six methods used to pass parameters to a subroutine. We illustrate each method with the dot product from Section 6.1. We first consider the simplest method, which is to pass parameters in registers as we did in our earlier examples. Then the passing of parameters by global variables is discussed and discouraged. We then consider passing parameters on the stack and after the call, which are the most common methods used by high-level languages. We then discuss the technique of passing parameters using a table, which is widely used in operating system subroutines.

Figure 6.16. Change a Global Parameter before Its Subroutine Has Used It

*SUBROUTINE DOTPD - LOCAL VARIABLES

Figure 6.17. A Subroutine with Parameters in Global Variables

In assembly language, global variables are defined through a DS directive that is usually written at the beginning of the program. These variables are often stored on page zero on smaller microcontrollers so that direct page addressing may be used to access them. However in the 6812, page zero is used for I/O ports. Assuming that the directives are written somewhere in the program, the subroutine in Figure 6.17 does the previous calculation, passing the parameters through these locations. Note that we use local variables in this subroutine, as discussed in Section 6.1.

The subroutine in Figure 6.17 uses global variables VI, V2, Wl, W2, and DTPD to pass parameters to the subroutine and from it. If the calling routine wants to compute the dot product of its local variables LV and LW, which each store a pair of 2-element 1-byte vectors, putting the result in LDP, the calling sequence in Figure 6.18 could be used. Notice that the calling routine's local variables are copied into global variables VI, V2, Wl, and W2 before execution and copied out of the global variable DTPD after execution. Any other calling sequence for this version of DOTPRD must also copy the vectors of