Memory Section Management

Your toolchain will most probably put code in ROM as well as string literals, but you might want to finetune the location where specific code and data to meet your physical resources.

If you do not specify anthing in C sources, a default allocation scheme will be used by your locator. However, most toolchains allow you to use compiler pragmas which define the start and end of a certain section. The locator can be instructed to allocate these sections at a specific address: in combination with the memory layout of your hardware you are able to locate specific code and data exact where you want it.

The source code of the OO RTX is for most parts common for any RXF we release; apart from the Bridges the very same code is processed by many different compilers and excucuted in a wide variety of CPUs. We therefore implemented macro constants, which indicate the start and end of some section. The actual translation towards a compiler or toolchain specific pragma is done in a toolchain specific include file, which is part of this product release.

The macros and their corresponding implementation of the toolchain specific pragmas offer:

the memory categories: OORTX, OSAL, APPL
the phases: ONPOWER, DOWNPOWER, SLEEP, RUNNING
for code: CODE
for data sizes: 8 (bits), 16 (bits), 24 (bits), 32 (bits), UNSPECIFIED (bits)
for data types: INIT, NOINIT, CONST
for memory types: FAST, SLOW

When you setup a macro scheme which supports the above, you will end up with an impressive list of macros which results in a long include file WSTMemoryTypes.h where the corresponding compiler pragmas are defined. So we actually generate this WSTMemoryTypes.h using two input files:

a file which defines the memory categories, running phases, code and data types and memory types
a file which defines the toolchain specific compiler pragmas for these

The file WSTMemoryTypes.h which is generated using this input, is included in both the Rhapsody generated source files and the OO RTX source files. After linking your application, you can inspect the resulting memory map. You must instruct your locator where to place all sections if you want to override its default behavior.

Please refer to the section Usage | Memory Section Management for further details.