| |
|
|
|
|
|
Configuration Overview The general introduction to using Rational Exec as well as the steps for getting started using one of the BSPs provided in the release are in "Getting Started" in Programming for Rational Exec.
The following sections describe the components and structures used in creating a new board support package (BSP) or modifying an existing one.
- Configuration Components
- Board Support Package (BSP) Subsystem Structure
- View Naming Conventions
- Configuration Package and Interface Package
- Memory Layout
To begin working on a configuration that requires some modification or to configure for custom target hardware, follow the instructions in Building a Custom Configuration.
Configuration ComponentsApex contains the following components that you can configure for your target system:
TDM, the kernel, and the no-tasking-kernel are configured, linked, and downloaded as separate programs, independent of your application.
The user library is configured, linked with your application, and then downloaded as part of the application.
TDM
The Target Debug Monitor (TDM) can be thought of as an extension for the monitor firmware supplied with your embedded system. TDM allows you to download and debug applications. It also provides the mechanism for I/O to and from the host computer (referred to as "cross I/O").
To perform these functions, TDM must be configured to
- Respond to interrupts
- Handle serial communications
- Communicate with the host debugger process
Once TDM has been configured and tested, it is often placed in ROM as a replacement for the native monitor firmware.
Configuring TDM consists primarily of setting up the trap configuration table and interfacing TDM to your board's serial port. After downloading TDM to your board, use TDM to download all other programs to the board.
Details are in Configure TDM.
You can also run applications without using TDM. This is described in Running an Application Without TDM.
EneT (Network TDM)
EneT is an Ethernet version of the Target Debug Monitor (TDM). It provides program download and system-level debugging of embedded programs. Enet uses the UDP/IP protocols to communicate with the host while TDM contains its own internal implementation of the UDP/IP protocol stack.
EneT is a separately licensed product but is included in the Apex for Rational Exec product.For a complete description of Enet, see Using Enet with Rational Exec.
The Kernel
The kernel, also known as runtime system or executive, is a separate program that provides services to applications such as mutexes, memory management and scheduling. The kernel manages the resources of your target system and supplies thread scheduling support for tasking.
Part of the kernel configuration process supplies parameters for these resources: memory layout, trap and interrupt vector layout, etc.
Another phase of kernel configuration supplies the routines that manage certain key resources, for example, the timer.
The services provided by the kernel are also highly configurable so that only those services needed by the application are present in the kernel image. Once the kernel is configured and tested, it may also be placed in ROM with TDM, so that neither component needs to be re-downloaded.
Details are in Configure the Kernel.
The No-Tasking Kernel
The no-tasking kernel supports all other functions of the full kernel: it initializes the CPU, initializes the interrupt/exception trap and interrupt vector tables, starts the user program, provides full support for hardware exceptions and responds to the exit trap from the user program.
The no-tasking kernel is configured, compiled, and linked in the same way as the tasking version.
Details are in Configure the Kernel.
The No-Kernel Program
The no-kernel program is used to create applications that have very tight code space requirements and little need for runtime services. Using the no–kernel, you can build a small stand-alone program of less than 10KB.
Details are in The No-Kernel Program.
The User Library
Lastly, the user library consists of support routines that are linked with the user's program.
The VADSexec services, semaphores and mailboxes for example, are built on top of the user library.
The user library also contains the mechanism for interfacing the user's program to the kernel and the user program startup routine. It provides default values for such things as stack size, floating-point configuration, mutex attributes, and configurations for layered products.
Once this library has been configured, user applications are linked with it to create an executable. This executable is then downloaded to the target. TDM then begins execution of the kernel which in turn starts the user application.
Details are in Configure the User Library.
Warning: Configuring Apex requires knowledge of Ada and how your target hardware works. Expect to spend at least one-half day, and possibly as many as five days, configuring the Apex kernel and TDM for a specific target system. This job is easier if you have a working knowledge of the target hardware or if you can work with a hardware engineer.
Board Support Package (BSP) Subsystem StructureThe following subsystems located in the $APEX_BASE/ada directory are used to define a board support package:
Contents
Import Relationships
View Naming ConventionsEach view name is constructed from a combination of directory names. The naming conventions used for the Rational Apex for Rational Exec subsystem, view, and model names are listed in Model View Names and View Names in Subsystems. Directory Name Values That Make Up View Names lists the components of these naming conventions.
Model View Names
Subsystem: model.ss
BSP-Specific Models
For a specific board, model the views in which programs are linked on this view.
Construction
target_family.compiler_variant.board_variant.language_variant.version.view_type
Examples
m68k.rx_mc68060.mvme177.ada83.x.y.z.rel
mips.rx_mips1b.idt381.ada83.x.y.z.rel
Models That Are Not BSP-Specific
Construction
target_family.compiler_variant.language_variant.version.view_type
Example
i386.rx_i386.board.ada83.x.y.z.rel
Models That Are Not BSP-Specific and Have No Imports
Construction
target_family.compiler_variant.language_variant.no_imports.version.view_type
Examples
power.rx_ppc.no_imports.ada95.x.y.z.rel
rh32.rx_p3.no_imports.ada95.x.y.z.rel
View Names in Subsystems
Subsystems: board_common.ss, usr_conf.ss, krn_conf.ss
Subsystem: tdm_conf.ss
Construction
target_family.compiler_variant.board_variant.language_variant.comm_type.version.
view_type
Examples
mips.rx_mips1b.hkv3500.net.ada83.x.y.z.rel
power.rx_ppc.mvme1604.net.ada83.x.y.z.rel
Subsystem: lrm.ss, predefined.ss, ... (all subsystems not previously listed)
Construction
target_family.compiler_variant.version.view_type
Examples
rh32.rx_p3.ada95.x.y.z.rel
sun4_solaris2_ada95.x.y.z.rel
Directory Name Values That Make Up View Names
target_family
Defines processors that share a common tool set.
i386 power
m68k rh32
mips
compiler_variant
Identifies general object code compatibility. This defines the runtime interface to the underlying OS, the processor architecture, endian, etc. Any code that matches these characteristics is compile and link level compatible.
OS
rx - Rational Exec for embedded systems
vw - Tornado/VxWorks
lx - LynxOS
target_architecture
i386 mips1
mc68020 mips2
mc68040 ppc
mc68060 p3 (rh32 Model p3) Note: Endian is optional.
floating_point
sfp - software floating point
hfp - hardware floating point
endian
b - big endian
l - little endian
comm_type
In views of tdm_conf.ss, comm_type indicates whether a serial tty or UDP/IP network connection is being configured
serial - Serial tty
net - Network Note: The network option is separately licensed.
board_variant
Specific implementation of a board. This name can be any string.
language_variant
ada83 c++
ada95
version
Version number of this release.
x.y.z.rel x, y, and z are the numbers of the release.
Configuration Package and Interface PackageThis section presents information about the structure of the components that you configure and an overview of the configuration process.
Each configurable component (TDM, EneT (Network TDM), the kernel, the no-kernel, and the user library) has an associated configuration package which is listed in Table 1 . You configure a component by modifying and compiling its associated configuration package. During the configuration process you provide new values for the tables, and subprograms described and defined in the configuration package. The configuration package for each component also contains the startup procedure where execution begins.
Figure 1 The Interface Package
The interface package, in rational.ss, declares types and values that must be common between the item being configured and the configuration package. Included in the interface packages are type declarations, special constant declarations, boot and execution entry point routines, and support subprograms that may be called by the configuration package.
Warning: It is very important that the interface package match the archive with which it is being linked. Therefore, you must not modify the interface packages. If you are upgrading to a new release of Apex, you must use the latest versions of the interface packages with the new archives. A mismatched archive and interface package causes your software to fail in unpredictable ways.
Warning: Do not modify configuration package specifications, only the body.
Memory LayoutMany of the decisions that must be made to configure the Apex target software require assigning specific blocks of physical memory to various parts of TDM, the RTS kernel, and the user program. This presents a bit of a chicken and an egg problem, since you won't know how big each of the pieces are until after you are through the configuration process, but you can't get through the configuration process until you can layout all of the target software in memory. To get around this problem, we provide example layouts that work.
The memory maps in these figures show all of the sections of memory used by an example Apex configuration.
The maps include the memory occupied by the programs themselves: TDM, the RTS kernel, and the user program, in addition to the dynamic data areas required by these programs.
These maps are only an examples. The order of the sections of memory and their sizes are all under user control.
- Example M68000 Family Memory Map (1 Mbyte).
- Example CPU32 Memory Map (192 Kbyte)
- MIPS Example Memory Map
- PowerPC Example Memory Map
- RH32 Example Memory Map
- i386 Family Example Memory Map
Following are blank memory maps provided as a worksheet for you to lay out memory.
- M68000 Family Memory Map Worksheet
- MIPS Memory Map Worksheet
- PowerPC Memory Map Worksheet
- RH32 Memory Map Worksheet
- i386 Family Memory Map Worksheet
Figure 2 Example M68000 Family Memory Map (1 Mbyte)
Figure 3 Example CPU32 Memory Map (192 Kbyte)
Figure 4 MIPS Example Memory Map
Figure 5 PowerPC Example Memory Map
Figure 6 RH32 Example Memory Map
Figure 7 i386 Family Example Memory Map
Figure 8 M68000 Family Memory Map Worksheet
Figure 9 MIPS Memory Map Worksheet
Figure 10 PowerPC Memory Map Worksheet
Figure 11 RH32 Memory Map Worksheet
Figure 12 i386 Family Memory Map Worksheet
| Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
| |
|
|
|
|
|
 |
 |