IBM
Contents Index Previous Next



Bare Integration


This section deals with functions that must be adapted by the user in order to connect the SDL system to the environment i.e. connection to target hardware, and the environment.

Implementation of Main Function

The user may decide to implement his own main() function body when it comes to target application in a bare integration. A default main() function is included in the template file mk_user.c.

The implementation of a first main function looks like this:

Example 606

main ()
{
  xmk_InitQueue();
  xmk_InitSDL ();
  xmk_RunSDL ();
}

Of course this example does nothing in order to start the SDL Target Tester. The only possible way to get a very simple trace output is to define:

#define XMK_ADD_PRINTF

in ml_mcf.h with the help of the Targeting Expert. This will include calls to the C function xmk_printf() at several places in the generated C code and the Cmicro Library. The xmk_printf() function is available as an example in the file mk_cpu.c.

The user can use the main() functions delivered with the Cmicro Kernel to have full access to all Cmicro features. This delivered main() function is a template and can be modified to add or remove functionality.

Integrating Hardware Drivers, Functions and Interrupts

There is no extra handling for hardware drivers, hardware functions and interrupt service routines. It is necessary to implement an interface in the user's application. Hardware drivers, hardware functions and interrupt service routines are seen from the SDL system as the environment. The user has to implement the interface between the SDL system and the environment as it is described in the following subsections.

Critical Paths in the Cmicro Library

As with every real time application the Cmicro Library has to deal with critical paths.

Figure 597 : Critical paths

These are well defined in the source code using two macros namely XMK_BEGIN_CRITICAL_PATH and XMK_END_CRITICAL_PATH (see file ml_typ.h/compilersections).

The macros are expanded to compiler specific calls which disable/enables interrupts. The calls are counted using an internal variable, thus after having called XMK_BEGIN_CRITICAL_PATH n times XMK_END_CRITICAL_PATH has also to be called n times, to enable the interrupts again.

In the Cmicro Library these macros are used to disable/enable interrupts only. The application should take care not to handle interrupts without using these macros or at least evaluating the internal counter.

Caution!

When it comes to implementing the interrupt handling routines it is of the greatest importance to know about the Cmicro Library's handling of critical paths. Unpredictable results may result from a careless implementation!

Initializing the Environment / Interface to the Environment

xInitEnv()

There is one C function called xInitEnv() available as a template in the generated file env.c. The user should fill this module out appropriately, thus implementing connection to the environment (drivers, interrupt service routines and so on).

Receiving Signals from the Environment

There are two possibilities to send signals into the SDL system. In all cases, the user has to specify an SDL input symbol in the process which has to consume the signal. The possibilities are:

  1. Polling external events.
    This is done by the C function xInEnv(), which is called by the Cmicro Kernel after each transition.
  2. Directly sending signals into the SDL system.
    For example directly in an interrupt service routine. This is possible by using the XMK_SEND_ENV() function. This function directly operates on the SDL queue. If interrupt service routine is used and can result in signal sending the user need to manually define flag XMK_USE_INTERRUPT_SERVICE_ROUTINE to enable additional needed critical paths in kernel.

Caution!

For each signal sent into the system, the user must ensure that the addressed receiver process instance exists. Each pid value is checked for consistency by the Cmicro Kernel. In the case of an inconsistency the ErrorHandler() is called with an error message.

xInEnv()

Parameters:

In/Out: -no-
Return: -no-

In the case when no interrupt service routine is available to handle an external event, the Cmicro Kernel can poll external events. The user must use the C function xInEnv() in the file env.c generated by the Targeting Expert.

For example, a hardware register can then be checked in order to establish if its value has changed since the last call.

If an external signal is detected, then one of the xmk_Send*() functions is to be called thus enabling the signal to be put into the SDL queue.

Note:

There is a file called <systemname>.ifc, which is generated by the Cmicro SDL to C Compiler. It is necessary to include this file together with ml_typ.h before defining xInEnv(). This is necessary to have access to all the objects that are generated by the Cmicro SDL to C Compiler. The user should also make sure that this file is generated, because the analyzer's make menu contains an option for this.

Example 607 : xInEnv()

Assume, a hardware register where the value 0 is the start-value and where any other value means: data received. Two signals, namely REGISTER_TO_HIGH, and REGISTER_TO_LOW are to be defined in the SDL system, with a process receiving these. Then the user supplied C code should look like this (the <p> below stands for the automatically generated prefix, see the file sdl_cfg.h):

void xInEnv (void)
{
XMK_SEND_TMP_VARS
  static state = 0;
              /* state, to detect changes in the */
              /* hardwareregister               */

 /* BEGIN User Code */
 if ((state==0) && (hw_register != 0))
 /*   END User Code */
 {
   XMK_SEND_ENV (REGISTER_TO_HIGH, 
                 xDefaultPrioSignal, 
                 0,
                 NULL, 
 /* BEGIN User Code */
   GLOBALPID(XPTID_<p>_ReceiverName,0));
   state = 1;
 /*   END User Code */
   return;
 }

 /* BEGIN User Code */
 if ((state==1) && (hw_register == 0))
 /*   END User Code */
 {
   XMK_SEND_ENV (REGISTER_TO_LOW, 
                 xDefaultPrioSignal, 
                 0,
NULL,
/* BEGIN User Code */
   GLOBALPID(XPTID_<p>_ReceiverName,0));
   state = 0;
/*   END User Code */
    return;
  }

  return;
} /* END OF SAMPLE */

Caution!

The function xInEnv() contained in the file env.c is generated by the Targeting Expert. To make sure that changes done by the user will not be lost when generating again it is allowed to modify this file only between the comments /* BEGIN User Code */ and
/* END User Code */.

Furthermore it is not allowed to remove these comments or to add similar at other places which could especially happen when copy and paste is used during editing.

XMK_SEND_ENV()

Parameters:

In/Out: xPID Env_ID

        xmk_T_SIGNAL sig
 
        #ifdef XMK_USE_SIGNAL_PRIORITIES
          xmk_T_PRIO prio
        #endif
 
        #ifdef XMK_USED_SIGNAL_WITH_PARAMS
          xmk_T_MESS_LENGTH data_len,
          void xmk_RAM_ptr  p_data
        #endif

        #ifdef XMK_USE_RECEIVER_PID_IN_SIGNAL
          xPID Receiver
        #endif

Return: -no-

It is possible to send signals directly into the SDL system by calling the C function XMK_SEND_ENV(), no matter whether preemption is used or not. No conflict occurs, if an interrupt service routine uses a XMK_SEND_ENV() function parallel to the C function xInEnv().

This function is to be called when a signal is to be sent into the SDL system, e.g. within the users xOutEnv function. It must be called with one more parameter than the xmk_Send function, which is the first parameter Env_ID. This parameter must be set to ENV by the user.

The macro internally uses some variables which are to be declared before the macro can be used. For example in the xOutEnv function the XMK_SEND_TMP_VARS macro must be introduced for declaring these variables.

The function is implemented as a macro in C.

Use the template in the previous subsection to see details how to use the XMK_SEND_ENV() functions.

Sending Signals to the Environment

There are several possibilities to send signals to the environment:

  1. Using simple SDL output.
    The Cmicro Kernel is involved in the output operation.
  2. Using the #EXTSIG directive in the SDL output.
    The user can define his own output operation, like writing to a register in a single in-line-assembler command.
  3. Using the #ALT directive in the SDL output.
    A variant of alternative 2.

Alternative 1 is the most SDL like alternative because it does not use non SDL constructs, like directives. This alternative should be selected, where possible because it makes the diagrams more SDL like and MSCs more readable.

Alternative 2 and 3 are probably the alternatives with higher performance.

Alternative 1 is described below. Alternative 2 and 3 are already well described in The Cmicro SDL to C Compiler.

xOutEnv()

Parameters:

In/Out: 
        xmk_T_SIGNAL        xmk_TmpSignalID

        #ifdef XMK_USE_SIGNAL_PRIORITIES
        xmk_T_PRIO          xmk_TmpPrio
        #endif

        #ifdef XMK_USED_SIGNAL_WITH_PARAMS
          xmk_T_MESS_LENGTH xmk_TmpDataLength,
          void xmk_RAM_ptr  xmk_TmpDataPtr
        #endif

        #ifdef XMK_USE_RECEIVER_PID_IN_SIGNAL
          xPID xmk_TmpReceiverPID
        #endif

Return: xmk_OPT_INT

The function xOutEnv() exists as a template in the generated module env.c.

Each time an SDL output occurs, the generated C code calls the C function xmk_Send or xmk_SendSimple. After performing some checks, and if the signal is to be sent to the environment, the C function xOutEnv() is called with all the parameters necessary to represent the signal. The parameters are explained in the following.

With the parameter xmk_TmpSignalID, the signal ID is to be specified.

With the xmk_TmpPrio parameter, the signal's priority is to be specified (if conditionally compiled). If the XMK_USE_SIGNAL_PRIORITIES is not defined, the signal priorities which are specified with #PRIO in the diagrams is just ignored. The use of signal priorities is not recommended because this violates SDL. A few bytes can be spared if signal priority is not used. See also XMK_USE_SIGNAL_PRIORITIES.

With the parameter xmk_TmpDataLength, the number of bytes of signal parameters is to be specified. The number of bytes is evaluated by using a sizeof (C struct) construct. If the signal carries no parameters, this value is set to 0.

With the xmk_TmpDataPtr parameter, a pointer to the memory area containing the parameter bytes of the signal is given. The memory area is not treated as dynamically allocated within this function. Because the function copies the parameter bytes, the caller may use any temporary memory (for example memory allocated from the C stack by declaring a C variable). This parameter should be set to NULL if no parameter bytes are to be transferred (if conditionally compiled).

The parameters xmk_TmpDataLength and xmk_TmpDataPtr are compiled conditionally. The XMK_USED_SIGNAL_WITH_PARAMS is automatically generated into the sdl_cfg.h file, from the Cmicro SDL to C Compiler. For tiny systems, if there are no SDL signals with parameters specified, this is undefined. It will reduce the amount of information which is to be transferred for each signal, with a few bytes. See also XMK_USED_SIGNAL_WITH_PARAMS.

With the last parameter xmk_TmpReceiverPID, the PID of the receiving process is to be specified (if conditionally compiled). The parameters xmk_TmpDataLength and xmk_TmpDataPtr are compiled conditionally, see also XMK_USE_RECEIVER_PID_IN_SIGNAL.

If XMK_USE_RECEIVER_PID_IN_SIGNAL is not defined, the user must implement the C function xRouteSignal which is responsible to derive the receiver from the signal ID in that case. Using xRouteSignal is recommended only if the last few bytes must be spared for transferring of signals.

Note:

There is a file called <systemname>.ifc, which is generated by the Cmicro SDL to C Compiler. It is necessary to include this file together with ml_typ.h before defining xOutEnv(). This is necessary to have access to all the objects that are generated by the Cmicro SDL to C Compiler. The user should also make sure that this file is generated, because the analyzer's make menu contains an option for this.

Evaluate the Signals's Sender

The sender of the signal can be retrieved by the global variable xRunPID of type xPID. Users should remember, that in a system with only (x,1) process declarations, this pid represents the process type of the sender. In a system in which multiple process instances of the same process type appear, this pid represents the process type plus the process instance of the sender. Probably it is required to make decisions depending on the sender of the signal. The user can evaluate the process type of the sender by using the C expression EPIDTYPE(xRunPID), i.e.:

Example 608 : Evaluating the Process Type

unsigned char ptype;
ptype = EPIDTYPE(xRunPID);

Remember also, if it is required to signal to a specific pid in the environment, this requires dynamic signalling where a process in the environment establishes communication to a process in the system or the other way around.

Checking the Signal's Receiver

Under normal circumstances it is not necessary to check the receiver in xOutEnv() as the Cmicro Kernel calls xOutEnv() only, if the environment is recognized as the signal's receiver.

Caution!

The users have to ensure that signals to the environment are consumed in the environment by returning XMK_TRUE in xOutEnv().

Signal Parameters

If the signal to be sent to the environment contains parameters, it is necessary to copy these parameters to the data area of the environment as the signal and its parameters are deleted after signal consumption.

For each signal carrying parameters, there is a typedef struct generated into the <systemname>.ifc file. Please view Example 609.

Return Values of xOutEnv()

The user must ensure that signals which are to be sent to the environment are consumed by the environment. In xOutEnv() this is done by returning the values XMK_TRUE or XMK_FALSE.

An Easy Example

Assume, for example, a process which has to send a signal with parameters to the environment. The code the user has to write into the xOutEnv()-function, looks as follows:

Example 609 : xOutEnv()

xmk_OPT_INT xOutEnv (xmk_T_SIGNAL      xmk_TmpSignalID,
xmk_T_PRIO xmk_TmpPrio,
xmk_T_MESS_LENGTH xmk_TmpDataLength,
void * xmk_TmpDataPtr,
xPID xmk_TmpReceiverPID )
{
  xmk_OPT_INT xmk_TmpResult = XMK_FALSE;

  switch (xmk_TmpSignalID)
  {
    case SDL_Signal1 :
      {
        /* BEGIN User Code */
        int temp;
        temp = (yPDef_z4_SDL_Signal1*)xmk_TmpDataPtr->Param1
        UserFunction(temp);
        /*   END User Code */
        xmk_TmpResult = XMK_TRUE; /* signal is */ 
                                 /* consumed  */
      }
      break ;
 
   case SDL_Signal2 :
      {
        /* BEGIN User Code */
        char g;
        int  k;
        g = (yPDef_z5_SDL_Signal2*)xmk_TmpDataPtr->Param1;
        k = (yPDef_z5_SDL_Signal2*)xmk_TmpDataPtr->Param2;
        UserFunction2( g, k );
        /*   END User Code */
        xmk_TmpResult = XMK_TRUE; /* signal is */ 
                                 /* consumed  */
      }
      break ;
  
   default :
        xmk_TmpResult = XMK_FALSE;/* signal is NOT */ 
                                 /* consumed   */
                                 /* and to be handled */
                                 /* by the Cmicro Kernel */
        break ;
  }
  return( xmk_TmpResult );
}

Caution!

The function xInEnv() contained in the file env.c is generated by the Targeting Expert. To secure that changes done by the user will not be lost when generating again it is allowed only to modify this file between the comments /* BEGIN User Code */ and /* END User Code */.
Furthermore it is not allowed to remove these comments or to add similar ones at other places.

Inter-Processor-Communication

Note:

If inter-processor-communication is to be performed, the user has to define a unique protocol between the communicating processors. In small applications with a restricted range, it might be enough to copy C structures, but usually this causes problems when it comes to redesigning the hardware.

Closing the Environment / the Interface to the Environment

xCloseEnv()

Parameters:

In/Out: -no-
Return: -no-

There is one C function called xCloseEnv() available as a template in the generated C module env.c.

The user should fill this function out appropriately thus realizing disconnection from the environment (drivers, interrupt service routines and so on). Disconnection can make sense if a re-initialization or a software reset is to be implemented.

The SDL_Halt function is mapped to xCloseEnv() in Cmicro.

SDL System Time Implementation

Included in the Cmicro Kernel, there are some template functions for the implementation of SDL system time. All these functions are contained in the module mk_stim. The functions xmk_NOW() or xmk_SetTime() must be implemented newly if a new method for accessing the hardware system time is to be implemented. In many cases, the standard C library function time() is available, which is used in most of the C compiler adaptations that are already been made.

It is necessary though to implement a function which makes the variable SystemTime topical. This will be an interrupt service routine in most cases.

Please view Defining the SDL System Time Functions in mk_stim.c.

Getting the Receiver of a Signal - Using xRouteSignal

Parameters:

In/Out: xmk_T_SIGNAL sig
Return: xPID

The user can remove the receiver's xPID from the signal structure by resetting the flag XMK_USE_RECEIVER_PID_IN_SIGNAL. In this case, the function xRouteSignal() has to be filled as the Cmicro Kernel needs to know which process likes to receive the current signal.

Example 610 : Function xRouteSignal()

/* 
** the <p> below stands for the automatically generated prefix 
*/

xPID xRouteSignal  ( xmk_T_SIGNAL sig )
{
   /*
   ** Please insert appropriate code here to map
   ** Signal ID's to Process - Type - ID's
   ** (XPTID_ProcessName in generated code).
   ** Keep in mind that this function might be 
   ** called from within a critical path.
   ** Include <systemname>.ifc to get signal names
   ** and process' XPTID
   */
   switch (sig)
   {
    /*
    **  S D L   T i m e r s ...
    */
    case SDL_Timer1: return (XPTID_<p>_ProcessName_A)
                     break;
    case SDL_Timer2: return (XPTID_<p>_ProcessName_B)
                     break;
    case SDL_Timer3: return (XPTID_<p>_ProcessName_A)
                     break;
    case SDL_TimerN: return (XPTID_<p>_ProcessName_C)
                     break;

    /*
    **  O r d i n a r y  S D L   S i g n a l s ...
    */
    case SDL_Signal1: return (XPTID_<p>_ProcessName_B)
                      break;
    case SDL_Signal2: return (XPTID_<p>_ProcessName_A)
                      break;
    case SDL_Signal3: return (XPTID_<p>_ProcessName_A)
                      break;
             ......

    case SDL_SignalN : return (XPTID_<p>_ProcessName_C)
                      break;

    default: ErrorHandler (ERR_N_NO_RCV); 
             return (xNULLPID)
             break;
   }
}

