| Real-Time Workshop® Embedded Coder™ | |
The Real-Time Workshop Embedded Coder software provides code export capabilities that you can use to
Automatically generate code for
A function-call subsystem that contains only blocks that support code generation
A virtual subsystem that contains only such subsystems and a few other types of blocks
Optionally generate an ERT S-function wrapper for the generated code
You can use these capabilities only if the subsystem and its interface to the Simulink model conform to certain requirements and constraints, as described in Requirements for Exporting Function-Call Subsystems. For limitations that apply, see Function-Call Subsystems Export Limitations.
To see a demo of exported function-call subsystems, type rtwdemo_export_functions in the MATLAB Command Window.
See the following in the Simulink documentation for additional information relating to exporting function-call subsystems:
If you want to use Stateflow blocks to trigger exportable function-call subsystems, you may also need information from the Stateflow and Stateflow Coder User's Guide.
To be exportable as code, a function-call subsystem, or a virtual subsystem that contains such subsystems, must meet certain requirements. Most requirements are similar for either type of export, but some apply only to virtual subsystems. The requirements that affect all Simulink code generation also apply.
For brevity, exported subsystem in this section means only an exported function-call subsystem or an exported virtual subsystem that contains such subsystems. The requirements listed do not necessarily apply to other types of exported subsystems.
These requirements apply to both exported function-call subsystems and exported virtual subsystems that contain such subsystems.
Blocks Must Support Code Generation. All blocks within an exported subsystem must support code generation. However, blocks outside the subsystem need not support code generation unless they will be converted to code in some other context.
Blocks Must Not Use Absolute Time. Certain blocks use absolute time. Blocks that use absolute time are not supported in exported function-call subsystems. For a complete list of such blocks, see Limitations on the Use of Absolute Time in the Real-Time Workshop documentation.
Blocks Must Not Depend on Elapsed Time. Certain blocks, like the Sine Wave block and Discrete Integrator block, depend on elapsed time. If an exported function-call subsystem contains any blocks that depend on elapsed time, the subsystem must specify periodic execution. See Exporting Function-Call Subsystems That Depend on Elapsed Time in the Real-Time Workshop documentation.
Trigger Signals Require a Common Source. If more than one trigger signal crosses the boundary of an exported system, all of the trigger signals must be periodic and originate from the same function-call initiator.
Trigger Signals Must Be Scalar. A trigger signal that crosses the boundary of an exported subsystem must be scalar. Input and output data signals that do not act as triggers need not be scalar.
Data Signals Must Be Nonvirtual. A data signal that crosses the boundary of an exported system cannot be a virtual bus, and cannot be implemented as a Goto-From connection. Every data signal crossing the export boundary must be a scalar, a vector, or a nonvirtual bus.
These requirements apply only to exported virtual subsystems that contain function-call subsystems.
Virtual Subsystem Must Use Only Permissible Blocks. The top level of an exported virtual subsystem that contains function-call subsystem blocks can contain only the following other types of blocks:
Input and Output blocks (ports)
Constant blocks (including blocks that resolve to constants, such as Add)
Merge blocks
Virtual connection blocks (Mux, Demux, Bus Creator, Bus Selector, Signal Specification)
Signal-viewer blocks, such as Scope blocks
These restrictions do not apply within function-call subsystems, whether or not they appear in a virtual subsystem. They apply only at the top level of an exported virtual subsystem that contains one or more function-call subsystems.
Constant Blocks Must Be Inlined. When a constant block appears at the top level of an exported virtual subsystem, the containing model must check Inline parameters on the Optimization pane of the Configuration Parameters dialog box.
Constant Outputs Must Specify a Storage Class. When a constant signal drives an output port of an exported virtual subsystem, the signal must specify a storage class.
To export a function-call subsystem, or a virtual subsystem that contains function-call subsystems,
Ensure that the subsystem to be exported satisfies the Requirements for Exporting Function-Call Subsystems.
In the Configuration Parameters dialog box:
On the Real-Time Workshop pane, specify an ERT code generation target such as ert.tlc.
If you want an ERT S-function wrapper for the generated code, go to the Interface pane and select Create Simulink (S-function) block.
Click OK or Apply.
Right-click the subsystem block and choose Real-Time Workshop > Export Functions from the context menu.
The Build code for subsystem: Subsystem dialog box appears. This dialog box is not specific to exporting function-call subsystems, and generating code does not require entering information in the box.
Click Build.
The MATLAB Command Window displays messages similar to those for any code generation sequence. The Real-Time Workshop build process generates code and places it in the working directory.
If you checked Create Simulink (S-function) block in step 2b, The build process opens a new window that contains an S-function block that represents the generated code. This block has the same size, shape, and connectors as the original subsystem.
Code generation and optional block creation are now complete. You can test and use the code and optional block as you could any generated ERT code and S-function block.
You can use Real-Time Workshop options to optimize the code generated for a function-call subsystem or virtual block that contains such subsystems. To obtain faster code,
Specify a storage class for every input signal and output signal that crosses the boundary of the subsystem.
For each function-call subsystem to be exported (whether directly or within a virtual subsystem):
Right-click the subsystem and choose Subsystem Parameters from the context menu.
Set the Real-Time Workshop system code parameter to Auto.
Click OK or Apply.
Some blocks, such as the Sine Wave block (if sample-based) and the Discrete-Time Integrator block, depend on elapsed time. See Absolute and Elapsed Time Computation in the Real-Time Workshop documentation for more information.
When a block that depends on elapsed time exists in a function-call subsystem, the subsystem cannot be exported unless it specifies periodic execution. To provide the necessary specification,
Right-click the trigger port block in the function-call subsystem and choose TriggerPort Parameters from the context menu.
Specify periodic in the Sample time type field.
Set the Sample time to the same granularity specified (directly or by inheritance) in the function-call initiator.
Click OK or Apply.
The next figure shows the top level of a model that uses a Stateflow chart named Chart to input two function-call trigger signals (denoted by dash-dot lines) to a virtual subsystem named Subsystem.
The next figure shows the contents of Subsystem in the previous figure. The subsystem contains two function-call subsystems, each driven by one of the signals input from the top level.
In the preceding model, the Stateflow chart can assert either of two scalar signals, Toggle and Select.
Asserting Toggle toggles the Boolean state of the function-call subsystem Toggle Output Subsystem.
Asserting Select causes the function-call subsystem Select Input Subsystem to assign the value of DataIn1 or DataIn2 to its output signal. The value assigned depends on the current state of Toggle Output Subsystem.
The following generated code implements the subsystem named Subsystem. The code is typical for virtual subsystems that contain function-call subsystems. It specifies an initialization function and a function for each contained subsystem, and would also include functions to enable and disable subsystems if applicable.
#include "Subsystem.h"
#include "Subsystem_private.h"
/* Exported block signals */
real_T DataIn1; /* '<Root>/In3' */
real_T DataIn2; /* '<Root>/In4' */
real_T DataOut; /* '<S4>/Switch' */
boolean_T SelectorSignal; /* '<S5>/Logical Operator' */
/* Exported block states */
boolean_T SelectorState; /* '<S5>/Unit Delay' */
/* Real-time model */
RT_MODEL_Subsystem Subsystem_M_;
RT_MODEL_Subsystem *Subsystem_M = &Subsystem_M_;
/* Initial conditions for exported function: Toggle */
void Toggle_Init(void)
{
/* Initial conditions for function-call system: '<S1>/Toggle Output Subsystem' */
/* InitializeConditions for UnitDelay: '<S5>/Unit Delay' */
SelectorState = Subsystem_P.UnitDelay_X0;
}
/* Output and update for exported function: Toggle */
void Toggle(void)
{
/* Output and update for function-call system: '<S1>/Toggle Output Subsystem' */
/* Logic: '<S5>/Logical Operator' incorporates:
* UnitDelay: '<S5>/Unit Delay'
*/
SelectorSignal = !SelectorState;
/* Update for UnitDelay: '<S5>/Unit Delay' */
SelectorState = SelectorSignal;
}
/* Output and update for exported function: Select */
void Select(void)
{
/* Output and update for function-call system: '<S1>/Select Input Subsystem' */
/* Switch: '<S4>/Switch' incorporates:
* Inport: '<Root>/In3'
* Inport: '<Root>/In4'
*/
if(SelectorSignal) {
DataOut = DataIn1;
} else {
DataOut = DataIn2;
}
}
/* Model initialize function */
void Subsystem_initialize(void)
{
/* initialize error status */
rtmSetErrorStatus(Subsystem_M, (const char_T *)0);
/* block I/O */
/* exported global signals */
DataOut = 0.0;
SelectorSignal = FALSE;
/* states (dwork) */
/* exported global states */
SelectorState = FALSE;
/* external inputs */
DataIn1 = 0.0;
DataIn2 = 0.0;
Toggle_Init();
}
/* Model terminate function */
void Subsystem_terminate(void)
{
/* (no terminate code required) */
}The function-call subsystem export capabilities have the following limitations:
Real-Time Workshop options do not control the names of the files containing the generated code. All such filenames begin with the name of the exported subsystem. Each filename is suffixed as appropriate to the file.
Real-Time Workshop options do not control the names of top-level functions in the generated code. Each function name reflects the name of the signal that triggers the function, or for an unnamed signal, the block from which the signal originates.
This release cannot export reusable code for a function-call subsystem. Checking Configuration Parameters > Real-Time Workshop > Interface > Generate reusable code has no effect on the generated code for the subsystem.
This release supports code generation for ERT generated S-function blocks if the block does not have function-call input ports, but the ERT S-function block will appear as a noninlined S-function in the generated code.
This release supports an ERT generated S-function block in accelerator mode only if its function-call initiator is noninlined in accelerator mode. Examples of noninlined initiators include all Stateflow charts.
The ERT S-function wrapper must be driven by a Level-2 S-function initiator block, such as a Stateflow chart or the built-in Function-call Generator block.
An asynchronous (sample-time) function-call system can be exported, but this release does not support the ERT S-function wrapper for an asynchronous system.
This release does not support code generation for an ERT generated S-function block if the block was generated as a wrapper for exported function calls.
The output port of an ERT generated S-function block cannot be merged using the Merge block.
This release does not support MAT-file logging for exported function calls. Any specification that enables MAT-file logging is ignored.
The use of the TLC function LibIsFirstInit is deprecated for exported function calls.
The model_initialize function generated in the code for an exported function-call subsystem never includes a firstTime argument, regardless of the value of the model configuration parameter IncludeERTFirstTime. Thus, you cannot call model_initialize at a time greater than start time, for example, to reset block states.
| Automatic S-Function Wrapper Generation | Nonvirtual Subsystem Modular Function Code Generation | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |