![]() |
![]() |
![]() |
![]() |
![]() |
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:
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_PRINTFin 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.
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.
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:
- Polling external events.
This is done by the C function xInEnv(), which is called by the Cmicro Kernel after each transition.- 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.
xInEnv()
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.
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_VARSstatic 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 */
XMK_SEND_ENV()
In/Out: xPID Env_IDxmk_T_SIGNAL sig#ifdef XMK_USE_SIGNAL_PRIORITIESxmk_T_PRIO prio#endif#ifdef XMK_USED_SIGNAL_WITH_PARAMSxmk_T_MESS_LENGTH data_len,void xmk_RAM_ptr p_data#endif#ifdef XMK_USE_RECEIVER_PID_IN_SIGNALxPID Receiver#endifReturn: -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:
- Using simple SDL output.
The Cmicro Kernel is involved in the output operation.- 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.- 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()
In/Out:xmk_T_SIGNAL xmk_TmpSignalID#ifdef XMK_USE_SIGNAL_PRIORITIESxmk_T_PRIO xmk_TmpPrio#endif#ifdef XMK_USED_SIGNAL_WITH_PARAMSxmk_T_MESS_LENGTH xmk_TmpDataLength,void xmk_RAM_ptr xmk_TmpDataPtr#endif#ifdef XMK_USE_RECEIVER_PID_IN_SIGNALxPID xmk_TmpReceiverPID#endifReturn: xmk_OPT_INTThe 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.
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.
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:
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->Param1UserFunction(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 );}
Inter-Processor-Communication
Closing the Environment / the Interface to the Environment
xCloseEnv()
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
In/Out: xmk_T_SIGNAL sigReturn: xPIDThe 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:
- The memory occupation cannot be evaluated by the user, so that it is impossible to configure the dynamic memory. If all objects are allocated statically and if the memory occupation exceeds the available memory, this results in errors during compilation/linking, or at least a memory map file can be viewed.
- If dynamic memory allocation is used, then, after the program has executed for a time, usually memory leaks are the result. Memory leaks are fatal because there might be enough memory, but it is even impossible to allocate one more block.
- If there is no more free dynamic memory available, then it is up to the user to decide how to continue in the program. In any case, the program should be terminated, started again or any similar reaction is to be programmed.
Normally, Cmicro tries to prevent any use of dynamic memory allocation, but there are the following exceptions, in which this is impossible:
- When a signal with too many parameters is to be sent to another process. See Signals, Timers and Start-Up Signals.
- When an SDL sort is used requiring dynamic memory management, like the charstring sort.
- If the SDL Target Tester is used, because there is dynamic memory allocation in the start-up phase and for each transmit buffer.
There are at least two possibilities to implement dynamic memory allocation namely:
- The dynamic memory management from the C Compiler or operating system can be used.
- The dynamic memory management from Cmicro can be used.
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:
- The user must introduce his own C compiler section, please refer to the subsection Introducing a new C Compiler.
- In the new C compiler section, the correct header files must be introduced with #include. The user should refer to the manuals of the C compiler or operating system.
- The SDL Target Tester, Cmicro Library and Cmicro Kernel always allocate dynamic memory by using the functions in the file mk_cpu.c.
- The file mk_cpu.c below the Cmicro template directory must be copied into the user's project directory. Any modifications should be performed on the private copy of mk_cpu.c.
- The mk_cpu.c file contains two C functions called xAlloc() and xFree(). Within these functions, the user should call the appropriate dynamic memory allocation functions of the C compiler or operating system.
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.
- For general use of the Cmicro memory management functions the user should set the flag XMK_USE_SDL_MEM in ml_mcf.h with the help of the Targeting Expert. This will make the basic memory allocation functions available. The ml_mem.c module must of course be compiled an linked together with the application.
- Adjust the alignment that the CPU is using. There is a macro definition in ml_mem.c called CPU_WORD_SIZE. The right setting of this macro is basically important for making the dynamic memory allocation functions do work. With this flag, it is possible to define the word size of the target CPU. The value is predefined in ml_mem.c but it could be the case that the predefined value is inappropriate for the target system. If the CPU_WORD_SIZE value must be redefined, this could be done in ml_mcf.h in the user's section. The predefined value for UNIX compilers is 8, the predefined value for ARM_THUMB C compiler 4, otherwise a default value of 1 (no alignment) is used.
- Here is a recommendation: The user should use an alignment of 4 (32 Bit) if it is not sure what type of alignment the C compiler / CPU produces. This will work for most cases, but of course probably not if the CPU is 64 Bit CPU. For small systems, this might not be appropriate, because there is an extra overhead of 3 bytes per allocated block. For a CPU like 8051 and derivatives a CPU_WORD_SIZE of 1 is appropriate.
- It is possible to introduce a minimum block size per each allocated block. This decreases the risk of getting memory leaks after a while because blocks of the same size can be put together again. If the mechanism of a minimum block size is to be used, then the define XMK_USE_MIN_BLKSIZE is to be used. With the define XMK_MEM_MIN_BLKSIZE the user may define the minimum block size per each allocated block. If the XMK_MEM_MIN_BLKSIZE is not defined from the user, a minimum block size of 64 is predefined.
- The ml_mem.c module contains profiler that keeps track on how many blocks are allocated, how much memory is free and furthermore. The user must define XMK_ADD_PROFILE in order to get the complete functionality. If the SDL Target Tester is used, the flag is automatically predefined.
xmk_CleanPool()
In/Out: -no-Return: size_tThis 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()
In/Out: -no-Return: size_tThis 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()
In/Out: -no-Return: size_tReturns 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()
In/Out: size_tReturn: size_tThis 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.
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,65536The ?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:
- Is the dynamic memory correctly initialized after system start-up?
- How is the dynamic memory pool configured?
- At any time during SDL target system execution:
The command presents the following output to the user:
M-STATE:Memory pool size incl.overhead =4096M-STATE:Current memory fill =136M-STATE:Current amount of blocks in pool =2M-STATE:Peak hold: Amount of blocks =29M-STATE:Peak hold: Largest block =2048M-STATE:Overhead per block (in bytes) =20M-STATE:Minimum block size =0M-STATE:Memory pool address (hex) =28478M-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
In/Out: int ErrorNoReturn: voidErrors, 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:
- The actions defined via the flag XMK_WARN_ACTION_HANG_UP are carried out (see Reactions on Warnings).
- The actions defined via the flag XMK_WARN_ACTION_PRINTF are carried out.
- The actions defined via the flag XMK_WARN_ACTION_USER and XMK_WARN_USER_FUNCTION are carried out.
In the case of an error message, either:
- The actions defined via the flag XMK_ERR_ACTION_HANG_UP are carried out (see Reaction on Errors)
- The actions defined via the flag XMK_ERR_ACTION_PRINTF are carried out.
- The actions defined via the flag XMK_ERR_ACTION_USER and XMK_ERR_USER_FUNCTION are carried out.
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_HANGUPif (ErrorClass==XMK_WARNING_CLASS)while (1);#endif /* ... XMK_WARN_ACTION_HANGUP */#ifdef XMK_ERR_ACTION_HANGUPif (ErrorClass==XMK_FATAL_CLASS)while (1);#endif /* ... XMK_ERR_ACTION_HANGUP */#ifdef XMK_WARN_ACTION_PRINTFif (ErrorClass==XMK_WARNING_CLASS)xmk_MonError (stderr, xmk_TmpErrorNumber);#endif /* ... XMK_WARN_ACTION_HANGUP */#ifdef XMK_ERR_ACTION_PRINTFif (ErrorClass==XMK_FATAL_CLASS)xmk_MonError (stderr, xmk_TmpErrorNumber);#endif /* ... XMK_ERR_ACTION_HANGUP */#ifdef XMK_WARN_ACTION_USERif (ErrorClass==XMK_WARNING_CLASS)XMK_WARN_USER_FUNCTION( xmk_TmpErrorNumber );#endif /* ... XMK_WARN_ACTION_USER */#ifdef XMK_ERR_ACTION_USERif (ErrorClass==XMK_FATAL_CLASS)XMK_ERR_USER_FUNCTION( xmk_TmpErrorNumber );#endif /* ... XMK_ERR_ACTION_USER */.........} /* END OF SAMPLE */void ErrorHandler ( int ErrorNo ){/* The user could implement the 3 functions
** fatalerror, warning, and information
*/switch (ErrNo){case ERR_N_UNKNOWNfatalerror(ErrNo);break;case .....
.....break;default: warning(ERR_N_UNKNOWN); break;}} /* END OF SAMPLE */List of Dynamic Errors and Warnings
Cmicro Kernel Errors
- ERR_N_CREATE_NO_MEM
- This error can happen in the case of using dynamic process creation. When a parent process tries to create another process, the Cmicro Kernel tries to allocate an entry in the queue for the insertion of an internal create signal.
- The error occurs when full queue capacity has been reached.
- Help: Change the size of the signal queue by modifying the macro XMK_MAX_SIGNALS in ml_mcf.h.
- ERR_N_CREATE_INSTANCE
- This error happens if there is no dormant instance of a process type which can be (re)used. The Cmicro Package uses fixed upper process instance limits (x, N), where N is to be specified as an integer value. In the C code, all the data of one process instance is represented by one element of an array of the size N.
- The error occurs if all instances (i.e. all array elements), of this process type are currently active and the parent tries to create another instance of that type.
- ERR_N_SDL_DISCARD
- ERR_N_DIVIDE_BY_ZERO
- ERR_N_NO_FREE_SIGNAL
- It is impossible to allocate one more signal instance from the static memory pool. Depending on how the user has defined the signal handling (XMK_USE_STATIC_QUEUE_ONLY and XMK_USE_STATIC_AND_DYNAMIC_QUEUE), this must be treated either as a warning or as a fatal error.
- It has to be treated as a fatal error, when the macro XMK_USE_STATIC_QUEUE_ONLY is set.
- It can be treated as a minor warning, when the macro XMK_USE_STATIC_AND_DYNAMIC_QUEUE is set.
- The output operation fails, if it is impossible to allocate one more signal.
- Help: Change the size of the signal queue by modifying the macro XMK_MAX_SIGNALS in ml_mcf.h or change the size of predefined dynamic memory pool (the memory pool, that is used when the xAlloc C function is called).
- ERR_N_PARAMETER_MEM_ALLOC
- The output operation fails as a signal with parameters is to be sent but not enough free memory is available for allocation of the signal parameters.
- If the signal parameter's length is greater than the value of XMK_MSG_BORDER_LEN (see Compilation Flags) the parameters are inserted in a memory area which has to be allocated. This allocation fails because there is no more memory available.
- Help: If using the Cmicro Library's memory functions (flag XMK_USE_SDL_MEM): The size of the memory for allocation can be increased by incrementing the value XMK_MAX_MALLOC_SIZE.
- ERR_N_SYSTEM_SIGNAL
- This error can only happen, if a non specified system signal is sent. Internally, some signals are predefined as system signals. System signals are given priority treatment. For example, for the dynamic process creation, there is a system signal called XMK_CREATE_SIGNALID which is automatically defined in ml_mcf.h according to the setting of XMK_USE_MORE_THAN_250_SIGNALS.
- To prevent this error situation happening it is strongly recommended not to send an SDL signal with equal or higher priority than that of a system signal (please see the subsection Scheduling).
- ERR_N_NO_CONT_PRIO
- This error occurs when process priorities are not numbered according to the rules of the preemptive Cmicro Kernel. The numbering must begin from zero incremented consecutively to an upper limit. All numbers between zero and the upper limit-1 are to be used within a #PRIO directive, no number may be omitted. (See MAX_PRIO_LEVELS and xDefaultPrioProcess in section Preemption.
- ERR_N_NO_COR_PRIO
- When the preemptive Cmicro Kernel is selected, the macro MAX_PRIO_LEVELS has to be set correct. As described in MAX_PRIO_LEVELS in section Preemption, this macro has to contain the amount of process priority levels.
- ERR_N_xRouteSignal
- The function xRouteSignal, which is to be filled by the user when signals do not contain a receiver pid, detects an error or was not able to handle the current signal which is to be routed. See Bare Integration.
- ERR_N_NO_REC_AVAIL
- If the user is using implicit addressing (output without to) and there are several possible receivers of one type, the Cmicro Kernel tries to assign one of them to this signal. This assignment may fail if there is no possible receiver. If there is more than one, then the first one found will be used in the output of the C function xmk_Send*.
- ERR_N_NO_FREE_TIMER
- The error occurs when an SDL process tries to start an instance of a timer and either the timer is unknown or there is no memory available to start a timer instance. To eliminate the first source of error check the SDL compilation. For the second case increase the memory assigned to timers by increasing the value of XMK_TIMERPRIO.
- ERR_N_PID_INDEX
- ERR_N_SEND_TO_NULLPID
- An SDL application tries to send to a NULL - PID. This case normally cannot arise as the Analyzer performs appropriate checks in the dynamic analyses pass. If it occurs, it is most probably that either something is wrong with the environment signalling or possibly with initialization of pid variables.
- ERR_N_TRANS_TIME
- The maximum execution time for one SDL transition was exceeded. This error can only happen if no preemption is used and if the administration of the transition-execution-time is switched on. See XMK_USE_CHECK_TRANS_TIME.
- ERR_N_xOutEnv
- The C function xOutEnv() does not handle all necessary signals. It should handle all signals which are sent to the environment. Please view Return Values of xOutEnv().
- ERR_N_INIT_SDL_MEM
- If the Cmicro Library's memory functions are used, (XMK_USE_SDL_MEM is defined) the memory for alloc() and malloc() has to be initialized. This error occurs if a malloc() takes place before the memory is initialized. See ml_mem.c
- ERR_N_SDL_DECISION_ELSE
- ERR_N_SDL_RANGE
- ERR_N_NO_RCV
- If the flag XMK_USE_RECEIVER_PID_IN_SIGNAL is undefined the function xRouteSignal() has to be filled by the user. See Getting the Receiver of a Signal - Using xRouteSignal. This error code means that there is no receiver defined for the current signal.
- ERR_N_SDL_IMPLICIT_CONSUMPTION
- ERR_N_PREDEFINED_OPERATOR_CALL
- An error occurred in the call to one of the predefined operators. Unfortunately it is not possible to find out what the reason for this error is without either simulating the system or using the SDL Target Tester or any trace possibility introduced by the user. The error message occurs if a range in the memory is crossed.
- ERR_N_INIT_QUEUE
- The SDL signal queue is not correctly initialized. The error occurs if the user has forgotten to call the C function xmk_InitQueue(). This function must be called before xmk_InitSDL() may be called.
- Please view the section Implementation of Main Function.
- ERR_N_MEM_PARAM
- ERR_N_MEM_NO_FREE
- There is no free block in the memory pool of the Cmicro Memory Management (see Exported from ml_mem.c). This error can only be detected if the Cmicro Memory Management is used (see the flag XMK_USE_SDL_MEM).
- The size of the dynamic memory, i.e. the amount of blocks available can be modified by modifying the flag XMK_MAX_MALLOC_SIZE
- ERR_N_MEM_ILLMBLOCK
- A call to the xmk_Free() function of the Cmicro Memory Management (see the file Exported from ml_mem.c) occurred and the given block is an invalid block.
- This error can only be detected if the Cmicro Memory Management is used (see the flag XMK_USE_SDL_MEM).
- ERR_N_NO_FREE_SIGNAL_DYN
- This error is detected when a new signal is to be allocated dynamically and there is no more free memory available. The Cmicro Kernel starts to create signal instances by using memory allocation in the case that the define XMK_USE_STATIC_AND_DYNAMIC_QUEUE is defined and there is no available signal instance in the predefined pool of static signal instances (see XMK_MAX_SIGNALS).
- ERR_N_NO_FREE_TIMER_DYN
- This error is detected when memory for a new timer instance is to be allocated dynamically and there is no more free memory available. The error only occurs if timers with parameters are used. The Cmicro Kernel starts to create timer instances by using memory allocation in the case that timers with parameters are used in SDL (XMK_USED_TIMER_WITH_PARAMS is defined in sdl_cfg.h) and the amount of statically predefined timer instances (XMK_MAX_TIMER_USER defined with Targeting Expert) is being reached.
- ERR_N_NULL_POINTER_VALUE_USED
- ERR_N_UNDEFINED_ERROR
SDL Target Tester Errors
- ERR_N_INDEX_SIGNAL
- ERR_N_ILLEGAL_CMD
- ERR_N_TESTER_MESSAGE
- ERR_N_LINK_SYNC
- ERR_N_LINK_DEST_BUFFER
- ERR_N_LINK_ENC_LENGTH
- ERR_N_LINK_ENC_MEMORY
- ERR_N_LINK_NOT_IMPL
- ERR_N_DATA_LINK
- ERR_N_DECODE_METHOD
- ERR_N_RING_WRITE_LENGTH
- ERR_N_TRACE_OUTPUT
- ERR_N_RECORD_OUTPUT
- ERR_N_RECORD_MAX_EXCEEDED
- ERR_N_RECORD_STATE
- ERR_N_RECORD_CANNOT_CONT
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |