![]() |
![]() |
![]() |
![]() |
![]() |
Internal
Partitioning Diagram Model File
The Targeting Expert needs to know how the SDL system which is used for targeting should be partitioned. This is done by using a partitioning diagram model.
The partitioning diagram model will be generated by the Deployment Editor for deployed systems into a partitioning diagram model file <partitioning diagram model>.pdm. It should not be modified by hand! Please see Generating Partitioning Diagram Data for the Targeting Expert for more information.
If there is no deployment done for a system, the Targeting Expert generates a default partitioning diagram model for its internal use. This partitioning diagram model is not available as a file. For a default partitioning diagram model there is no chance to specify integration models or threads.
Definitions
The complete SDL system is mirrored in the partitioning diagram's application which takes several nodes.
Each node can represent a run-time (physical) object with memory and processing capability and is a collection of several components.
Each component is a collection of different objects, with each object representing an SDL qualifier. A component will result in one executable or OS task.
File Syntax Example
Estimated there is an SDL system like the one shown in Figure 546,
then the simplest possible partitioning diagram model looks like the one shown in Figure 547.
The first few lines of the corresponding partitioning diagram model file is shown in Example 490:
Example 490 : Partitioning diagram model file
TIMESTAMP: 948787119APPLICATION*0: accessdetail+SystemFileName: access.sdtNODE*1: nodeCOMPONENT*2: componentOBJECT*3: objectdetail+Qualifier: accessExplanations
- The TIMESTAMP entry is needed for future implementations.
- The APPLICATION*0: access gives the name of the used SDL system. The 0 is used as an identifier for internal purposes.
- detail+SystemFileName is the name of the used <systemname>.sdt file
- detail+PRFileName is the name of the used <systemname>.pr file. Subsequent entries of detail+PRFileName can be used to insert more than one PR file.
- NODE*1: node specifies that the following components belong to the node. The node is called node and the unique id 1 is used for internal purposes.
- COMPONENT*2: component specifies that the following objects belong to this component. The component is called component and the unique id 2 is used for internal purposes.
- OBJECT+5: object gives one further object which will be assigned to the current component.
- detail+Qualifier: access means that all the SDL entities that are sub entities of the qualifier access (in this case the complete system) will be part of the object.
More Supported Keywords
Details of COMPONENT
- detail+Integration: Light|Threaded specifies in which integration model the component should be build. For backwards compatibility, the keyword ThreadedLight is accepted as an alias for Threaded.
Details of OBJECT
Details of THREAD
- THREAD: name is a sub entry of COMPONENT and specifies a thread, e.g. for a threaded integration.
- detail+ThreadPriority: value specifies the OS priority of the particular thread.
- detail+StackSize: value specifies the stack size of the thread. (bytes)
- detail+QueueSize: value specifies the maximum number of signals that are allowed in the queue.
- detail+MaxSignalSize: value specifies the maximum size of an individual signal in the queue. (bytes)
- detail+OneThreadPerInstance: true|false tells if each process instance will become its own thread in a threaded integration if the value is true.
Configuration Files
For each SDL to C compiler that will be used there is one configuration file ca_conf.def (Cadvanced), cm_conf.def (Cmicro) and ce_conf.def (Cextreme).
The configuration files for all SDL to C compilers can be found in <installationdir>/sdt/sdtdir.
The c*_conf.def files are ASCII text files that can be (should be) extended by you to adapt a new compiler or to adapt a new communications link (Cmicro only).
You can find all the known configuration flags in:
- Some Configuration Macros (Cadvanced)
- Compilation Flags (for Cmicro)
Structure of the Configuration File cm_conf.def
All the descriptions in this section are valid for the SDL to C compiler Cmicro only.
Compiler
All the compilers currently supported by a SDL to C compiler library are listed in the c*_conf.def file like displayed in Example 491.
Example 491 : Structure of a compiler entry
BEGINIAR_C51IAR systems compiler of 8051COMPILERMicrocontroller compilerENDThe first and the last line of the example simply marks the start and the end of one entry.
Line 2 is the flag which will be used to include the appropriate compiler section in the used library (see ml_typ.h for Cmicro and scttypes.h for Cadvanced).
Line 3 is the text which will be shown in the Targeting Experts user interface.
Line 4 must be COMPILER in this case.
Line 5 is the compiler group this compiler should be associated with. In the distributed files c*_conf.def there are three groups, namely:
Communications Link
This section is valid only if the Cmicro SDL to C Compiler is used.
The example below shows the structure of one entry.
Example 492 : Structure of a cm_conf.def entries
1 BEGIN2 XMK_USE_V243 V24 communication4 COMMLINK5 V24 interface6 AUTOSET7 XMK_V24_BAUD8 XMK_V24_DEVICE9 END10 ENDLines 1 and 10 mark the start and the end of one entry.
Line 2 gives the name of the flag as it appears in the generated file ml_mcf.h. According to this example line 3 is the marker which appears in the Targeting Expert graphical user interface.
Line 4 specifies the main group this entry belongs to. It has to be COMMLINK in this case.
Line 5 gives the subgroup of the entry. This subgroup can be anything you like. In the delivered version there is only the subgroup V24 interface. However, you can define your own communications link CAN Bus for example.
The lines 6 and 9 belong together and between these lines all flags are listed which have to be set when the flag on line 2 is set. The amount of flags (lines 7 and 8 in the example) is free. In the same way as AUTOSET in line 6 there can also be the entries RESET or DEPEND.
RESET means the following flags will be reset if this flag is defined and DEPEND means this flag can only be set if the following flags (lines 7 and 8) are already defined.
Not given in the example above is the section VALUE, (like AUTOSET finished by an END) which assign a value to the flag. This section can include three lines of information. The first gives the default value. And, if the value is numeric, the second line gives the lowest and the third one the highest value. You are asked to have a look into c*_conf.def.
Also not given in the example above is the section VALUE_LIST (finished by an END) which assign a value to the flag with a list of allowed values given. The first value is the default value, the following values (with no upper limit) are giving the list of allowed values. The default value must be given in the list again.
Pre-defined Integration Settings
Introduction
Pre-defined integration settings must be seen as a set of default values which can be used for targeting purposes.
There are several pre-defined integration settings distributed with each installation.
- Each set of predefined integration settings is stored in an ASCII file with the extension .its.
- The amount of pre-defined integration settings that are to be handled by the Targeting Expert can simply be enlarged by copying a new file <name>.its or by exporting own settings. (See Export)
- The integration names have to be unique!
- The Targeting Expert searches for .its files in the following directories:
Distributed Pre-defined Integration Settings
For Use with Cadvanced SDL to C Compiler
Timers are not implemented, i.e. timers set in the SDL system will expire at once
See The SDL Simulator.
Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.
See The SDL Simulator.
$(sdtdir)/SCT*VALIDATORSee The SDL Explorer.
Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.
See Compilation Switches.
Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.
See Compilation Switches.
The environment variable WIND_BASE has to be set on your system!
The environment variable OSE_ROOT has to be set on your system!
See Threaded Integration.
For Use with the Cmicro SDL to C Compiler
Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.
Timers are not implemented, i.e a timer set in the SDL system will never expire.
The target is executed as the SDL Target Tester's gateway. After a complete make The SDL Target Testerwill be started and the target can be tested.
Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.
The target is executed as the SDL Target Tester's gateway. After a complete make The SDL Target Tester will be started and the target can be tested.
Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.
The target is executed as the SDL Target Tester's gateway. After a complete make The SDL Target Tester will be started and the target can be tested.
For Use with the Cextreme SDL to C Compiler
- Application (applclenv)
Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.
- Application, debug (debclenvcom)
- Threaded integrations for the platforms
- Posix
- Win32
- VxWorks (Windows)
WIND_BASE has to be set for VxWorks.
Other options, see Optimization and Configuration.
A deployment diagram is needed to specify what the code generator should generate threads for, see The Deployment Editor.
Syntax of the .its Files
There is a more or less complex syntax to be followed in .its files which will be described here. In principle each .its file is divided into four sections:
- The Description about the Settings
- The Settings which are once more split into
- The Configuration Settings to Be Set
- The Configuration Settings to Be Reset
You can find further syntax information in Comments and empty Lines and Other Rules.
Description about the Settings
The Targeting Expert will read in the description and display it in the user interface whenever a set of pre-defined integration settings is selected.
This section starts with [DESCRIPTION] and has got the only entry HelpLink. The description is a link name to this manual.
The Settings
The section of the .its files which contains the settings starts with [SETTINGS]. They must be ordered with the Global Settings (A) first, followed by the Compiler specific Definitions.
The global settings start with the <keyword1> equal to Preferences and the delimiter '+', i.e. an allowed line in this section looks like:
Preferences+<keyword2>: parameter
Example 493 : Pre-defined integration settings (2A)
Preference+IntegrationSettings: <name>The meaning of <keyword2> can be found in the table below.
The name of this pre-defined integration setting is entered here.
The global settings part B start with the <keyword1> equal to the name of the pre-defined integration settings (see Global Settings (A)) and the delimiter '+', i.e. an allowed line in this section looks like:
Example 494 : Pre-defined integration settings (2B)
Simulation+CompilersUsed: MicrosoftSimulation+CodeGenerator: CadvancedSimulation+GenerateMakefile: YESThe meaning of <keyword2> can be found in the table below.
This segment has got all the definitions for an unlimited amount of compilers. All the keywords start with
<name of the setting>+<compiler-name>*
followed by one or two further keywords. If it is followed by two keywords both are separated by '~'.
Example 495 : Pre-defined integration settings (3)
Simulation+Microsoft*Compiler~Tool: clSimulation+Microsoft*Compiler~Options: -nologo %I -ML -c -D_Windows -DSCTDEBCOM /Fo%o %sSimulation+Microsoft*Compiler~Include: -I$(sctuseinclude)Simulation+Microsoft*Compiler~Flag: IC86Simulation+Microsoft*Linker~Tool: linkSimulation+Microsoft*Linker~Options: -nologo -subsystem:console %O /OUT:%eSimulation+Microsoft*ObjectExtension: _smc.objSimulation+Microsoft*ExecutableExtension: _smc.exeSimulation+Microsoft*FileToCompile: $(sdtdir)\INCLUDE\sctsdl.cSimulation+Microsoft*FileToCompile: $(sdtdir)\INCLUDE\sctpred.cSimulation+Microsoft*FileToCompile: $(sdtdir)\INCLUDE\sctos.cSimulation+Microsoft*FileToCompile: $(sdtdir)\INCLUDE\sctmon.cSimulation+Microsoft*FileToCompile: $(sdtdir)\INCLUDE\sctutil.cSimulation+Microsoft*FileToCompile: $(sdtdir)\SCTADEBCOM\sctpost.cSimulation+Microsoft*LibrariesToLink: $(sdtdir)\INCLUDE\msvc50\libpost.libSimulation+Microsoft*LibrariesToLink: user32.libSimulation+Microsoft*Make~Tool: Microsoft nmake (using temporary response file)Simulation+Microsoft*MakefileName: my_makefile.mSimulation+Microsoft*MakefileGenerator: -Simulation+Microsoft*ObjectDirectory: objects
All the keywords and the allowed combinations can be found in the table below.
Compiler Tool Compiler Tool2 Compiler Tool3 Compiler OptionsCompiler command line options (Please see Compiler)
Compiler Options2 Compiler Options3 Compiler LibFlagThe compiler's option to set defines plus the library flag (e.g. SCTDEBCOM)
Compiler IncludeThe compiler's option for include paths and the include paths
Compiler CodIncludeThe compiler's option for include paths and the include paths to the coder files
Compiler FlagCompiler flag (Please see Compiler Flag)
Linker Tool Linker OptionsLinker command line options (Please see Linker)
ObjectExtension ExecutableExtension FilesToCompileKernel, library and template files to be compiled. This entry can be used more than once.
TesterFilesToCompileTester files to be compiled. This entry can be used more than once. (Cmicro only)
FilesToCopyTemplate files which should be copied into the target directory. Environment variable §(sdtdir) can be used
ObjectsToLinkAdditional object files to be linked. This entry can be used more than once.
LibrariesToLinkAdditional libraries to be linked (e.g. the compiler's libraries). This entry can be used more than once.
Make Tool MakefileNameThe name of the makefile to be generated (or respectively to be used) is entered here.
MakefileGeneratorThe Targeting Experts supports the use of external makefile generators which is to be entered here. An intern means that the build-in makefile generator is to be used
ObjectDirectoryThe relative path (seen from the target directory) for the object directory can be entered here. If not specified Targeting expert will generate the makefile in a way that the object files will be written into the target directory when make is executed.
LibraryDirectoryIf this entry is specified the SDL to C compiler's library will be taken from the specified path. If not specified it will be taken from $sdtdir (%SDTDIR%).
Download Tool PreMakeAction to perform before the target application will be made in the makefile.
PreCompileIf the generated code should be modified before it is compiled, an appropriate application (complete command line) should be entered here.
PostLinkIf the linked target application needs to be modified (e.g. conversion into HEX format), the appropriate application (complete command line) should be entered here.
AddCompiler ToolFor the additional files (see FilesToCompile) the name of the compiler application must be entered here.
AddCompiler OptionsThe command line options for the compiler in AddCompiler must be specified here.
AddCompiler IncludeThe compiler's option for include paths and the include paths for the compiler entered in AddCompiler
AddCompiler DependThe dependencies for the additional files (used inside of the generated makefile).
AddObjectExtensionThe object extension of the AddCompiler must be entered here.
AddFilesToCompileKernel files to be compiled (e.g. communications link). This entry can be used more than once.
Default Configuration Settings
For several pre-defined integrations it is necessary to have some configuration flags defined as default. In this section a simple list of all configuration flags which should be set is given.
This section starts with [CONFIGURATION_DEFAULT].
Please see Configuration Files for more information about configuration flags.
Configuration Settings to Be Set
For several pre-defined integrations it is necessary to have some configuration flags set without giving you the chance to un-select them. In this section a simple list of all configuration flags which have to be set is given.
This section starts with [CONFIGURATION_SET].
Please see Configuration Files for more information about configuration flags.
Configuration Settings to Be Reset
In opposite to the configuration flags which have to be set, it is of course necessary sometimes to prevent the selection of other flags. This can be done in this section by simply listing all the flags that have to be reset.
This section starts with [CONFIGURATION_RESET].
Please see Configuration Files for more information about configuration flags.
SDL to C Compiler Settings to Be Disabled
For some pre-defined integrations it does not make sense to configure all the SDL to C compiler options available. It is possible here to list all the options to be disabled in the user interface.
This section starts with [SDL_TO_C_COMPILER_DISABLED].
SDL to C Compiler Settings to Be Enabled
For some pre-defined integrations some SDL to C compiler options needs to be enabled by default. It is possible here to list all the options to be enabled in the user interface.
This section starts with [SDL_TO_C_COMPILER_DEFAULT].
Comments and empty Lines
- Empty lines are allowed everywhere in the an .its file.
- Comments are allowed everywhere in the .its file but have to start with an '#' in the first column.
Other Rules
- Only one set is allowed per .its file
- The amount of compilers supported for each set is unlimited.
- The characters '[', ']', '+', '*', '~' and ':' are forbidden in compiler names or the name of the pre-defined integration settings itself.
User-defined Integration Settings
All the settings done by the user will be stored in separate files into the target directory, i.e.:
- The complete set of settings will be stored (not the difference to the defaults)
- There is one file for each integration configuration done for an application, node or component
- If several nodes or components have to use the same settings it is possible to manually select one file for them.
Please see Handling of Settings.Target Sub-Directory Structure
The Targeting Expert automatically sets up a sub-directory structure for all the applications, nodes and components. Furthermore there is a sub directory for each kind of integration done.
Example 496 : Sub-directory structure
Estimated there is a partitioning diagram which looks like Figure 550, the Targeting Expert generates a sub-directory structure like:
<target_dir>+ application._0+ node._1+ component._2
- Later, after you have built a Simulator and an Explorer for the component, for example, then the sub-directory structure was extended to:
<target_dir>+ application._0+ node._1+ component._2+ Simulator+ ValidatorFlat Directory Structure
When using an .sdt or .pr file as input the directory structure will be flatten automatically. I.e it will look like
<target_dir>+ application._0+ Simulator+ ValidatorThis is possible because there can only be one node with one component in both cases.
Generated Makefile
Before the selected make tool is invoked the Targeting Expert generates a makefile with all of the necessary settings done. (Please see Configure Compiler, Linker and Make for information on how to set up the makefile generation.)
The standard header files of the used SDL to C compiler library are not used as dependencies in the compilation rules, i.e. after modifying one of these files you have to select the Clean entry in the Make Menu.
Comparisons
There are a few differences that need to be mentioned when comparing the way the Targeting Expert handles makefiles with the way the Organizer's Make dialog does.
When using the Targeting Expert...
- ... there is no makefile (systemname.m) generated by the SDL to C compiler. Instead it generates a sub-makefile (component_gen.m) which is automatically parsed and inserted into the Targeting Expert makefile, i.e. the Targeting Expert still gets all the information from the SDL to C compiler but in a different way.
- ... there is not support of template makefiles by the Targeting Expert. The makefiles generated by the Targeting Expert can be modified directly in the so called "user sections". Please see User Modifications.
- ... there are no makeoptions/make.opt files (taken from the kernel directories) used at all. Instead of this, the Targeting Expert gets all the make information from the Pre-defined Integration Settings and places them into its makefile.
- ... the comp.opt files placed in the kernel directories are not used at all! Again all the information is taken from the Pre-defined Integration Settings.
- ... the sccd cannot be used for pre-processing purposes as default because the Targeting Expert does not use sccd.cfg files from the kernel directories. It is recommended to use the Targeting Expert Preprocessor instead.
The only exceptions in which the Targeting Expert uses some information from the associated kernel directory are the integrations Validation and TTCN Link. In both cases a library is taken from the kernel directory.
User Modifications
After all it is possible that there are a few adaptations to be done, e.g. if there is an assembler file which needs to be assembled and linked.
Example 497 shows the section of a generated makefile where it is possible to add further object files.
Example 497 : Generated makefile (1)
######## UserObjectsStart (Do not edit this line!) ##########userOBJECTFILES1 =userOBJECTFILES2 =######## UserObjectsEnd (Do not edit this line!) ##########The list userOBJECTFILES1 will be inserted at the front of all the object files to link. Accordingly userOBJECTFILES2 will be inserted at the end.
The rules and the dependencies for the files in Example 497 must be given in the section shown in Example 498.
Example 498 : Generated makefile (2)
######## UserRulesStart (Do not edit this line!) ################## UserRulesEnd (Do not edit this line!) ##########
Any modification that is done outside of the sections described in Example 497 and Example 498 will be overwritten when the makefile is generated anew.
Parameter File sdttaex.par
General
One of the delivered configuration files used by the Targeting Expert is called sdttaex.par. Several different sections give information that is statically used during runtime. Under normal circumstances this file does not need to be modified. However, there might be the need to extend the Targeting Expert functions.
Please see the following sub-sections for more information what can be configured:
- Compiler Error Descriptions
- Preprocessor Commands
- Make Applications
- C++ Options
- Debug Options
- Compiler Dependent Defaults
- Restricted Compilers
- Editor Commands
- Additional Files
- Host Configuration Options (used for Cmicro only)
Search Order for sdttaex.par
The following shown search order applies when the Targeting Expert is started. The distributed version of sdttaex.par is always placed in <installationdir>/bin/<platform>bin
Compiler Error Descriptions
The section [COMPILER-ERROR-DESCRIPTION] of sdttaex.par is filled with regular expressions describing the construction of compiler error messages.
Example 499 : [COMPILER-ERROR-DESCRIPTION]
[COMPILER-ERROR-DESCRIPTION]{cl} {1} {.*([1234567890]} {0} {2} {([1234567890]*)} {1} {1}{cc166} {2} {.*[A-Za-z]:} {0} {1} {[1234567890]*: } {0} {2}{gcc} {1} {.*:[1234567890]} {0} {2} {:[1234567890]*:} {1} {1}{icc8051} {1} {.*,[1234567890]} {1} {3} {,[1234567890]* } {1} {1}{c51} {1} {OF .*[CH]: } {3} {2} {LINE [1234567890]* OF} {5} {3}{cc} {1} {.*, l} {1} {4} {line [1234567890]*:} {5} {1}{CC} {1} {.*, l} {1} {2} {line [1234567890]*:} {5} {1}{aCC} {1} {: .*,} {3} {2} {line [1234567890]* #} {5} {2}{ccpentium} {1} {.*:[1234567890]} {0} {2} {:[1234567890]*:} {1} {1}{icpp} {1} {!E .*(} {3} {1} {(.*)} {1} {1}
Each line gives the description for one compiler. The eight entries have the meaning shown below (explained on the gcc entry):
- The name of the compiler executable
- The amount of lines the compiler error message takes
- The regular expression to determine the erroneous file
- The amount of characters thrown away at the beginning of the found file name
- The amount of characters thrown away at the end of the found file name. (In this example the colon and the numeric character do not belong to the file name but both are needed to find it.)
- The regular expression to determine the line number
- The amount of characters thrown away at the beginning of the found line. (In this example the colon at the front of the regular expression does not belong to the line number but is needed to find it).
- The amount of characters thrown away at the end of the found line. (In this example the colon at the end of the regular expression does not belong to the line number but is needed to find it).
Preprocessor Commands
This section takes the preprocessor commands for all the default compilers that can be set in the preferences. It has got the following contents:
Example 500 : [PREPROCESSOR-COMMANDS]
[PREPROCESSOR-COMMANDS]{Sun GNU gcc} {gcc -P -E -C}{Sun Workshop cc} {cc -C -P}{Sun Workshop CC} {CC -E}{Microsoft} {cl -P -EP -C -nologo}Make Applications
The section [MAKE_APPLICATIONS] of sdttaex.par is used to specify the command line of the make application, i.e. how it will be invoked.
Example 501 : [MAKE_APPLICATIONS]
[MAKE_APPLICATIONS]{Microsoft nmake} {nmake /f} {} {}{Microsoft nmake (ignore exit codes)} {nmake /i /f} {} {}{Microsoft nmake (using temporary response file)} {nmake /f} {@<<\n\t} {\n<<}{Tasking mk166} {mk166 -f} {} {}{VxWorks make} {make -f} {} {}{UNIX make} {make -f} {} {}
Each line is the description for one make application. The four entries (given between '{' and '}') have the following meaning.
- The text to identify it in the make configuration. See Make tool
- The name of the make application and the option used to specify the makefile.
- This is the start sequence for the generation of temporary response files. Empty for most make applications.
- This is the stop sequence for the generation of temporary response files. Empty for most make applications.
C++ Options
The C++ options specify what has to be added to the compiler's Options and the linker's Options to compile and link the SDL to C compiler's library as C++ code.
[C++OPTIONS]{Sun GNU gcc} {-xc++} {-lstdc++}{Microsoft} {-TP} {}Each line consist of the three entries
Debug Options
The debug options specify what has to be added to the compiler's Options and the linker's Options to compile and link the target application including debug information.
[DEBUG-OPTIONS]{Sun GNU gcc} {-g} {-g}{Sun Workshop cc} {-g} {-g}{Sun Workshop CC} {-g} {-g}{Microsoft} {-D "_DEBUG"} {/debug}{icc12} {-g} {-g}Each line consist of the three entries
Compiler Dependent Defaults
The compiler dependent defaults ease the implementation of new pre-defined integrations because the values given here do not need to appear again in the .its file(s).
Example 504 : [COMPILER-DEPENDENT-DEFAULTS]
[COMPILER-DEPENDENT-DEFAULTS]{Borland} {bcc32} {bcc32} {tlib} {.obj} {.exe} {.lib} {%I -c -w- -DUSING_DLL - DIC86 -o%o %s} {-e%e %L %O} {%l /C /E /P256 %O} {-I$(sctCODERDIR)} {bcc_obj} {Borland make (using temporary response file)}
The different entries mean the following (listed from left to right):
- Compiler name
- Compiler tool name
- Linker tool name
- Library manager name
- Object file extension
- Executable file extension
- Library file extension
- Compiler options
- Linker options
- Library Manager Options
- Coder include path
- Relative path to intermediate directory
- make application to use per default
Restricted Compilers
There are a few target compilers which do not support file names which are longer that 8.3 (8 character in front of '.' and a 3 character extension). To ensure that files are generated only which fit to the 8.3 requirement. This section looks as follows:
[8.3-COMPILERS]{c51}{icpp}{icc12}Editor Commands
The Targeting Expert allows to use other text editor different to the build-in one. The information how to start these editors is given in the section [EDITOR-COMMANDS] shown below.
Example 506 : [EDITOR-COMMANDS]
[EDITOR-COMMANDS]{Windows} {TextPad} {textpad -ca -q "%f"(%l,0)}{Windows} {UltraEdit} {UEdit32 %f/%l/0}{Windows} {Codewright} {codewright %f -G%l}{Windows} {MS DeveloperStudio} {msdev %f}{UNIX} {Emacs} {emacs %f}{UNIX} {dtpad} {/usr/dt/bin/dtpad %f}{UNIX} {nedit} {nedit -line %l %f}There are 2 placeholders used in the command. %f will be replaced by the name of the file to open and %l gives the line number which should be shown.
Additional Files
The sections shown in Example 507 will used to find out which files belong to external parts of the distributed SDL to C compiler libraries.
Example 507 : Additional Files Sections
[CMICRO-KERNEL-FILES]$(sctkerneldir)/mk_main.c$(sctkerneldir)/mk_sche.c$(sctkerneldir)/mk_queu.c$(sctkerneldir)/mk_outp.c$(sctkerneldir)/mk_tim1.c$(sctkerneldir)/sctpred.c[CMICRO-TI-KERNEL-FILES]$(sctkerneldir)/ti_sche.c$(sctkerneldir)/ti_queu.c$(sctkerneldir)/ti_outp.c$(sctkerneldir)/ti_tim1.c$(sctkerneldir)/ti_init.c$(sctkerneldir)/sctpred.c[TESTER-FILES]$(scttesterdir)/mt_tsdl.c$(scttesterdir)/mt_tsys.c$(scttesterdir)/mt_cod.c$(scttesterdir)/mt_cmd.c$(scttesterdir)/mt_opt.c$(scttesterdir)/mt_deb.c$(scttesterdir)/mt_rec.c$(scttesterdir)/mt_play.c$(sctkerneldir)/ml_buf.c[TI-TESTER-FILES]$(scttesterdir)/mt_tsdl.c$(scttesterdir)/mt_tsys.c$(scttesterdir)/mt_cod.c$(scttesterdir)/mt_cmd.c$(scttesterdir)/mt_opt.c$(scttesterdir)/mt_deb.c$(sctkerneldir)/ml_buf.c[CODER-FILES]$(sctCODERDIR)/cucf_er.c$(sctCODERDIR)/cucf_er_sdt.c$(sctCODERDIR)/bms/bms.c$(sctCODERDIR)/bms/bms_small.c$(sctCODERDIR)/ems/ems.c$(sctCODERDIR)/ems/ems_eo_sdt.c$(sctCODERDIR)/er/ascii/ascii.c$(sctCODERDIR)/er/ber/ber_base.c$(sctCODERDIR)/er/ber/ber_content.c$(sctCODERDIR)/er/ber/ber_decode.c$(sctCODERDIR)/er/ber/ber_encode.c$(sctCODERDIR)/er/per/per_base.c$(sctCODERDIR)/er/per/per_content.c$(sctCODERDIR)/er/per/per_decode.c$(sctCODERDIR)/er/per/per_encode.c$(sctCODERDIR)/er/mms/mms.c$(sctCODERDIR)/vms/vms_base.c$(sctCODERDIR)/vms/vms_check.c$(sctCODERDIR)/vms/vms_export.c$(sctCODERDIR)/vms/vms_print.c[TCP-IP-FILES]$(sctTCPIPDIR)/tcpipcomm.c
Host Configuration Options
The host configuration options are the default host configurations for different compilers when using the Target Tester, i.e. these options are only used for Cmicro applications. An example can be found below.
Example 508 : [HOST-CONFIGURATION-OPTIONS] (Borland compiler)
[HOST-CONFIGURATION-OPTIONS]bcc32 "UNIT-NAME sec"bcc32 "UNIT-SCALE 1.0"bcc32 "LENGTH_CHAR 1"bcc32 "LENGTH_SHORT 2"bcc32 "LENGTH_INT 4"bcc32 "LENGTH_LONG 4"bcc32 "LENGTH_FLOAT 4"bcc32 "LENGTH_DOUBLE 8"bcc32 "LENGTH_POINTER 4"bcc32 "ALIGN_CHAR 8"bcc32 "ALIGN_SHORT 8"bcc32 "ALIGN_INT 8"bcc32 "ALIGN_LONG 8"bcc32 "ALIGN_FLOAT 8"bcc32 "ALIGN_DOUBLE 8"bcc32 "ALIGN_POINTER 8"bcc32 "ENDIAN_CHAR 1"bcc32 "ENDIAN_SHORT 21"bcc32 "ENDIAN_INT 41"bcc32 "ENDIAN_LONG 41"bcc32 "ENDIAN_FLOAT 41"bcc32 "ENDIAN_DOUBLE 81"bcc32 "ENDIAN_POINTER 41"
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |