c513.txt

dsp&c51的编程,从小百合上down的

ed emulators like the Hitex T51 can read their values on the fly. This appro 
ach is generally best for large, time-critical applications, as the SMALL gl 
obal model guarantees that local variables and function parameters will have 
 the fastest access, while large arrays can be located off-chip. 
COMPACT: Total RAM 256 bytes off-chip, 128 or 256 bytes on-chip. 
Suitable for programs where, for example, the on-chip memory is applied to a 
n operating system. The compact model is rarely used on its own but more usu 
ally in combination with the SMALL switch reserved for interrupt routines. 
COMPACT is especially useful for programs with a large number of medium spee 
d 8 bit variables, for which the MOVX A,@R0 is very suitable. 
It can be useful in applications where stack usage is very high, meaning tha 
t data needs to be off-chip. Note that register variables are still used, so 
 the loss of speed will not be significant in situations where only a small 
number of local variables and/or passed parameters are used. 
LARGE: Total RAM up to 64KB, 128 or 256 bytes on-chip. 
Permits slow access to a very large memory space and is perhaps the easiest 
model to use. Again, not often used on its own but in combination with SMALL 
. As with COMPACT, register variables are still used and so efficiency remai 
ns reasonable. 
In summary, there are five memory spaces available for data storage, each of 
 which has particular pros and cons. 
Here are some recommendations for the best use of each: 
DATA: 128 bytes; SMALL model default location 
Best For: 
Frequently accessed data requiring the fastest access. Interrupt routines wh 
ose run time is critical should use DATA, usually by declaring the function 
as "SMALL". Also, background code that is frequently run and has many parame 
ters to pass. If you are using re-entrant functions, the re-entrant stacks s 
hould be located here as a priority. 
Worst For: 
Any variable arrays and structures of more than a few bytes. 
IDATA; Not model-dependant 
Best For: 
Fast access data arrays and structures of limited size (up to around 32 byte 
s each) but not totalling more than 64 or so bytes. As these data types requ 
ire indirect addressing, they are ideally placed in the indirectly addressab 
le area. It is also a good place to locate the stack, as this is by definiti 
on indirectly addressed. 
Worst For: 
Large data arrays, fast access words. 
CODE: 64K bytes 
Best For: 
Constants and large lookup tables, plus opcodes, of course! 
Worst For: 
Variables! 
PDATA: 256bytes; COMPACT model default area 
Best For: 
Medium speed interrupt and fast background char (8 bit) variables and modera 
te-sized arrays and structures. Also good for variables which need to be vie 
wed in real time using an emulator. 
Worst For: 
Very large data arrays and structure above 256 bytes. 
Very frequently used data (in interrupts etc..). 
Integer and long data. 
XDATA; LARGE model default area 
Best For: 
Large variable arrays and structures (over 256 bytes) 
Slow or infrequently-used background variables. Also good for variables whic 
h need to be viewed in real time using an emulator. 
Worst For: 
Frequently-accessed or fast interrupt variables. 
2.1.4 Setting The Memory Model - #Pragma Usage 
The overall memory type is selected by including the line #pragma SMALL as t 
he first line in the C source file. 
See Section 2.1.3 for details on specific variable placement. SMALL is the d 
efault model and can be used for quite large programs, provided that full us 
e is made of PDATA and XDATA memory spaces for less time-critical data. 
Special note on COMPACT model usage 
The COMPACT model makes certain assumptions about the state of Port 2. The X 
DATA space is addressed by the DPTR instructions which place the 16 bit addr 
ess on Ports 0 and 2. The COMPACT model uses R0 as a 8 bit pointer which pla 
ces an address on port 0. Port 2 is under user control and is effectively a 
memory page control. The compiler has no information about Port 2 and unless 
 the user has explicitly set it to a value it will be undefined, although ge 
nerally it will be at 0xff. The linker has the job of combining XDATA and PD 
ATA variables and unless told otherwise it puts the PDATA (COMPACT default s 
pace) at zero. Hence, the resulting COMPACT program will not work. 
It is therefore essential to set the PPAGE number in the startup.a51 file to 
 some definite value - zero is a good choice. The PPAGEENABLE must be set to 
 1 to enable paged mode. Also, when linking, the PDATA(ADDR) control must be 
 used to tell L51 where the PDATA area is, thus: 
L51 module1.obj, module2.obj to exec.abs PDATA(0)XDATA(100H) 
Note that the normal XDATA area now starts at 0x100, above the zero page use 
d for PDATA. Failure to do this properly can result in very dangerous result 
s, as data placement is at the whim of PORT2! 
2.2 Local Memory Model Specification 
2.2.1 Overview 
C51 version 3.20 allows memory models to be assigned to individual functions 
. Within a single module, functions can be declared as SMALL, COMPACT or LAR 
GE thus 
#pragma COMPACT 
/* A SMALL Model Function */ 
fsmall() small { 
   printf("HELLO") ; 
   } 
/* A LARGE Model Function */ 
flarge() large { 
   printf("HELLO") ; 
   } 
/* Caller */ 
main() { 
   fsmall() ;  // Call small func. 
   flarge() ;  // Call large func. 
   } 
See pages 5-20 in the C51 reference manual for further details. 
2.2.2 A Point To Watch In Multi-Model Programs 
A typical C51 program might be arranged with all background loop functions c 
ompiled as COMPACT, whilst all (fast) interrupt functions treated as SMALL. 
The obvious approach of using the #pragma MODEL or command line option to se 

t the model can cause odd side effects. The problem usually manifests itself 
 at link time as a MULTIPLE PUBLIC DEFINITION error related to, for instance 
, putchar(). 
The cause is that in modules compiled as COMPACT, C51 creates references to 
library functions in the COMPACT library, whilst the SMALL modules will acce 
ss the the SMALL library. When linking, L51 finds that it has two putchars() 
 etc. from two different libraries. 
The solution is to stick to one global memory model and then use the SMALL f 
unction attribute, covered in the previous section, to set the memory model 
locally. 
Example: 
    #pragma COMPACT 
    void fast_func(void) SMALL{ 
    /*code*/ 
    } 
---------------------------------------------------------------------------- 
---- 
  
-- 
Ours is essentially a tragic age, so we refuse to take it tragically.