User`s manual

Rabbit 4000 Designer’s Handbook rabbit.com 45
#orgdef xcodorg xmemcode in flash above start to user_block
Defining origins for the physical memory devices in a particular configuration is not enough for the com-
piler, so we need to define regions for code and data. The line above defines an origin for xmem code with
“xcodorg” origin type, and called “xmemcode”. The compiler knows to use this origin for xmem code
because of the origin type. Note that xmemcode is a child of the origin “flash”, so it not only has the prop-
erty of being a code region, but it is also non-volatile since it inherits that property from its parent “flash”.
The final bit of syntax, “above start to user_block” means that the origin region starts at the beginning of
its parent and extends to the beginning of the sibling “user_block” origin region. The “to” syntax allows
the origin definition to remain unchanged even if the parent origin changes. A “to” terminal in an origin
definition can also be followed by the syntax “end” to indicate that the region should occupy the entire
parent origin region (this is useful for organizational purposes).
#orgdef rcodorg rootcode in xmemcode above start log 0 size
ROOTCODE_SIZE
The xmem code origin is defined above to take up the entire flash device other than the small space
reserved for the user block. The reason for this is that we want to be able to put xmem code anywhere in
the flash device. However, we also need root code for the segmented addressing the Rabbit provides. The
line above defines the “rootcode” origin to be a child of the “xmemcode” region. This is legal because
root code addresses can also be used for xmem code (all root addresses have a corresponding physical
address). The origin starts at the beginning of “xmemcode”, but notice the addition of “log 0”, for “logi-
cal 0”.
The origin type for “rootcode” is rcodorg, a logical origin. This means that “rootcode” can be accessed
through logical addresses, so the compiler needs to know where it is situated in logical memory, i.e., the
origin needs a starting logical address. In this case, it starts at logical address “0”.
#orgdef rvarorg rootdata in ram above start log ROOTCODE_SIZE size
ROOTDATA_SIZE
The origin named “rootdata” is a child of “ram” and as such inherits the property of being battery-
backed. The origin starts at the beginning of “ram”, and has size ROOTDATA_SIZE. It is a logical origin;
its starting logical address is ROOTCODE_SIZE, a macro defined in the BIOS.
#orgdef wcodorg watcode in rootdata below end size WATCHCODESIZE
The origin named “watcode” is a child of “rootdata” and as such is also of logical origin type. Its starting
logical address is not explicitly stated, but can be determined from the parent origin’s logical extents. Fol-
lowing the inheritance, “below end” indicates that the origin should be at the end of its parent “rootdata”,
with size WATCHCODESIZE. This information is used to determine the starting logical address: We know
that the starting logical address of the parent “rootdata” is ROOTCODE_SIZE. The logical addresses for
child origins necessarily must be relative to their parents. In this case, that means that the starting logical
address for “watcode” is then, ROOTCODE_SIZE + ROOTDATA_SIZE - WATCHCODESIZE.
#orgdef xvarorg
xmemdata in ram above rootdata to userdata_buff
The origin named “xmemdata” is a child of “ram” and as such inherits the property of being battery-
backed. The origin starts where its sibling origin “rootdata” ends; therefore, it starts at
ORG_RAM_START+ROOTDATA_SIZE. “xmemdata” extends to the beginning of “userdata_buff”. (The
declaration for the origin named “userdata_buff” is in memory_layout.lib along with the declarations for