Atomic and Virtual Subsystems

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.

View Changes in Model Architecture

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:

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) PI_ctrl_1, PI_ctrl_2, and Pos_Command_Arbitration.

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.

Control Function Location and File Placement in the Generated Code

In Prepare a Control Algorithm Model for C Code Generation and Configure Data Interface in the Generated Code, the code generator creates a single model_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 PI_ctrl_1.

Treat as atomic unit

Sample time

Function packaging options

Function name options

File name options

Function with separate data

Generate Reentrant Code

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.

Cause                                     Solution

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.

Use a Mask to Pass Parameter Values into Library 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_1 and PI_ctrl_2 are masked. In each mask, the values of the P and I gains are set by data objects such as I_Gain_2 and P_Gain_2.

Generate Code for Atomic Subsystem

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:

Alternatively, open the Embedded Coder app, select the subsystem and on the C Code tab, click Build.

Examine Generated Code

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.

rtwdemo_PCG_Eval_P3.c

PI_ctrl_1.c

Pos_Command_Arbitration.c

PI_Ctrl_Reusable.c

ert_main.c

eval_data.c

(1) 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 P_Gain, I_Gain, P_Gain_2, and I_Gain_2 as arguments.

Effect of Execution Order on Simulation Results

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.