This example shows how to associate subsystems in a model with function names and files.
Learn how to:
Specify function and file names in the generated code.
Identify the parts of the generated code that are required for integration.
Generate code for atomic subsystems.
Identify data that are required to execute a generated function.
For information about the example model and other examples in this series, see Prepare a Control Algorithm Model for C Code Generation.
The example models in Prepare a Control Algorithm Model for C Code Generation and Configure Data Interface in the Generated Code use virtual subsystems. Virtual subsystems visually organize blocks but do not affect the model functionality. Atomic subsystems evaluate the blocks included in a model as a unit. With atomic subsystems, you can specify additional function partitioning information. In a model, atomic subsystems appear with a bold border.
Open the example model rtwdemo_PCG_Eval_P3.
Save a copy of the model to a writable folder.
This example shows how to replace the virtual subsystems with function-call subsystems. Function-call subsystems:
Are atomic subsystems
Enable you to control subsystem execution order
Execute when a function call signal triggers
By controlling the execution order of the subsystems, you can match the model with an existing system that has a specific execution order.
The figure identifies the function call subsystems (1)
This version of the model contains the new subsystem
Execution_Order_Control (2), which contains a Stateflow® chart that models the calling functionality of a scheduler. The subsystem controls the execution order of the function call subsystems through function call signals (3). Later in this example, you examine how changing the execution order can change the simulation results.
This version of the model contains new Signal Conversion blocks (4) at the outputs of the PI controllers. With these additional blocks in place, the code generator can generate a single reentrant function for the PI controllers.
In Prepare a Control Algorithm Model for C Code Generation and Configure Data Interface in the Generated Code, the code generator creates a single
_step function that contains the control algorithm code. However, many applications require a greater level of control over the file placement of functions. By modifying the parameters of atomic subsystems, you can specify multiple functions within a single model.
The figure shows the subsystem parameters for
Treat as atomic unit
Enables other submenus. For atomic subsystems, this parameter is automatically selected and disabled.
Specifies a sample time for execution. Not available for function-call subsystems.
Function packaging options
Auto -- Determines how the subsystem appears in the generated code. This value is the default.
Inline -- Places the subsystem code inline with the rest of the model code.
Function -- Generates the code for the subsystem as a function.
Reusable function -- Generates a reusable (reentrant) function from the subsystem. The function passes all input and output data through formal parameters. The function does not directly access global variables.
Function name options
Reusable function for Function packaging enables function name options.
Auto -- Determines the function.
Use subsystem name -- Bases the function on the subsystem name.
User specified -- Applies the specified file name.
File name options
Reusable function for Function packaging enables file name options.
Auto -- Places the function definition in the module generated for the parent system, or, if the model root is the parent, in
Use subsystem name -- Generates a separate file. The name of the file is the name of the subsystem or library block.
Use function name -- Generates a separate file. The name of the file is the name that you specify with Function name options.
User specified -- Applies the specified, unique file name.
Function with separate data
Enabled when you set Function packaging to
Function. When selected, the code generator separates the internal data of the subsystem (for example, signals) from the data of the parent model. The subsystem owns this separate data.
Embedded Coder® supports reentrant code. Reentrant code is a reusable programming routine that multiple programs can use simultaneously. Reentrant code is used in operating systems and other system software that uses multithreading to handle concurrent events. Reentrant code does not maintain state data, so there are no persistent variables in the function. Calling programs maintain state variables and must pass the state data into the function. Multiple users or processes can share one copy of a reentrant function.
To generate reentrant code, you must first specify the subsystem as reusable by configuring the subsystem parameter Function packaging.
In some cases, the configuration of the model prevents reusable code. The table lists common issues.
Subsystem output feeds global signal Add a Signal Conversion block between the data subsystem and the global signal.
Generated function receives data Select Configuration Parameters > (formal parameters) through pointers Model Referencing > Pass fixed-size scalar root inputs by value for code generation.
Subsystem uses global signal data Use a port to pass the global data in and out in internal algorithm of the subsystem.
To define algorithmic parameter data (such as a gain or coefficient) outside the scope of a reusable library block or subsystem, you can apply a mask to the block or subsystem and create a mask parameter. You can then specify a different parameter value for each instance of the block or subsystem. Each mask parameter appears in the generated code as a formal parameter of the reentrant function.
In this version of the model, the subsystems
PI_ctrl_2 are masked. In each mask, the values of the
I gains are set by data objects such as
In Prepare a Control Algorithm Model for C Code Generation and Configure Data Interface in the Generated Code, you generate code at the root level of the model. Alternatively, you can build a specific subsystem.
To initiate a subsystem build, use the context menu. You can choose from these options:
Build This Subsystem: Treats the subsystem as a separate mode and creates the full set of source C files and header files. This option does not support function-call subsystems.
Generate S-Function: Generates C code for the subsystem and creates an S-Function wrapper. You can then simulate the code in the original model. This option does not support function-call subsystems.
Export Functions: Generates C code without the scheduling code that comes with the Build This Subsystem option. Use this option to build subsystems that use triggers, such as function-call subsystems.
Alternatively, open the Embedded Coder app, select the subsystem and on the C Code tab, click Build.
This example compares the files that are generated for the full system build with the files that are generated for exported functions. You also examine how the masked data appears in the code.
Run the build script for the three options. Then, examine the generated files by clicking the hyperlinks.
Full Build: Yes, Step function
Full Build: No
PI_ctrl_1: Yes, Trigger function
Full Build: No
Pos_Command_Arbitration: Yes, Init and Function
eval_data.c has different content in the full and export function builds. The full build includes all of the parameters that the model uses. The export function contains only the variables that the subsystem uses.
Masked Data in the Generated Code
In the file
rtwdemo_PCG_Eval_P3.c, the call sites of the reentrant function use the data objects
I_Gain_2 as arguments.
By default, Simulink® executes the subsystems in this order:
For this example, you can specify one of two alternative orders of execution. You can then use the test harness to observe the effect of the execution order on the simulation results. The subsystem
Execution_Order_Control has two configurations that control the execution order. To choose a configuration, use the subsystem context menu.
Change the execution order and observe the results.
The simulation results (throttle position over time) vary slightly depending on the order of execution. You can see the difference most clearly when the throttle request changes.
For the next example in this series, see Call External C Code from Model and Generated Code.