Limitations and Tips
The following limitations apply to AUTOSAR code generation.
Generate Code Only Check Box
If you do not select the Generate code only check box, the software produces an error message when you build the model. The message states that you can build an executable with the AUTOSAR system target file only if you:
Configure the model to create a software-in-the-loop (SIL) or processor-in-the-loop (PIL) block
Run the model in SIL or PIL simulation mode
Provide a custom template makefile
AUTOSAR Compiler Abstraction Macros (Classic Platform)
The software does not generate AUTOSAR compiler abstraction macros for data or functions arising from the following:
Model blocks
Stateflow®
MATLAB® Coder™
Shared utility functions
Custom storage classes
Local or temporary variables
Preservation of Bus Element Dimensions in Exported ARXML and Code
Bus element dimensions are preserved in the exported ARXML and generated code when a
model is configured with the property Array layout set to
Row-major
. Previously, if a model contained a
Simulink.Bus
data type that had a multidimensional array
Simulink.BusElement
, the exported ARXML and generated code flattened
the bus element to a one-dimensional array. Now, the generated code and exported ARXML
preserves the dimensionality as expected.
Loop Unrolling Threshold Optimization
AUTOSAR code generation supports optimizations, such as Loop unrolling threshold (Simulink Coder), for improving the performance of the generated code. The circumstances under which these optimizations are implemented in the generated code can vary across releases and targets.
C++11 Style Scoped Enum Classes Generated for AUTOSAR Adaptive Applications
To facilitate easier integration, by default the generated C++ code for AUTOSAR adaptive
models emit C++ 11 style scoped enum class data types in the generated code. You can view
this data type definition in the header file for enumerations located in the
aragen/stub
folder of the build folder. This data type definition is
standardized and validated prior to code generation.
The following table shows a comparison of a scoped enum class definition versus the previously generated code behavior for a dynamic enumeration:
Simulink.defineIntEnumType('BasicColors', ... {'Red','Green','Blue'},... [0;1;2],... 'DataScope','Auto',... 'StorageType','uint8')
Generated Enumeration Definition in Header File
Previous Behavior (C++03) | Current Default Behavior (C++11) |
---|---|
#ifndef IMPL_TYPE_BASICCOLORS_H_ #define IMPL_TYPE_BASICCOLORS_H_ #include <cstdint> using BasicColors = uint8_t; const BasicColors Red = 0; const BasicColors Green = 1; const BasicColors Blue = 2; #endif //IMPL_TYPE_BASICCOLORS_H_ |
#ifndef IMPL_TYPE_BASICCOLORS_H_ #define IMPL_TYPE_BASICCOLORS_H_ #include <cstdint> enum class BasicColors : uint8_t { Red = 0, Green = 1, Blue = 2 }; #endif //IMPL_TYPE_BASICCOLORS_H_ |
The default behavior is determined by the default Language standard
for a model set to C++11(ISO)
. If you configure this setting so that a
model to generates C++ 03, then the generated code emits the previous code definition
behavior and may not compile if used with a third-party ara generator.
AUTOSAR Code Generation Complex Number Support
AUTOSAR code generation supports complex numbers inside software components, but it does not support complex signals at the model interface level. For more information regarding this code generation setting, see Support: complex numbers (Embedded Coder).
Optimization of Unused Root-Level Inport Blocks
Inport blocks that are grounded are considered unused by the software and
optimized out during code generation. As a result, these inports are not considered during
RTE stub generation which may lead to the data types of these blocks not being described in
the generated Rte_Type.h
header file.
Inconsistent Code Replacement Behavior
It is possible that code replacement behaves differently than you expect. For example, intermediate data types for a Simulink® block might not match the intermediate data types used by your implementation code even if the input and output data types do match the implementation code.
Additionally, discrepancies can occur due to implementation details of the replacement code, as the implementations might differ from the logic used by Simulink for simulation. This can lead to mismatches between simulation and generated code behavior. Verify code replacements by examining the generated code and check the implementations when potential mismatches occur between simulation and generated code behavior to justify the discrepancies.
For more information regarding the AUTOSAR 4.x code replacement library, see Code Generation with AUTOSAR Code Replacement Library.
See Also
Topics
- Support: complex numbers (Embedded Coder)
- Verify AUTOSAR Code with SIL and PIL
- Loop unrolling threshold (Simulink Coder)