|
|
|
| R2011b Documentation → Embedded Coder | |
Learn more about Embedded Coder |
|
| Contents | Index |
Specify function and file names in generated code.
Exert direct control over the execution order of model components.
Identify parts of generated code used for integration.
Generate code for atomic subsystems.
Know what data you need to execute a generated function.
Understand basic model architecture.
Understand the difference between types of subsystems — see Systems and Subsystems in the Simulink documentation.
Understand the purpose of function-call subsystems.
Understand what reentrant code is.
Familiarity with the Subsystem Parameters dialog box.
Familiarity with the Mask Parameters dialog box.
Familiarity with different ways to generate code for subsystems.
Able to read C code.
rtwdemo_throttlecntrl_funcpartition.mdl
rtwdemo_throttlecntrl_testharnessert.mdl
To match the behavior of a physical system, you might have to exert direct control over the execution order of model components. One way of controlling execution order is to use function-call subsystems and a Stateflow chart that models the calling functionality of a scheduler.
The example throttle controller model includes virtual subsystems. This tutorial shows you how to replace the virtual subsystems with function-call subsystems, and use them to control subsystem execution order.
Open rtwdemo_throttlecntrl_funcpartition.mdl. Save a copy as throttlecntrl_funcpartition.mdl in a writable location on your MATLAB path.
This version of the throttle controller model includes three function-call subsystems and a subsystem consisting of a Stateflow chart, which controls execution order of the other subsystems.
Examine the function-call subsystems PI_ctrl_1, PI_ctrl_2, and Pos_Command_Arbitration.
Examine the Stateflow chart subsystem Execution_Order_Control. This subsystem controls the execution order of the function-call subsystems. Later in the tutorial, you see how changing execution order can change simulation results.
Examine the new Signal Conversion blocks for output ports pos_cmd_one and pos_cmd_two of the PI controllers. The Contiguous copy setting for the Output block parameter makes it possible for the PI controller functions in the generated code to be reentrant.
Close the model.
So far, the code generator has produced a model_step function, which contains all control algorithm code for the throttle controller model. However, many applications require a greater level of control over the location of functions in the generated code. By using atomic subsystems, you can instruct the code generator to partition algorithm code across multiple functions. You specify the partitioning by modifying parameters in the Subsystem Parameters dialog box for each subsystem.
Open your copy of the throttle controller model, throttlecntrl_funcpartition.mdl.
Open the Subsystem Parameters dialog box for subsystems PI_ctrl_1 and PI_ctrl_2. Examine the parameter settings.
Right-click the subsystem and select Subsystem Parameters. The Function Block Parameters dialog box opens.
On the Main tab, Treat as atomic unit is selected. This parameter is automatically selected and unavailable for atomic subsystems. When set, this parameter causes Simulink software to treat block methods associated with a subsystem as a unit when determining execution order. The parameter provides a way to group functional aspects of a model at the execution level. This parameter enables parameters on the Code Generation tab.
Click the Code Generation tab.
Note the following parameter settings:
| Parameter | Rationale for Setting |
|---|---|
| Function packaging | Reusable function causes the code generator to produce reentrant code for the subsystem. Reentrant code is a reusable programming routine that multiple programs can use simultaneously. Operating systems and other system software that use multithreading to handle concurrent events use reentrant code. Reentrant code does not maintain state data. No persistent variables are in the function. Calling programs maintain state variables and pass them into the function. Any number of users or processes can share one copy of a reentrant routine |
| Function name options | User Specified enables you to specify a unique name for the generated function. |
| Function name | Enables you to name the function that the code generator produces for a subsystem. In this case, the code generator names the reusable function PI_Cntrl_Reusable. |
| File name options | Use function name causes the code generator to place the generated function in a separate file and name it with the same name as the generated function. In this case, the code generator places the function in the model build folder in the file the PI_Cntrl_Reusable.c. |
Open the Subsystem Parameters dialog box for subsystem Pos_Command_Arbitrationand examine the parameter settings. Treat as atomic unit on the Main tab is already selected. The following table provides the rationale for the parameter settings on the Code Generation tab.
| Parameter | Rationale for Setting |
|---|---|
| Function packaging | Function causes the code generator to produce a separate function that is not reentrant and has no arguments. |
| Function name options | Auto assigns the generated function a unique name using the default convention model_subsystem(). model is the name of the model and subsystem is the name of the subsystem. In this case, the function name is throttlecntrl_funcpartition_Pos_Command_Arbitration. |
| File name options | Auto causes the code generator to place the function code in the throttlecntrl_funcpartition.c file. |
Open the Subsystem Parameters dialog box for subsystem Execution_Order_Controland examine the parameter settings. For this subsystem, the Treat as atomic unit parameter is not set, restricting Function packaging to Function only.
Close the model.
For more information, see Subsystem.
Subsystem masks enable Simulink software to define subsystem parameters outside the scope of a library block. By changing the parameter value at the top of the library, you can reuse the same library with multiple sets of parameters within the same model.
When a subsystem is reusable and has a mask, the generated code passes the masked parameters into the reentrant code as arguments. Code generation software fully supports the use of data objects in masks. The data objects are used in the generated code.
Examine the masks for subsystems PI_ctrl_1 and PI_ctrl_2.
Open your copy of the throttle controller model, throttlecntrl_funcpartition.mdl.
Open the Mask Parameters dialog box for subsystem PI_ctrl_1 by double-clicking the subsystem. The dialog box opens, showing data objects for gain parameters P_gain and I_gain.
Open the Mask Parameters dialog box for subsystem PI_ctrl_2. For this subsystem, Simulink creates two new data objects, P_Gain_2 and I_Gain_2.
Close the Mask Parameters dialog boxes and the model.
The code generator can build code at the system (full model) and subsystem levels. Compare the files generated for the full model build with files generated for exported functions.
Open your copy of the throttle controller model, throttlecntrl_funcpartition.mdl.
Generate code for the model.
Export a function for the PI_ctrl_1 subsystem.
In the model window, right-click PI_ctrl_1 and select Code Generation > Export Functions. The Build code for Subsystem dialog box opens.
In the Build code for Subsystem dialog box, click Build. The code generator produces a complete set of code files for the subsystem and places them in the build folder PI_ctrl_1_ert_rtw.
If you have a Stateflow license, export a function for the Pos_Command_Arbitration subsystem. The code generator produces a complete set of code files for the subsystem and places them in the build folder Pos_Command_Arbitration_ert_rtw.
Examine the generated code listed in the following table by locating and opening the files in the respective build folders.
| File | Full Build | PI_ctrl_1 | Pos_Command_Arbitration (requires Stateflow license) |
|---|---|---|---|
| throttlecntrl_funcpartition.c | Yes Step function | No | No |
| PI_ctrl_1.c | No | Yes Trigger function | No |
| Pos_Command_Arbitration.c (requires Stateflow license) | No | No | Yes Initialization and Function |
| PI_Ctrl_Reusable.c | Yes Called by main | Yes Called by PI_ctrl_1 | No |
| ert_main.c | Yes | Yes | Yes |
| eval_data.c | Yes* | Yes* | No Eval data not used in diagram |
* The content of eval_data.c differs between the full model and export function builds. The full model build includes all parameters that the model uses while the export function contains only variables that the subsystem uses.
Close all dialog boxes and the model.
Open throttlecntrl_funcpartition.c.
Search for PI_Cntrl_Reusable. The function call shows how the code generator passes data objects (P_Gain and I_Gain) from the subsystem masks into the reentrant code.
PI_Cntrl_Reusable(pos_rqst, fbk_1, &throttlecntrl_funcpartiti_DWork_DWork->PI_ctrl_1, I_Gain, P_Gain);
Search for PI_Cntrl_Reusable again. The second function call passes data objects from the mask for subsystem PI_ctrl_2.
PI_Cntrl_Reusable(pos_rqst, fbk_2, &throttlecntrl_funcpartiti_DWork->PI_ctrl_2, I_Gain_2, P_Gain_2);
Close the C code file.
Without explicit control, subsystems in model throttlecntrl_funcpartition execute in the following order:
PI_ctrl_1
PI_ctrl_2
Pos_Cmd_Arbitration
You can use the test harness to see the effect of the execution order on the simulation results. The Execution_Order_Control subsystem is set up so that you can switch between two configurations, which change the execution order of the other subsystems in the model.
Change the execution order.
Open your copy of the throttle controller model, throttlecntrl_funcpartition.mdl.
Right-click the Execution_Order_Control subsystem. Select Block Choice > PI_1_then_PI_2_then_Pos_Cmd_Arb to set the subsystem execution order to PI_ctrl_1, PI_ctrl_2, then Pos_cmd_Arbitration.
Save the model.
Open the test harness model, throttlecntrl_testharnessert.mdl.
Set up the test harness to use model throttlecntrl_funcpartition as the unit under test.
Right-click the Unit_Under_Test Model block and select Model Reference Parameters.
Set Model name to throttlecntrl_funcpartition and click OK.
Update the model diagram.
Run the test harness.
The resulting plot shows that the difference between the golden and simulated versions of the model remains zero.
In the model throttlecntrl_funcpartition, change the execution order to Pos_cmd_Arbitration_then_PI_1_then_PI_2, update the model diagram, and save the model.
Run the test harness again.
A slight variation exists in the output results depending on the order of execution. The difference is most noticeable when the desired input changes.
Close the throttle controller and test harness models.
One way of controlling execution order of subsystems during simulation is to use function-call subsystems and a Stateflow chart that models the calling functionality of a scheduler.
For atomic subsystems, you can instruct the code generator to partition algorithm code across multiple functions.
When partitioning code across multiple functions, you can specify the name of the function for each subsystem and the name of the separate file for the code with parameters in the Subsystem Parameters dialog box.
When a subsystem is reusable and has a mask, the generated code passes the masked parameters into the reentrant code as arguments.
The code generator can build code at the system (full model) and subsystem levels.
At the subsystem level, the code generator produces a full set of generated files in a separate build folder.
You can change the execution of a model by using a subsystem containing a Stateflow chart that models the calling functionality of a scheduler and changing the setting of the Block Choice option on the subsystem's context menu.
S-Function Code Insertion in the Simulink Coder documentation
Exporting Function-Call Subsystems in the Embedded Coder documentation
Function Prototype Control in the Embedded Coder documentation
Working with Block Masks in the Simulink documentation
 | Configuring Data Interface | Integrating Generated Code into External Environment |  |
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 |
