Tau3.4 -> Tau 3.5

New and Changed Functionality

Cmicro Tester

• Cmicro Tester now supports OO, as the Cmicro Codegenerator does.
• As Cmicro Codegenerator now does support timers with parameters,  Cmicro Tester implements possibilities to enter and display timer parameters. Hint : Timers with parameters are restrictively implemented in the way that it is possible only to specify one integer parameter.

Known Limitations

Code Generator

• The .ifc file contains #define definitions for the kind of SDL units for which this is possible. All the C Codegenerators follow this principle. This can, depending on the C Compiler, lead to compilation errors/warnings or to runtime errors in some cases. The following example shows how the problem may occur:

The both literals 'green' and 'blue' will then be created like this :
/* For newtype x */ #define green 0 #define blue 1 /* For newtype y */ #define blue 0 #define green 1

The C Compiler then usually complains that the macros 'blue' and 'green' are redefined with a different value. Some C compilers will continue in any case and produce an executable. Runtime errors are the consequence on this, because when 'green' and 'blue' are used together with the first newtype x, the literal values from the second newtype y are used by the C compiler. In order to avoid this problem, the users should manually add a prefix for each literal, like this:
literals x_green, x_blue; endnewtype x; newtype y literals y_blue, y_green; endnewtype y;

The 'green' and 'blue' example is not a good one, because it is possible to avoid the problem by using the inherit construct. The literals from the newtype x could be inherited into the newtype y. More problems will occur if several entity classes are mixed up from the C compiler, like if there would for example a signal called "green", which is also created as a #define. The user is strongly recommended to avoid naming conflicts in the .ifc file by manually adding prefixes.

Cmicro Generator and Library

• The names of processes in different blocks must not be the same. The reason for this restriction is the missing symbol tree in Cmicro. It is impossible to address for example two processes with the same name in the same C module (in the SDL environment). As a work around, the user should always spend different names for the different processes in the system. This can easily be reached by adding a prefix to each process name.
• The predefined generators own and oref and the new algorithmic extensions (loops) may cause problems together with Cmicro because these have not been tested extensively.
• Predefined sort charstring and predefined ASN.1 sorts that use the charstring type internally: There might be cases in which dynamically allocated memory is not deallocated again. These kind of problem occurs only, if a charstring value is used in the return value from a procedure (by using the returns construct). It does not matter if the charstring value is returned directly or if the charstring value is enclosed by a newtype struct value.
• Predefined sort carray: There is a restriction in all the C Codegenerators (CBasic/CAdvanced/Cmicro) : It is impossible to return variables of the predefined sort carray from an SDL procedure because the ANSI C language cannot handle this. It is however possible to enclose the carray into a newtype struct value as a workaround.
• Sometimes the Cmicro C Codegenerator does not create error messages correctly, e.g. the messages like: "Feature of SDL not implemented: <detailled message>" Instead of having the error in the Organizer's Log Window, a problem will appear during compilation of the generated C Code. The generated C Code contains an "*****Error*****" String at the place where a feature would have to be, but cannot be code-generated.
• The order of trace of procedure call and procedure's statements is wrong in the SDL editor trace. This means that the SDL editor trace first goes down into the procedure, and the procedure call symbol is high-lighted after returning from it. The reason for this is the wrong order of statements in generated C code :

• The C macro XMK_C_TIME is not generated in the case of file separation. This may lead to problems because the macro is used to check the consistancy between all the generated files. Inconsistancies may then occur if a user copies files and does not update every generated file accordingly.
• The specific requirements for the 8051 C compilers are not suffiently fulfilled yet, because the test is difficult. The background is the CPU's Harvard architecture which requires to store variables in a different way as usual. The Cmicro C Codegenerator tries to cope with this by adding the macros xmk_RAM/ROM_ptr and XCONST, but there are still problems with it.
• If no timers are in the system, but the "now" expression is used, a compilation error in the generated C code will occur. The reason is that the xmk_NOW function in the user's template C module mk_stim.c is not compiled then. It is possible to remove the scaling with XMK_USED_TIME around that C function.
• If the user implemented the "now" expression without care, it might come to problems when a time value is stored, and later compared with the current "now" value. The user must fill out the xmk_NOW C function from the mk_stim.c module, which is deliverd as a template file. The following example will explain why problems may occur:

If the xmk_NOW C function is implemented in a way, so that an overrun in the system time can occur, then the behaviour of the system depends on whether an overrun happens or not. The background behind this is that the Cmicro Kernel cannot update SDL variables of the predefined sort time and duration, which it would have to do if an overrun in the system time occurs. Ordinary SDL timers are handled correctly because the Cmicro Kernel checks the system time against a possible overrun and corrects active timers in the background.

Cmicro Tester

• The order of trace of procedure call and procedure's statements is wrong in the SDL editor trace. This means that the SDL editor trace first goes down into the procedure, and the procedure call symbol is high-lighted after returning from it.
• When the target system is suspended (by sending the suspend command), any signal that is sent to the target will be discarded.
• When, with the Output-PAR/NPAR command, the user wants to send a signal to the target system, he is presented a list with all the signals that are defined in the system. The user should keep in mind that he always has to address the right process instance when specifing the parameters of the Cmicro Tester's output command.
• Several compilers, e.g the Tasking 80166, are giving wrong information about the message length. This error is detected by the Cmicro Tester and displayed once. The trace of SDL events will be correct as only the CRC check is not involved in the following communication.
• If the user wants to access timers, he has to enter a timer value in every case. If the timer is zero,  the user has to enter:  '0' .

Problems when an Application Is Created with Cmicro

• Not all possible errors are checked by the Bodybuilder. In most cases a compilation error is the result the user will get from a wrong configuration. The Bodybuilder's online help will support the user to configure correctly.
• In the generated C code, there is the warning: "Large integer implicitely truncated to unsigned type" at all those places, where an SDL output is code-generated. The Cmicro Library is able to handle a maximum of 255 bytes parameters in a signal's output. This restriction was introduced to better support small embedded systems for efficiency reasons.The warning occurs because the output function of the Cmicro Library (xmk_Send) does expect an unsigned char type, but is given an int value. The reason for this is, that the sizeof() operator in C returns an int value.
• If the user tries to #include "systemname.ifc" file in ml_typ,h, or for some other reason, there may be further naming conflicts, for example during preprocessing :

The reason for the error above (and other behavior that is impossible to foresee) was that there was a signal named "SIn". This will be generated as a #define SIn 0. In the ml_pred.c file, there is a variable called SIn (in the macro yAss_SDL_Object_Identifier. The C preprocessor then replaces the variable name with the #define value of SIn, which ended up in the parse error above.

In order to avoid that, the user should never include codegenerated header or .ifc files in any part of the Cmicro Library itself or in the generated C code. The .ifc file should only be included in the SDL environment files (like env.c and/or mk_user.c).

• In the generated C code, the following warning is repeated per each variable that is unused:

These warnings in generated C code are not that easy to remove because it is difficult to calculate this during codegeneration. These warnings should not produce real problems (except that it is sometimes impossible to read the large C compiler output). The following variables are sometimes referred:
warning: unused variable `yOutputSignal' warning: unused variable `yVarP' warning: unused variable `ySVarP'

The same warning as above is thrown from C compilers when signals without parameters are used.

This warning is accepted in the mk_outp.c module:
mk_outp.c:warning: unused variable `P_Parameter'

A similar warning (accepted also) is within mk_stim.c:
mk_stim.c:warning: `SystemTime' defined but not used

• Warnings like : "Control reaches end of non-void function" - As the codegenerator basically creates a switch() construct in C, and every return from the process activity description function (PAD function) occurs in all the case branches of that switch, the PAD function contains no return statement after the switch. This is the reason why some C compilers complain that the "Control reaches end of non-void function". This is an accepted warning. It is possible for the user to remove that warning in the ml_typ.h or user_cc.h file by modifying the END_PAD macro such like:

• Warnings : missing braces around initializer for `xSTATE_INDEX_zyyyy_xxxxxxx[0]' - This is an accepted error so far, because each known C compiler handles this correct. The reason why the Codegenerator generates like this is that is still should be conform to not just only ANSI C, but also Kernighan & Ritchie C.
• Some C compilers fail in preprocessing of very long macro definitions (like all the C Compilers available on the market for the 8051 family of CPU's). Such long macro calls occur in the predefined generators (String, Poweret,Bag). - If the C Compiler (in more detail : the C preprocessor) complains about a macro definition that is too long, or produces erroneous output, it is not possible to use these kind of generators. The macro "X_LONG_MACROS" should be set with the Bodybuilder. (This is a restriction common for all C Codegenerators.)
• It could also be impossible for some C compilers for embedded systems to compile recursive macro calls. Recursive macro calls appear for SDL statements like for example :

If such a problem occurs, it is strongly recommended to avoid such statements for example with the following work around :
tmp:=b and c, a := tmp and d;

• When it comes to target applications, the user always has to specify how memory is allocated (see C module mk_cpu.c in the template directory) and what should happen if there is no more memory available. As the template C files does not know what the user wants to do, there is a C macro called "NO_MORE_MEMORY" that the user must define. Any reaction on such a fatal error might be appropriate, like "Hang up the program", or "Reset", or "Print out an error message". Printing out error messages may however fail as well, if the print function allocates memory.
• Indextable / Transitiontable overflow - There are runtime errors if too many signals/ transitions are defined. This is solved in the library because there are additional configuration possibilities with the Bodybuilder. The problem occurs when the following happens: Too many transition pathes in at least one SDL process or many states in at least one SDL process or a combination of both. In the Bodybuilder, there is a flag called XMK_USE_HUGE_TRANSITIONTABLES that, if it is set, will solve the problem.
• If there are too many signals specified in the system, there will be a compilation error in the ml_typ.h file, because an error check in the ml_typ.h file will become negative. As the Cmicro Library uses a char value in C to represent signal IDs, and as some values are reserved internally, the maximum amount of signals that Cmicro can handle is predefined to 250. If more than 250 signals are declared in SDL (the user can see this by investigating the XMK_HIGHEST_SIGNAL_NR value in the sdl_cfg.h file), it is possible to define the macro XMK_USE_MORE_THAN_250_SIGNALS with the help of the Bodybuilder.
• If there are too many states defined in a process, this will lead to problems. Cmicro is restricted to 250 states in a process.
• The default values for variables are not set in a procedure when XMK_USE_KERNEL_INIT is defined. - This is a problem which cannot be solved easily. These are the possible work arounds : a) Do not define XMK_USE_KERNEL_INIT, or b) do not use default values for variables in a procedure, e.g. this is forbidden in a procedure (in a process it does work very well).
• There are some restrictions in sizes of C objects. The user should be aware that there is a risk to failure in configuration of the target system. Especially the maximum amount of signal parameters bytes can be miss-configured and will lead to fatal errors.
• The C define XCONST is not correct for all C compilers that are in the list of available compilers. The problem is that the semantics of the keyword "const" in C is not the same for all of the C compilers.

Use of ADTs from SDT in Cmicro

If something is missing in the list below (for some unknown reason), it should be considered as "Not possible together with Cmicro".

• ctypes.sdl - This package can be used together with Cmicro with the following restriction. There are two operators that are excluded when Cmicro C Code is compiled. The operators are "CStar2CString" and "CharStar". The reason for this is that with Cmicro it is possible to define an array of char in C instead of the predefined solution of Cadvanced (to use dynamic memory allocation).
• idltypes.sdl - This package cannot be used with Cmicro.
• access.pr - This ADT cannot be used together with Cmicro.
• byte.pr - This ADT can be used in the same way as described for Cadvanced.
• file.pr - This ADT is not useful for typical Cmicro applications (embedded systems usually do not provide a hard disk in Cmicro applications) and for that reason never has been tested. The ADT may, however, work with Cmicro.
• idltypes.pr - This ADT cannot be used together with Cmicro.
• idnode.pr - This ADT cannot be used together with Cmicro.
• list1.pr/list2.pr - This ADT can be used together with Cmicro.
• long_int.pr - This ADT can be used together with Cmicro.
• pidlist.pr - This ADT cannot be used as it is specific to Cadvanced only.
• pointer.pr - This ADT can be used together with Cmicro but the user should be aware of it's own restrictions.
• random.pr - This ADT can be used together with Cmicro.
• unsigned.pr - This ADT can be used together with Cmicro.
• unsigned_long.pr - This ADT can be used together with Cmicro.

Combining Cadvanced / Cmicro C Code

Real-time Operating System Support

There are tight integrations for Cmicro but these are not part of the product.

CORBA Integration (UNIX only)

• The CORBA integration cannot be used together with the Cmicro package.

Corrected Errors

Cmicro Generator and Library

• Array of newtype struct value passed into a procedure by using FPAR in/out lead to compilation or runtime errors depending on the C compiler. This has been solved by a correction in the Cmicro Codegenerator.
• The predefined sort "ref" lead to fatal compiler errors. This has been solved by inserting some additional macros in ml_typ.h.
• A global procedure could not use pid expressions in tight integrations. This has been solved by inserting some additional macros in ml_typ.h. The macros are called XGP_PARAM_.* and are to be defined as empty in bare/light integrations (they are in the Cmicro Library of the patch release, so the user does not have to take care on this). In Tight Integrations these macros are expanded, so that all the possible PID expressions can be passed down to the procedure. PID expressions are : SENDER/PARENT/OFFSPRING/SELF.

Cmicro Tester and Cmicro Bodybuilder

• The problems with reading the wrong .ifc or .sym files have been removed for both, the Cmicro Tester and the Cmicro Bodybuilder.
• For using the emulator, ( in section : CommLink - CommunicationsLink ), a separate license is necessary.
• If the flag Use_V24_ Communication, ( in section : CommLink - V24 interface ), is set the flags XMK_V24_BAUD and XMK_V24_DEVICE will be set correctly, now.
• If the Bodybuilder is opened, it will detect new files in the working directory.
• The .lock file will be removed, if bodyconf.def is not found.
• The Green Hills Compiler is now implemented.
• The syntax of the generated macro XMK_USE_STATIC_AND_DYNAMIC_QUEUE is corrected.
• If the .ifc files are manipulated, the Bodybuilder wont be crach down . It will give a message to the user, concerning the situation.