Documentation

Explanatory Note for Directive 1.1

Information about the implementation-defined behavior for Embedded Coder is available in Configure Run-Time Environment Options . Compiler documentation is out of scope.

Character set encoding is managed by using the SavedCharacterEncoding model parameter. For additional information, including a list of supported character encodings, see slCharacterEncoding.

Configure the integer division method in the Model Configuration Parameters dialog box, on the Hardware Implementation pane. For additional information, see Configure Run-Time Environment Options

Embedded Coder generates #pragma when the user:

In both instances, you are responsible for documenting the intended use of the #pragma. For more information, see Control Data and Function Placement in Memory by Inserting Pragmas.

To enable the generation of bitfields:

Explanatory Note for MISRA Directive 3.1

You can link requirements model elements. These links are included in the generated C code to provide traceability from a requirements document, to the model elements, and to the generated code. For additional information, see View Linked Requirements in Models and Blocks and Link Blocks and Requirements (Simulink Requirements).

Explanatory Note for Directive 4.1

You can use Polyspace Bug Finder™ to identify run-time errors and Polyspace Code Prover™ to prove the absence of run-time errors. For information, see:

Simulink Design Verifier can be used to detect design errors at the model level. For more information, see Run a Design Error Detection Analysis (Simulink Design Verifier).

Explanatory Note for Directive 4.3

Embedded Coder does not directly call assembly language code. You can add calls to assembly language functions through S-functions, code replacement libraries, Stateflow, and in MATLAB^® blocks. These calls are documented as calls to External C Functions. In these cases, you are responsible for encapsulation.

For additional information, see:

Explanatory Note for Directive 4.6

Embedded Coder replaces basic data types with typedefs types, which are compatible with Directive 4.6. A guideline is not required because this behavior is default behavior in Embedded Coder. For additional information, see Replace and Rename Data Types to Conform to Coding Standards and Typedefs.

Explanatory Note for Directive 4.11

The requirements of this directive are satisfied by:

“Demonstrate statically that the input parameters can never take invalid values”.

You can use Polyspace Code Prover to analyze parameter ranges and prove the absence of run-time errors caused by out-of-range values. For additional information, see Run Polyspace Analysis on Code Generated with Embedded Coder (Polyspace Code Prover).

Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8

Embedded Coder is configurable to limit the number of characters imposed by the implementation. For additional information, see Maximum identifier length.

To ensure unique names for different types of variables (local scope variables, global scope variables, macros, and so on), implement a naming convention. For additional information, see Model Configuration Parameters: Code Generation Symbols.

Explanatory Note for Rule 8.12

Embedded Coder supports the use of enumerated data. The file used to define the enumeration can be either manually or automatically generated. Files defining enumerations generated by Embedded Coder are compliant with MISRA C:2012 Rule 8.12 by design. If you manually create the definition file, you are responsible for ensuring compliance. For additional information, see Use Enumerated Data in Simulink Models.

Explanatory Note for Rules 10.1 and 10.2

Embedded Coder does not directly create data of type char. Data of char type can be introduced by user-defined S-functions, code replacement libraries, and custom storage classes. In this case, limit the usage of plain char to: