IBM
Contents Index Previous Next



Tight Integration Code Reference


This section explains data types, procedures and macros used in a Tight Integration (Light Integrations are explained in the Master Library).

General Macros

XPP(x)

The macro XPP is used in function declarations to specify the function parameters. It is defined like this:

#define XPP(x)  x

if function prototypes according to ANSI C can be used.

xptrint

The following type is also always defined:

#define xptrint unsigned

where xptrint should be an int type with the same size as a pointer.

xPrsNode and xPrdNode


typedef struct xPrsStruct  *xPrsNode;
typedef struct xPrdStruct  *xPrdNode;

xPrsNode and xPrdNode are pointers to structs holding instance data for an instance of a process or a procedure. Note that some parts of the structs are OS-dependent.

xInputAction, xNotInSignalSet ...

These defines specify the different ways of handling a signal.

Macros to Exclude Unnecessary Code

The following macros are defined to exclude unnecessary code for IdNode variables etc.:

#define XNOSTARTUPIDNODE
#define XOPTSIGPARA
#define XOPTDC
#define XOPTFPAR
#define XOPTSTRUCT
#define XOPTLIT
#define XOPTSORT
#define XNOUSEOFSERVICE
......

Macros to activate Signal-Free-Functions

The following macro must be defined to activate the Signal-Free-Functions. This is necessary if signals and timers with string parameter (dynamic allocated) are used - to avoid memory leaks.

#define XFREESIGNALFUNCS

If strings not are used as parameters in signals this flag should not be set cause it does lead to some performance deterioration. (Normally this define is set in the make-file).

For timer string parameters the define

#define XTIMERSWITHSTRINGPARAMS

must be set.

The following macro must be defined to activate the Signal-Free-Functions. This is necessary if signals and timers with string parameter (dynamic allocated) are used - to avoid memory leaks.

#define XFREESIGNALFUNCS

Default Priorities

One group of macros defines default priorities for processes and signals:

#ifndef xDefaultPrioProcess 
#define xDefaultPrioProcess      RTOSPRIODEFAULT
#endif

#ifndef xDefaultPrioSignal
#define xDefaultPrioSignal       RTOSPRIODEFAULT
#endif
...

Macros to Implement SDL

First in this section is a macro defining the symbol table root:

xIdNode         xSymbolTableRoot;

XPROCESSDEF_C and XPROCESSDEF_H

These macros define the start-up function for a PAD function. It is this function that is called in the task creation. As mentioned before this function will after some variable initializations call the PAD function. The definition of the start-up function varies in different RTOS, that is why there is a second OS-specific macro here.

STARTUPSIGNAL, ALLOCPRSSIGNAL, etc.

Each signal in an application is assigned a unique integer value. The values 31992 through 32000 are reserved for internal signals like the start-up signal.

Variables in the PAD Function

PROCESS_VARS, PROCEDURE_VARS

These macros define the elements in the xPrsStruct and xPrdStruct respectively.

YPAD_YSVARP

This macro defines a variable representing a pointer to a signal's parameter area.

YPAD_YVARP

This macro defines the variable yVarP which represents the process instance data.

LOOP_LABEL, LOOP_LABEL_PRD, LOOP_LABEL_PRD_NOSTATE

These three macros define the eternal loop inside processes, procedures and procedures without a state.

START_STATE

Each state in a process and procedure is represented as an integer. The Start state will always have the value 0.

Using OSE Trace Features

Note:

IBM Rational has noticed that the OSE-trace feature can make the application crash in some situations. This seems to happen when a SDL process (OSE-task) sends a signal immediately before terminating. If you come across this problem, first check if the application works correctly when generated without OSE-trace.


http://www.ibm.com/rational
Contents Index Previous Next