programming construction

在嵌入式的实际应用中，FLASH、16位RAM、32位RAM都存在于系统中，要在编程时将必要
的代码定位在特定的位置（比如32位的RAM速度最快，最适合放中断程序），这就要用到
ADS的“分散加载(Scatterloading)”技术。
下面是原文：
Locating code and data in memory (Scatterloading)
In most embedded systems, the code and data for an application will be
permamently stored in non-volatile memory (e.g. ROM or Flash) so that it is
available for execution at the moment of power-up. Normally though, parts of
this code and data (e.g. interrupt handlers, global variables) will need to be
copied from the non-volatile memory into volatile memory (RAM) in order for the
application to be able to execute correctly. In ADS this is done using the
linker's scatterloading mechanism.
Scatterloading allows you to partition an application into a number of separate
code and data regions spread throughout the address map. The location of these
regions can differ between load time and run time:
1) Load Regions contain application code and/or data used by the application at
power-on/load time (typically ROM).
2) Execution Regions are used by the application whilst it is executing.
The details of the memory map used by a scatterloaded application are contained
in a description file which is passed as a parameter to armlink. The benefit of
using a scatter description file is that all the (target-specific) absolute
addresses chosen for your devices, code and data are located in one file,
making maintenance easy. Furthermore, if you decide to change your memory map
(e.g. if peripherals are moved), you do not need to rebuild your entire
project - you only need to re-link the existing objects.
Within a scatter description file, a load region is represented by the outer
set of braces, and this can contain a number of execution regions (the inner
braces). Execution regions can be 'rooted' (executed at their load address), or
non-rooted (copied at run-time) regions. Consider the following typical
example:
LOAD_FLASH 0x04000000 0x80000 ; start address and length
{
EXE_FLASH 0x04000000 0x80000
{
init.o (Init, First) ; Put this area first in region
* ( RO) ; wildcard to collect all other RO
}
32bitRAM 0x0000 0x2000
{
vectors.o (Vect, First) ; Put this area first in region
int_handler.o ( RO)
}
16bitRAM 0x2000 0x80000
{
* ( RW, ZI) ; wildcard to collect RW & ZI
}
}
This defines one load region (LOAD_FLASH), and three execution regions
(EXEC_FLASH, 32bitRAM, 16bitRAM):
The exception vectors (in vectors.s) and exception handlers (in int_handler.c)
are relocated to 32bitRAM at address 0 (for speed)
The RW variables are copied from Flash to the 16bitRAM at address 0x2000
The ZI data will follow the RW data in the 16bitRAM
All other code (init, main program, libraries, etc) does not need to be
relocated, so just runs from the Flash.
Note that one key point to remember is that the ordering of objects in the
scatter file does not affect their ordering in the output image. Within each
region, the linker collects together input sections with the same attribute
(RO, RW or ZI). The basic placement rule for sections within a region is: RO
sections precede RW sections which precede ZI sections.
Within this ordering, sections will be ordered:
by attribute (e.g RO-Code before RO-Data), then
by name, then
by the order they were specified on the armlink command line.
A section may be placed first or last in an execution region using FIRST and
LAST, e.g. to place a checksum at the end of a region (as long as this does
not break the basic placement rules).
It should also be noted that if a system implements ROM/RAM remapping (i.e. ROM
is aliased to 0x0 at reset, but RAM is at 0x0 during normal execution), then
the descriptor file should describe the memory map after remapping has
occurred.
For more details of scatterloading please see:
ADS 1.0 - Tools Guide, Chapter 6, "The ARM linker" and Developer Guide, Chapter
7, "Writing Code for ROM"
ADS 1.1 - Compiler, Linker & Utilities Guide, Chapter 5, "The ARM linker" and
Developer Guide, Chapter 6, "Writing Code for ROM"