Dynamic Memory Allocation

General

Dynamic memory allocation in real life always introduces problems, which are:

Normally, Cmicro tries to prevent any use of dynamic memory allocation, but there are the following exceptions, in which this is impossible:

There are at least two possibilities to implement dynamic memory allocation namely:

When it comes to targeting, the user decides upon the dynamic memory allocation manager. In the following, the both possibilities are explained.

Dynamic Memory Allocation Functions - Compiler or Operating System

If the C compiler, that the user is using in the target environment, provides dynamic memory allocation functions, it is possible to use these functions. A few steps must be carried out to include the dynamic memory allocation functions of the C compiler or operating system, which are:

Dynamic Memory Allocation Functions - Cmicro

Below the Cmicro kernel directory there is a C module ml_mem.c that implements a dynamic memory allocator. The C module ml_mem.c can be used for managing memory dynamically for SDL systems, but it is not forbidden to use this module within handwritten C code also.

The module cannot be used if partitioning is to be used. In that case compilation errors will occur. Please refer to Dynamic Memory Allocation for an explanation which parts in SDL are to be dynamically allocated. The module provides C functions for initialization, allocation, de-allocation, and getting some information about the current memory status.

There is only one memory pool. The memory pool is to be declared by the user and initialized with the C function xmk_MemInit before the memory pool can be used. Allocations may be performed by calling xmk_Malloc() or xmk_Calloc(). An allocated block is de-allocated again by calling xmk_Free(). So far, the principle behavior is the same as the usual malloc(), calloc() and free() functions from compilers. But the memory pool can probably be cleaned with a Cmicro specific function. There are additional functions which can be used to query the amount of free or occupied space.

Before the memory management functions of Cmicro can be used, a few adaptations are to be made which are explained in the following.

Adaptations That Are to Be Made

Some adaptations are to be made by the user, which are necessary to include the right functions, scale buffers and memory management and take care for general adjusting like alignment of the CPU.

xmk_CleanPool()

Parameters:

In/Out: -no-
Return: size_t

This C function returns the amount of occupied memory. It is available only if XMK_USE_SDL_MEM and XMK_SYSTEM_INFO are set.

xmk_GetOccupiedMem()

Parameters:

In/Out: -no-
Return: size_t

This C function returns the net amount of occupied memory. It is available only if XMK_USE_SDL_MEM and XMK_SYSTEM_INFO are set.

xmk_GetFreeMem()

Parameters:

In/Out: -no-
Return: size_t

Returns the amount of free memory in sum, which means that the overhead from each block is included. It is available only if XMK_USE_SDL_MEM and XMK_SYSTEM_INFO are set.

xmk_EvaluateExp2Size()

Parameters:

In/Out: size_t
Return: size_t

This function is either used from Cmicro's dynamic memory allocation functions xmk_Malloc() and xmk_Calloc() or it may be used directly from the user.

It is available only if XMK_USE_MIN_BLKSIZE is set.

The function is declared as:

size_t xmk_EvaluateExp2Size ( size_t GivenLength )

The function evaluates from the given length a length value, which is in any case a 2 exp N value. This is used to reduce the risk of memory leaks that occur in dynamic memory management systems. It may be used for the memory functions of this module but also for the memory functions of an operating system or C compiler. If the minimum block size is in any case greater than the greatest block that is requested in the target system, then there is no risk for memory leaks. The return result is either the minimum specified with XMK_MEM_MIN_BLKSIZE, but might be also one of the following values:

64,128,256,512,1024,2048,4096,8192,16384,32768,65536

The ?Memory Command

The SDL Target Tester offers a command that allows the user to inspect the status of the dynamic memory. Unfortunately this command can be used only, if the dynamic memory management from Cmicro is used (by setting the XMK_USE_SDL_MEM flag in the Targeting Expert).

The command allows the user to check the following:

The command presents the following output to the user:

M-STATE:Memory pool size incl.overhead     =4096
M-STATE:Current memory fill                =136
M-STATE:Current amount of blocks in pool   =2
M-STATE:Peak hold: Amount of blocks        =29
M-STATE:Peak hold: Largest block           =2048
M-STATE:Overhead per block (in bytes)      =20
M-STATE:Minimum block size                 =0
M-STATE:Memory pool address (hex)          =28478
M-STATE:(Probably there are memory leaks)

The command is available only if XMK_USE_SDL_MEM and XMK_ADD_PROFILE are set.

User Defined Actions for System Errors - the ErrorHandler

Parameters:

In/Out: int ErrorNo
Return: void

Errors, warnings and information can be generated and detected in many places and situations during the lifetime of an SDL system. By fully utilizing the Analyzer, several dynamic error sources can be eliminated at the design stage of development.

Some errors or warnings go undetected by the Analyzer, for example resource errors or real time errors such as memory, performance, or illogical use of SDL.

These errors and warnings are detectable by the Cmicro Kernel and the SDL Target Tester. For a complete list of errors, warnings and information, please view the following subsection List of Dynamic Errors and Warnings.

As a general rule, for each error and warning there should be an appropriate reaction in the function ErrorHandler() in the mk_user module.

The ErrorHandler() is, as a default implementation, implemented like this:

In the case of a warning message, either:

In the case of an error message, either:

For more explanations on these flags, please view Reactions on Warnings and Reaction on Errors. If printf is used, the C module ml_mon.c below the cmicro/kernel directory must be compiled also.

Errors are numbered easily by an integer value. If the user's target allows the use of printf, then use the C function xmk_err_text contained in the ml_err module. It is easier to specify error handling in this module rather than directly modifying the ErrorHandler function.

Example 611 : Default implementation of ErrorHandler()

void ErrorHandler ( int ErrorNo ) 
{
  ...
  ...
  ...

 ErrorClass = xmk_GetErrorClass (xmk_TmpErrorNumber);
  #ifdef XMK_WARN_ACTION_HANGUP
    if (ErrorClass==XMK_WARNING_CLASS)
      while (1);
  #endif /* ... XMK_WARN_ACTION_HANGUP */

  #ifdef XMK_ERR_ACTION_HANGUP
    if (ErrorClass==XMK_FATAL_CLASS)
      while (1);
  #endif /* ... XMK_ERR_ACTION_HANGUP */

  #ifdef XMK_WARN_ACTION_PRINTF
    if (ErrorClass==XMK_WARNING_CLASS)
      xmk_MonError (stderr, xmk_TmpErrorNumber);
  #endif /* ... XMK_WARN_ACTION_HANGUP */

  #ifdef XMK_ERR_ACTION_PRINTF
    if (ErrorClass==XMK_FATAL_CLASS)
      xmk_MonError (stderr, xmk_TmpErrorNumber);
  #endif /* ... XMK_ERR_ACTION_HANGUP */

  #ifdef XMK_WARN_ACTION_USER
    if (ErrorClass==XMK_WARNING_CLASS)
      XMK_WARN_USER_FUNCTION( xmk_TmpErrorNumber );
  #endif /* ... XMK_WARN_ACTION_USER */

  #ifdef XMK_ERR_ACTION_USER
    if (ErrorClass==XMK_FATAL_CLASS)
      XMK_ERR_USER_FUNCTION( xmk_TmpErrorNumber );
  #endif /* ... XMK_ERR_ACTION_USER */

  ...
  ...
  ...

} /* END OF SAMPLE */

Example 612 : ErrorHandler()

void ErrorHandler ( int ErrorNo ) 
{
  /* The user could implement the 3 functions
** fatalerror, warning, and information
*/
  switch (ErrNo)
  {
    case  ERR_N_UNKNOWN
          fatalerror(ErrNo); 
          break;

    case  .....
.....
          break;

    default: warning(ERR_N_UNKNOWN); break;
  } 
} /* END OF SAMPLE */

List of Dynamic Errors and Warnings

Cmicro Kernel Errors

SDL Target Tester Errors


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