Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Real-Time Workshop Embedded Coder |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Real-Time Workshop Embedded Coder |
| Contents | Index |
| Learn more about Real-Time Workshop Embedded Coder |
Several parameters are available for customizing generated symbols.
| To... | Specify... |
|---|---|
| Define a macro string that specifies whether, and in what order, certain substrings are included within generated identifiers for global variables, global types, field names of global types, subsystem methods, subsystem method arguments, local temporary variables, local block output variables, and constant macros | The macro string with the Identifier format control parameter (for details on how to specify formats, see Specifying Identifier Formats and for limitations, see Identifier Format Control Parameters Limitations). |
| Specify the minimum number of characters the code generator uses for mangled symbols | Specify an integer value for the Minimum mangle length (for details, see Name Mangling). |
| Specify the maximum number of characters the code generator can use for function, typedef, and variable names (default 31) | Specify an integer value for the Maximum identifier length. If you expect your model to generate lengthy identifiers (due to use of long signal or parameter names, for example), or you find that identifiers are being mangled more than expected, you should increase the value of this parameter. |
| Control whether scalar inlined parameter values are expressed in generated code as literal values or macros | The value Literals or Macros for the Generate scalar inlined parameters as parameter .
|
For more information, see Real-Time Workshop Pane: Symbols in the Real-Time Workshop reference documentation.
| To Define Rules that Change the Names of a Model's... | Specify a Naming Rule with the ... |
|---|---|
| Signals | Signal naming parameter |
| Parameters | Parameter naming parameter |
| Parameters that have a storage class of Define | #define naming parameter |
For more information on these parameters, see Specifying Simulink Data Object Naming Rules in the Real-Time Workshop Embedded Coder Module Packaging Features document.
The Identifier format control parameters let you customize generated identifiers by entering a macro string that specifies whether, and in what order, certain substrings are included within generated identifiers. For example, you can specify that the root model name be inserted into each identifier.
The macro string can include
Tokens of the form $X, where X is a single character. Valid tokens are listed in Identifier Format Tokens. You can use or omit tokens as you want, with the exception of the $M token, which is required (see Name Mangling) and subject to the use and ordering restrictions noted in Identifier Format Control Parameter Values.
Any valid C or C++ language identifier characters (a-z, A-Z, _ , 0-9).
The build process generates each identifier by expanding tokens (in the order listed in Identifier Format Tokens) and inserting the resultant strings into the identifier. Character strings between tokens are simply inserted directly into the identifier. Contiguous token expansions are separated by the underscore (_) character.
Identifier Format Tokens
| Token | Description |
|---|---|
| $M | Insert name mangling string if required to avoid naming collisions (see Name Mangling). Note: This token is required. |
| $F | Insert method name (for example, _Update for update method). This token is available only for subsystem methods. |
| $N | Insert name of object (block, signal or signal object, state, parameter or parameter object) for which identifier is being generated. |
| $R | Insert root model name into identifier, replacing any unsupported characters with the underscore (_) character. Note that when using model referencing, this token is required in addition to $M (see Model Referencing Considerations). Note: This token replaces the Prefix model name to global identifiers option used in previous releases. |
| $H | Insert tag indicating system hierarchy level. For root-level blocks, the tag is the string root_. For blocks at the subsystem level, the tag is of the form sN_, where N is a unique system number assigned by the Simulink software. This token is available only for subsystem methods and field names of global types. Note: This token replaces the Include System Hierarchy Number in Identifiers option used in previous releases. |
| $A | Insert data type acronym (for example, i32 for long integers) to signal and work vector identifiers. This token is available only for local block output variables and field names of global types. Note: This token replaces the Include data type acronym in identifier option used in previous releases. |
| $I | Insert u if the argument is an input or y if the argument is an output, (for example, rtu_ for an input argument and rty_ for an output argument). This token is available only for subsystem method arguments. |
Identifier Format Control Parameter Values lists the default macro string, the supported tokens, and the applicable restrictions for each Identifier format control parameter.
Identifier Format Control Parameter Values
| Parameter | Default Value | Supported Tokens | Restrictions |
|---|---|---|---|
| Global variables | $R$N$M | $R, $N, $M | $F, $H, $A, and $I are disallowed. |
| Global types | $N$R$M | $N, $R, $M | $F, $H, $A, and $I are disallowed. |
| Field name of global types | $N$M | $N, $M, $H, $A | $R, $F, and $I are disallowed. |
| Subsystem methods | $R$N$M$F | $R, $N, $M, $F, $H | $F and $H are empty for Stateflow functions; $A and $I are disallowed. |
| Subsystem method arguments | rtu_$N$M or rty_$N$M | $N, $M, $I | $R, $F, $H, and $A are disallowed. |
| Local temporary variables | $N$M | $N, $M, $R | $F, $H, $A, and $I are disallowed. |
| Local block output variables | rtb_$N$M | $N, $M, $A | $R, $F, $H, and $I are disallowed. |
| Constant macros | $R$N$M | $R, $N, $M | $F, $H, $A, and $I are disallowed. |
Non-ERT based targets (such as the GRT target) implicitly use a default $R$N$M specification. This specifies identifiers consisting of the root model name, followed by the name of the generating object (signal, parameter, state, and so on), followed by a name mangling string (see Name Mangling).
For limitations that apply to Identifier format control parameters, see Identifier Format Control Parameters Limitations.
In identifier generation, a circumstance that would cause generation of two or more identical identifiers is called a name collision. Name collisions are never permissible. When a potential name collision exists, unique name mangling strings are generated and inserted into each of the potentially conflicting identifiers. Each name mangling string is guaranteed to be unique for each generated identifier.
The position of the $M token in the Identifier format control parameter specification determines the position of the name mangling string in the generated identifiers. For example, if the specification $R$N$M is used, the name mangling string is appended (if required) to the end of the identifier.
The Minimum mangle length parameter specifies the minimum number of characters used when a name mangling string is generated. The default is 1 character. As described below, the actual length of the generated string may be longer than this minimum.
An important aspect of model based design is the ability to generate identifiers that can easily be traced back to the corresponding entities within the model. To ensure traceability, it is important to make sure that incremental revisions to a model have minimal impact on the identifier names that appear in generated code. There are two ways of achieving this:
When conflicts cannot be avoided (as may be the case in models that use libraries or model reference), name mangling ensures traceability. The position of the name mangling string is specified by the placement of the $M token in the Identifier format control parameter specification. Mangle characters consist of lower case characters (a-z) and numerics (0-9), which are chosen with a checksum that is unique to each object. How Name Mangling Strings Are Computed describes how this checksum is computed for different types of objects.
How Name Mangling Strings Are Computed
| Object Type | Source of Mangling String |
|---|---|
Block diagram | Name of block diagram |
Simulink block | Full path name of block |
Simulink parameter | Full name of parameter owner (that is, model or block) and parameter name |
Simulink signal | Signal name, full name of source block, and port number |
Stateflow objects | Complete path to Stateflow block and Stateflow computed name (unique within chart) |
The length of the name mangling string is specified by the Minimum mangle length parameter. The default value is 1, but this automatically increases during code generation as a function of the number of collisions.
To minimize disturbance to the generated code during development, specify a larger Minimum mangle length. A Minimum mangle length of 4 is a conservative and safe value. A value of 4 allows for over 1.5 million collisions for a particular identifier before the mangle length is increased.
Note that the length of generated identifiers is limited by the Maximum identifier length parameter. When a name collision exists, the $M token is always expanded to the minimum number of characters required to avoid the collision. Other tokens and character strings are expanded in the order listed in Identifier Format Tokens. If the Maximum identifier length is not large enough to accommodate full expansions of the other tokens, partial expansions are used. To avoid this outcome, it is good practice to
Avoid name collisions in general. One way to do this is to avoid using default block names (for example, Gain1, Gain2...) when there are many blocks of the same type in the model.
Where possible, increase the Maximum identifier length to accommodate the length of the identifiers you expect to generate.
Set the Minimum mangle length parameter to reserve at least three characters for the name mangling string. The length of the name mangling string increases as the number of name collisions increases.
Note that an existing name mangling string increases (or decreases) in length if changes to model create more (or fewer) collisions. If the length of the name mangling string increases, additional characters are appended to the existing string. For example, 'xyz' might change to 'xyzQ'. In the inverse case (fewer collisions) 'xyz' would change to 'xy'.
Within a model that uses model referencing, there can be no collisions between the names of the constituent models. When generating code from a model that uses model referencing:
The $R token must be included in the Identifier format control parameter specifications (in addition to the $M token).
The Maximum identifier length must be large enough to accommodate full expansions of the $R and $M tokens. A code generation error occurs if Maximum identifier length is not large enough.
When a name conflict occurs between an identifier within the scope of a higher-level model and an identifier within the scope of a referenced model, the identifier from the referenced model is preserved. Name mangling is performed on the identifier from the higher-level model.
There are some exceptions to the identifier formatting conventions described above:
Type name generation: The above name mangling conventions do not apply to type names (that is, typedef statements) generated for global data types. If the $R token is included in the Identifier format control parameter specification, the model name is included in the typedef. The Maximum identifier length parameter is not respected when generating type definitions.
Non-Auto storage classes: The Identifier format control parameter specification does not affect objects (such as signals and parameters) that have a storage class other than Auto (such as ImportedExtern or ExportedGlobal).
The following limitations apply to the Identifier format control parameters:
The following autogenerated identifiers currently do not fully comply with the setting of the Maximum identifier length parameter on the Real-Time Workshop/Symbols pane of the Configuration Parameters dialog box.
Model methods
The applicable format string is $R$F, and the longest $F is _derivatives, which is 12 characters long. The model name can be up to 19 characters without exceeding the default Maximum identifier length of 31.
Local functions generated by S-functions or by add-on products such as Signal Processing Blockset™ that rely on S-functions
Local variables generated by S-functions or by add-on products such as Signal Processing Blockset that rely on S-functions
DWork identifiers generated by S-functions in referenced models
Fixed-point shared utility macros or shared utility functions
Simulink rtm macros
Most are within the default Maximum identifier length of 31, but some exceed the limit. Examples are RTMSpecAccsGetStopRequestedValStoredAsPtr, RTMSpecAccsGetErrorStatusPointer, and RTMSpecAccsGetErrorStatusPointerPointer.
Define protection guard macros
Header file guards, such as _RTW_HEADER_$(filename)_h_, which can exceed the default Maximum identifier length of 31 given a filename such as $R_private.h.
Include file guards, such as _$R_COMMON_INCLUDES_.
typedef guards, such as _CSCI_$R_CHARTSTRUCT_.
In some situations, the following identifiers potentially can conflict with others.
Model methods
Local functions generated by S-functions or by add-on products such as Signal Processing Blockset that rely on S-functions
Local variables generated by S-functions or by add-on products such as Signal Processing Blockset that rely on S-functions
Fixed-point shared utility macros or shared utility functions
Include header guard macros
The following external identifiers that are unknown to the Simulink software might conflict with autogenerated identifiers.
Identifiers defined in custom code
Identifiers defined in custom header files
Identifiers introduced through a non-ANSI C standard library
Identifiers defined by custom TLC code
Identifiers generated for simulation targets may exceed the Maximum identifier length. Simulation targets include the model reference simulation target, the accelerated simulation target, the RSim target, and the S-function target.
 | Customizing Comments in Generated Code | Controlling Code Style |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
