|
|
|
| R2012a Documentation → Embedded Coder | |
Learn more about Embedded Coder |
|
| Contents | Index |
This table summarizes what is new in Version 6.1 (R2011b):
| New Features and Changes | Version Compatibility Considerations | Fixed Bugs and Known Problems |
|---|---|---|
| Yes Details below | Yes—Details labeled as Compatibility Considerations, below. See also Summary | Bug
Reports Includes fixes |
New features and changes introduced in this version are:
Generate Multitasking Code for Concurrent Execution on Multicore Processors
Custom Storage Class Properties for Managing Data Ownership and Definition
Export Data Declarations to Shared Header File for Code Generation with Model Reference
Enhanced Code Generation Optimization Using Minimum and Maximum Values
Control of Default Case Generation for Switch Statements in Generated Code for Stateflow Charts
License Names Not Yet Updated for Coder Product Restructuring
The HTML code generation report now includes a static code metrics report. The static code metrics include: number of source code files, number of lines of code, list of global variables, functions in a call tree format, and the estimated stack size required for a function.
To generate the static code metrics report, on the Code Generation > Report pane of the Configuration Parameters dialog box, select the Static code metrics parameter and build your model. For more information, see Analyze Static Code Metrics of the Generated Code.
Embedded Coder now supports Sensor/Actuator Software Components. The key difference between a sensor/actuator component and an application component is that a sensor/actuator component can access the I/O hardware abstraction part within the ECU abstraction layer.
This support allows you to import sensor/actuator components, implement and test designs within Simulink, and export sensor/actuator components. For more information, see Use the Configure AUTOSAR Interface Dialog Box.
Previously, Embedded Coder did not support the creation of multiple runnables from subsystems with links to Simulink library blocks. For example, you had to disable and break links to library blocks in order to configure and validate the subsystems as AUTOSAR runnables.
Now, the software supports the creation of multiple runnables when:
The wrapper subsystem (containing function-call subsystems) is a link to a library block
The function-call subsystems (within the wrapper subsystem) are links to library blocks
For more information, see Configure Multiple Runnables in the Embedded Coder documentation.
The software now supports AUTOSAR schema version 3.2 (3.2.1). See Select an AUTOSAR Schema.
When you export an AUTOSAR Software Component, you can generate XML as either a set of files (default) or a single file. The latter option is new. For more information, see Use the Configure AUTOSAR Interface Dialog Box.
R2011b supports the following enhancements for software-in-the loop (SIL) and processor-in-the-loop (PIL) simulations.
Previously, you could generate a profile of code execution times only for tasks within your generated code (for example, the step function for a sample rate). Now, you can also produce a profile of code execution times for functions generated from atomic subsystems and model reference hierarchies within the top model. The software places instrumentation probes inside these functions and calculates execution times during a SIL or PIL simulation. At the end of the simulation, you can view an HTML report and analyze execution times within the MATLAB environment:
The HTML report provides a summary of maximum and average execution times, which allows you to identify code that requires optimization
The supplied APIs allow you to carry out further analysis of time measurements.
For more information, see Code Execution Profiling in the Embedded Coder documentation.
You can measure code coverage using the LDRA Testbed from LDRA Software Technology. For more information, see Code Coverage.
The software previously did not support the BitField and GetSet custom storage classes. Now, the software supports these custom storage classes for all types of SIL and PIL simulations, with one limitation. GetSet behavior for the SIL block is different from top-model SIL/PIL, Model block SIL/PIL, and PIL block:
SIL block — The C definitions of the Get and Set functions that you provide form part of the algorithm under test.
Other types of SIL/PIL — The SIL/PIL test harness automatically provides C definitions of the Get and Set functions that are used during SIL/PIL simulations. In addition, the software supports only scalar signals, parameters and global data stores.
For more information, see I/O Support and GetSet Custom Storage Class.
You can run Model block SIL and PIL simulations where the Model block contains variable-size signals. On the Simulation > Configuration Parameters > Model Referencing pane, in the Propagate sizes of variable-size signals field, you must specify During execution. See I/O Support.
Previously, support for C++ was restricted to simulations with the SIL block. Now, you can verify generated C++ code using all types of SIL and PIL:
Top-model
Model block
SIL or PIL block
As before, only the SIL block supports C++ encapsulation. See Configuration Parameters Support.
The Embedded Coder product extends the concurrent execution modeling capability of the Simulink product. With Embedded Coder, you can generate multitasking code that uses POSIX threads (Pthreads) for concurrent execution on multicore processors running Linux or VxWorks®.
See Configuring Models for Targets with Multicore Processors.
Installing MATLAB & Simulink on a 64-bit Windows® computer automatically installs the 64-bit versions of your MathWorks products, including Embedded Coder software. Now, you can use the 64-bit version of Embedded Coder software with the following 32-bit IDEs/tool chains:
Texas Instruments™ Code Composer Studio™ 3.3
Texas Instruments Code Composer Studio 4.0
Analog Devices™ VisualDSP++® 5.0 (update 8)
Previously, you had to install the 32-bit versions of your MathWorks products to use Embedded Coder software with these IDEs.
For more information, see Embedded Coder — Support for Texas Instruments and Embedded Coder — Support for Analog Devices.
Also, check the Texas Instruments and Analog Devices Web sites for support information about using their tools on 64-bit Windows platforms.
You can automatically generate and integrate code with the Wind River® VxWorks 6.8 RTOS using makefiles via the XMakefiles feature. For more information, see Choosing an XMakefile Configurationand Working with Wind River VxWorks RTOS.
This release adds support for Serial Communication Interface (SCI) communications during processor-in-the-loop (PIL) simulations with Texas Instruments™ C28035 and C28335 microcontrollers. Using SCI for PIL simulations is much faster than using an IDE debugger for PIL.
For more information, see Serial Communication Interface (SCI) for Texas Instruments C2000, Example — Performing a Model Block PIL Simulation via SCI Using Makefiles, and the fuelsys_pil demo.
This release adds a new Target Function Library (TFL), Intel IPP/SSE (GNU), for the GCC compiler. This library includes the Intel Performance Primitives (IPP) and Streaming SIMD Extensions (SSE) code replacements.
For more information, see Code Replacement Library (CRL) and Embedded TargetsDesktop Targets.
This release adds support for the Single Instruction Multiple Data (SIMD) capabilities of the ARM® Cortex-A8, ARM Cortex-A9 , and Intel® processors. The use of SIMD instructions increases throughput compared to traditional Single Instruction Single Data (SISD) processing.
The following TFLs (code replacement libraries) optimize generated code for SIMD:
GCC ARM Cortex-A8 — The GCC compiler and the ARM Cortex-A8 embedded processor
GCC ARM Cortex-A9 — The GCC compiler and the ARM Cortex-A9 embedded processor
Intel IPP/SSE (GNU) — The GCC compiler and the Intel Performance Primitives (IPP) and Streaming SIMD Extensions (SSE)
The performance of the SIMD-enabled executable depends on several factors, including:
Processor architecture of the target
Optimized library support for the target
The type and number of TFL replacements in the generated algorithmic code
Evaluate the performance of your application before and after using the TFL.
To use SIMD capabilities, enable the corresponding TFLs as described in Code Replacement Library (CRL) and Embedded TargetsDesktop Targets.
Support for the Altium® TASKING IDE has been removed from the Embedded Coder product.
Support for the Infineon® C166® processor family has been removed from the Embedded Coder product.
Support for the Green Hills® MULTI® IDE will end in a future release of the Embedded Coder product.
Support for the Freescale MPC5xx processor family will end in a future release of the Embedded Coder product.
A new property for Stateflow® charts, Saturate on integer overflow, enables you to control the behavior of data with signed integer types when overflow occurs. This check box appears in the Chart properties dialog box.
| Check Box | When to Use This Setting | Overflow Handling | Example of a Result |
|---|---|---|---|
Selected | Overflow is possible for data in your Stateflow chart and you want explicit saturation protection in the generated code. | Overflows saturate to either the minimum or maximum value that the data type can represent. | An overflow associated with a signed 8-bit integer saturates to –128 or +127. |
Cleared | You want to optimize efficiency of the generated code. | The behavior depends on the C compiler you use for generating code. | The number 130 does not fit in a signed 8-bit integer and wraps to –126. |
Arithmetic operations in the chart for which you can enable saturation protection are:
Unary minus: –a
Binary operations: a + b, a – b, a * b, a / b, a ^ b
Assignment operations: a += b, a –= b, a *= b, a /= b
For new charts, this check box is selected by default. When you open charts saved in previous releases, the check box is cleared to maintain backward compatibility.
For more information, see Handling Integer Overflow for Chart Data in the Stateflow User's Guide.
In R2011b, use the Owner and Definition File properties of custom storage classes to manage the definition and ownership of mpt data objects in generated code.
Previously, you could include the data definitions in generated code but could not specify the model that defined the data. Now, Embedded Coder creates the data definitions in the generated code according to the Owner property.
The Owner property of a custom storage class specifies the model that owns and defines the data in the generated code. The Definition File property specifies a name for the data definition file that Embedded Coder generates.
If your legacy code exports data definitions to generated code and you now specify the Owner property, your generated code might have duplicate data definitions. This duplication causes a link error. In this case, remove the data definitions from the legacy code.
If your legacy code does not export data definitions to generated code and you now specify the Owner property, your generated code might not contain data definitions. This mismatch causes a link error. In this case, add the missing data definitions to your legacy code.
When generating code with model reference, you can export shared data declarations to a specific header file in a shared directory.
Specify a data declaration header file in the following ways:
For a data object: In the Code generation options section of the data object dialog
For a model: In the Code Generation > Code Placement section of the Configuration Parameters dialog
Specify the option to use a Shared location in the field Shared code placement in Code Generation > Interface section of the Configuration Parameters dialog.
R2011b provides the following enhancements to code replacement using target function libraries (TFLs).
R2011b provides the Code Replacement Tool, which helps you create and manage the code replacement tables that make up a TFL. You can:
Create a new code replacement table or import existing tables.
Add, modify, and delete table entries. Each table entry represents a potential code replacement for a single function or operator. You can manage multiple tables together and copy and paste entries between tables.
Validate tables and table entries.
Save code replacement tables as MATLAB files.
Generate the customization file you use to register your code replacement tables with code generation software.
Each code replacement table contains one or more table entries. Each table entry represents a potential replacement, during code generation, of a single function or operator by a custom implementation. For each table entry, you provide:
Mapping Information, which relates a conceptual view of the function or operator (similar to the Simulink block view of the function or operator) to a custom implementation of that function or operator.
Build Information, which provides any header, source, or link information required for building the custom implementation.
You can open the Code Replacement Tool in the following ways:
Go to the Interface pane of the Configuration Parameters dialog box and click the Custom button, which is located to the right of the Target function library parameter.
Use the MATLAB command crtool.
For more information about creating code replacement tables for TFLs, see Create and Manage Code Replacement Tables Using the Code Replacement Tool.
R2011b provides the ability to align data objects passed into a TFL replacement function to a specified boundary. This allows you to take advantage of target-specific function implementations that require data to be aligned in order to optimize application performance. To configure data alignment for a function implementation:
Specify the data alignment requirements in a TFL table entry. Alignment can be specified separately for each implementation function argument or collectively for all function arguments.
Specify the data alignment capabilities and syntax for one or more compilers, and include the alignment specifications in a TFL registry entry in an sl_customization.m or rtwTargetInfo.m file.
For more information on specifying data alignment requirements and compiler alignment attributes, see Configure Data Alignment for Function Implementations.
For additional examples of configuring data alignment for function implementations, see the demo rtwdemo_tfl_script.
TFLs support several nonscalar operators for replacement with custom library functions in generated model code. R2011b adds support for replacing element-wise matrix multiplication operations (.* operator in element-wise mode) with custom implementations. For more information, see Map Nonscalar Operators to Target-Specific Implementations.
Multiple checks of the same condition are difficult to avoid in modeling. For example, a common modeling pattern is Switch blocks sharing the same condition check. Previously, the generated code for multiple Switch blocks produced multiple if statements.
if (cond) {
true_statement1;
} else {
false_statement1; }
if (cond) {
true_statement2;
} else {
false_statement2;
}In R2011b, the generated code combines these condition checks. For example, the generated code for Switch blocks with a common condition combines these multiple if statements.
if (cond) {
true_statement1;
true_statement2;
}
else {
false_statement1;
false_statement2;
}
This optimization reduces code size and execution time. As a result, other optimizations for condition expressions or merged branches are enabled which reduce data copies and RAM usage.
R2011b provides more precise data dependency analysis of the data and signals of a nested Simulink bus. This enhancement enables more loop fusion in the generated code which reduces code execution time and ROM, and improves code readability.
When a condition check is invariant to the enclosing loop and you specify loops to be unrolled, the code generator lifts the check out of the loop. This enhancement reduces ROM, enables additional optimizations, and improves execution speed and code readability. For more information on loop unrolling, see Configure Loop Unrolling Threshold.
Parameter pooling now occurs for Simulink matrix constants used as Stateflow graphical function arguments. This enhancement reduces RAM and ROM, and improves thread safety.
The generated code for reusable subsystem input and output now eliminates redundant operators and unnecessary parentheses. This enhancement improves code readability.
The Optimize using specified minimum and maximum values code generation option now takes into account the minimum and maximum values specified for all Simulink.Parameter objects even if the object is part of an expression. For example, consider a Gain block with a gain parameter specified as an expression such as k1 + 5, where k1 is a Simulink.Parameter object with k1.min = -10 and k1.max = 10. If minimum and maximum values of the parameter specified in the parameter dialog box are 0 and 20, the range calculated for this parameter expression is 0 to 15.
For more information, see Optimize Generated Code Using Specified Minimum and Maximum Values.
The Simulink Model Advisor includes the following new check for code efficiency of logic blocks: Check output types of logic blocks. The following blocks in the Simulink Logic and Bit Operations library can use boolean or another setting for the output data type:
Running this Model Advisor check helps you identify logic blocks that do not use boolean for the output data type.
For more information about the Model Advisor, see Consulting the Model Advisor in the Simulink documentation.
You can specify whether or not to always generate default cases for switch statements in the generated code for Stateflow charts. This optimization works on a per-model basis and applies to the code generated for a state that has multiple substates. Use the following check box on the Code Generation > Code Style pane of the Configuration Parameters dialog box:
| Check Box | When to Use This Setting | Format of Switch Statements |
|---|---|---|
| Selected | Provide better code coverage by checking that every branch in the generated code is falsifiable. | Exclude the default case when it is unreachable. |
| Cleared | Check for MISRA C® compliance and provide a fallback in case of RAM corruption. | Always include a default case. |
For new models, this check box is cleared by default. When you open models saved in previous releases, the check box is also cleared to maintain backward compatibility.
For more information, see Code Generation Pane: Code Style in the Embedded Coder Reference documentation.
Previously, if your model contained two referenced models with the same input (or output) port names, the model might not build because of potentially conflicting identifiers. The failure to build happens when the generated identifiers exceed the Maximum identifier length. In R2011b, the build process is improved to handle more cases when two referenced models have the same input (or output) port names. For more information, see Model Referencing Considerations.
The Connectivity cgv.Config parameter has the following updates:
pil replaces the custom value. In R2011b, you can use custom without producing a warning or error message.
The tasking value is no longer available. Specifying tasking produces an error.
The Simulink Coder and Embedded Coder license name strings stored in license.dat and returned by the license ('inuse') function have not yet been updated for the R2011a coder product restructuring. Specifically, the license ('inuse') function continues to return 'real-time_workshop' for Simulink Coder and 'rtw_embedded_coder' for Embedded Coder, as shown below:
>> license('inuse')
matlab
matlab_coder
real-time_workshop
rtw_embedded_coder
simulink
>>The license name strings intentionally were not changed, in order to avoid license management complications in situations where Release 2011a or higher is used alongside a preR2011a release in a common operating environment. MathWorks plans to address this issue in a future release.
For more information about using the function, see the license documentation.
The following demos have been enhanced in R2011b:
| Demo... | Now... |
|---|---|
| rtwdemo_pmsmfoc_script | Shows how you can perform system-level simulation and algorithmic code generation using Field-Oriented Control for a Permanent Magnet Synchronous Machine |
| rtwdemo_sil_pil_script | Incorporates code execution profiling |
| rtwdemo_tfl_script | Shows how you can align nonscalar data passed into a target function library (TFL) code replacement function |
| fuelsys_pil | Incorporates using serial communication interface to communicate during PIL simulation |
 | Version 6.2 (R2012a) Embedded Coder Software | Version 6.0 (R2011a) Embedded Coder Software |  |
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 |
