| Contents | Index |
| ID: Title | hisl_0061: Unique identifiers for clarity | ||
|---|---|---|---|
| Description | When developing a model, | ||
| A | Use unique identifiers for Simulink signals. | ||
| B | Define unique identifiers across multiple scopes within a chart. | ||
| Notes | The code generator automatically resolves conflicts between identifiers so that symbols in the generated code are unique. The process is called name mangling. | ||
| Rationale | A, B | Improve readability of a graphical model and mapping between identifiers in the model and generated code. | |
| References |
| ||
| See Also | Construction of Symbols in the Simulink Coder documentation | ||
| Last Changed | R2011a | ||
| Examples | In the following example,
two states use identifier IntCounter.
The identifier IntCounter is defined for two states, Scope_1 and Scope_2. Not Recommended
| ||
To clarify the model, create unique identifiers—for example,IntCounter_S1 and IntCounter_S2—or define IntCounter at the parent level. Recommended
| |||
| ID: Title | hisl_0062: Global variables in graphical functions | ||
|---|---|---|---|
| Description | For data with a global scope used in a function | ||
| A | Do not use the data in the calling expression if a value is assigned to the data in that function. | ||
| Rationale | A | Enhance readability of a model by removing ambiguity in the values of global variables. | |
| References |
| ||
| Last Changed | R2011a | ||
| Examples | The basic expression is Y = f(U) + G where in the function G is assigned a value. This modeling pattern is realized:
static real_T GlobalOperator_1(real_T U_1)
{
real_T Y_1;
/* Rreturns Y and modifies the global G_1 */
Y_1 = sin(U_1);
DWork.G_1 = -Y_1;
return Y_1;
}In the next example, the function uses the
initial value of 1 for global variable G_2 before the chart tries to assign the variable another value. The
generated code omits the assignment of G_2 to negative Y_2. (If the chart uses G_2 at a later point, the chart uses the updated value
of negative Y_2.)
static real_T GlobalOperator_2(real_T U_2)
{
real_T Y_2;
/* Returns Y and modifies the global G */
Y_2 =sin(U_2);
DWork.G_2 = -Y_2;
return Y_2;
}Code generator behavior is consistent and
predictable. |
| ID: Title | hisl_0063: Length of user-defined function names to improve MISRA-C:2004 compliance | ||
|---|---|---|---|
| Description | To improve MISRA-C:2004 compliance of the generated code when working with Subsystem blocks with the block parameter Function name options set to User specified: | ||
| A | Limit the length of data object names to 31 characters or fewer. | ||
| For this rule, Subsystem blocks include standard Simulink Subsystems, MATLAB Function blocks, and Stateflow blocks. | |||
| Rationale | A | Function names longer than 31 characters might result in a MISRA-C:2004 violation. | |
| References |
| ||
| Prerequisites | hisl_0060: Configuration parameters that improve MISRA-C:2004 compliance | ||
| Last Changed | R2011a | ||
| ID: Title | hisl_0064: Length of user-defined type object names to improve MISRA-C:2004 compliance |
|---|---|
| Description | To improve MISRA-C:2004 compliance of the generated code, limit
the length of data object names to 31 characters or fewer for:
|
| Rationale | The length of the type definitions in the generated code name might result in a MISRA-C:2004 violation. |
| References |
|
| Prerequisites | hisl_0060: Configuration parameters that improve MISRA-C:2004 compliance |
| Last Changed | R2011a |
| ID: Title | hisl_0065: Length of signal and parameter names to improve MISRA-C:2004 compliance |
|---|---|
| Description | To improve MISRA-C:2004 compliance of the generated code, limit
the length of signal and parameter names to 31 characters or fewer
when using any of
the following storage classes:
|
| Rationale | The length of the signal and parameter name might result in a MISRA-C:2004 violation. |
| References |
|
| Prerequisites | hisl_0060: Configuration parameters that improve MISRA-C:2004 compliance |
| Last Changed | R2011a |
| ID: Title | hisl_0201: Define reserved keywords to improve MISRA-C:2004 compliance | ||
|---|---|---|---|
| Description | To improve MISRA-C: 2004 compliance of the generated code, define reserved keywords to prevent identifier clashes within the project namespace. | ||
| A | In the Configuration Parameters dialog box, on the Simulation Target > Symbols > Reserved names pane, define reserved identifiers. | ||
| B | Use a consistent set of reserved identifiers for all models. | ||
| Notes | Simulink Coder checks models for standard C language key words. Expand the list of reserved identifiers to include project specific identifiers. Examples include target-specific clashes, standard and custom library clashes, and other identified clashes. | ||
| Rationale | Improve MISRA-C:2004 compliance of the generated code. | ||
| See Also |
| ||
| References | MISRA-C:2004, Rule 20.2 | ||
| Last Changed | R2011b | ||
![]() | MISRA-C:2004 Compliance Considerations | Block Usage | ![]() |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |