Integrate External Application Code with Code Generated from PID Controller

Inspect Model to Assess Project Requirements

Open the example model ex_ext_ctrl_alg.

open_system('ex_ext_ctrl_alg')

The blocks in the model implement the PID controller algorithm. The module takes the filtered sensor data and passes the signal to a Discrete-time PID Controller block with Parallel form. For each input, the module outputs the weighted sum of the input signal, the integral of the input signal, and the derivative of the input signal. The weights are the proportional, integral, and derivative gain parameters. For more information, see Discrete PID Controller.

To complete the application, you must generate code using a service interface configuration to perform the function of the ex_ext_ctrl_alg module that the model represents.

The figure below shows the intended flow of data through the three modules in the system. Notice that the three modules are all called from ext_code_main.c. The figure also shows the code files that define and declare the data (global variables) that cross the module boundaries.

Inspect External Code to Assess Project Requirements

Run the script prepare_ext_code. The script copies external code files into several folders.

exampleFolder = pwd;
run('prepare_ext_code.m');

Open ext_code_main.c. This application code represents an embedded system with a trivial scheduling algorithm (a while loop) and three modules that include algorithms that run in every execution cycle: ex_ext_inputs_proc, ex_ext_ctrl_alg, and ex_ext_outputs_proc.

type('ext_code_main.c')

#include <stddef.h>
#include "ex_ext_inputs_proc.h"
#include "ex_ext_ctrl_alg.h"
#include "ex_ext_outputs_proc.h"
#include <stdio.h>
#include <string.h>
               
int numCycles = 0;

int main()
{

  ex_ext_ctrl_alg_initialize();

  do {
        ex_ext_inputs_proc();
        ex_ext_ctrl_alg_step();
        ex_ext_outputs_proc();
		numCycles = numCycles + 1;
		printf("At cycle %d, out1 is %f and out2 is %f.\n", numCycles, out1, out2);
  } while (numCycles <= 50);

  return 0;
}

In the shared folder (exampleFolder/shared), in ex_ext_projTypes.h, notice the two custom data types (typedef) that the data in the modules use.

typedef double dataPath_flow_T;

typedef double dataPath_temp_T;

In the io_drivers folder (exampleFolder/io_drivers), in ex_sensor_accessors.c, notice the functions get_fromSensor_flow and get_fromSensor_temp, which return raw data recorded by flow and temperature sensors. For this example, the functions return trivial sinusoidal stimuli for the control algorithm.

dataPath_flow_T get_fromSensor_flow(void) {

/* Return a trivial value for this "sensor" */

return sin(numCycles);

};

dataPath_temp_T get_fromSensor_temp(void) {

/* Return a trivial value for this "sensor" */

return cos(numCycles);

};

In the ex_ext_inputs_proc folder (exampleFolder/ex_ext_inputs_proc), in ex_ext_inputs_proc.c, the ex_ext_inputs_proc module reads the sensor data (by calling the accessor functions), filters the data, and stores it in two global variables, PROC_INPUT_FLOW and PROC_INPUT_TEMP. These global variables are defined in ex_ext_proc_inputs.c and declared in ex_ext_proc_inputs.h.

dataPath_flow_T PROC_INPUT_FLOW;

dataPath_temp_T PROC_INPUT_TEMP;

The filter algorithm in this module and the algorithms in the other two modules require state data, which must persist between execution cycles of the application. Each module stores relevant state data as global variables. For example, in the ex_ext_inputs_proc module, ex_ext_inputs_proc.c defines these variables:

The empty ex_ext_ctrl_alg folder is a placeholder for the generated code. The ex_ext_ctrl_alg module must perform PID control on the filtered flow and temperature measurements.

In the ex_ext_outputs_proc folder (exampleFolder/ex_ext_outputs_proc), in the file ex_ext_outputs_proc.c, the ex_ext_outputs_proc module reads the PID output signals from global variables named CONTR_SIG_FLOW and CONTR_SIG_TEMP. The ex_ext_ctrl_alg module (the generated code) must define these variables. The ex_ext_ctrl_alg module filters these signals and passes the filtered values to functions that represent device drivers for actuators (for example, a valve and a heater filament).

/* Filter algorithm for flow control. */

flowFilterOut_tmp_data = (CONTR_SIG_FLOW - 1.92 *

flowFilterOut_state_data) / 1.78;

/* Write filtered control output to flow valve. */

set_toActuator_flow(2.15 * flowFilterOut_tmp_data);

/* Filter algorithm for temperature. */

tempFilterOut_tmp_data = (CONTR_SIG_TEMP - 1.95 *

tempFilterOut_state_data) / 2.11;

/* Write filtered control output to heater filament. */

set_toActuator_temp(1.65 * tempFilterOut_tmp_data);

The actuator functions are defined in the io_drivers folder in the file ex_actuator_accessors_c.

To perform the function of the control algorithm module and integrate with the external code, the generated code must:

Inspect and Customize Default Service Interfaces in a Coder Dictionary

You address the external code requirements by defining a service code interface configuration in a shared Embedded Coder Dictionary. This example generates code from a component model that uses a C service code interface configuration. Model data elements are mapped to service interfaces defined in the Embedded Coder Dictionary. This example shows how to customize the default service interfaces and define new service interfaces in a dictionary.

For more information, see C Service Interfaces and Embedded Coder Dictionary.

Create a Shared Embedded Coder Dictionary

For this example, to meet the code interface requirements listed in Inspect Model to Assess Project Requirements and Inspect External Code to Assess Project Requirements, make these adjustments:

Consider removing service interface entries that are not used by selecting the trash can icon next to each unused service interface listed in the middle column of the dictionary.

For more information, see Code Interface Definitions.

Configure Model to Use Custom Data Types

Set your current folder to the shared folder.

Use the function Simulink.importExternalCTypes to generate Simulink.AliasType objects that represent the custom data types dataPath_flow_T and dataPath_temp_T.

cd('shared');
Simulink.importExternalCTypes('ex_ext_projTypes.h');

The objects appear in the base workspace.

Update the block diagram. The diagram shows that, due to data type inheritance and propagation, signals in the model use a custom data type.

Configure Code Interface to Use Constant Parameters

To apply a storage class to the parameters represented by Constant blocks Flow Setpt and Temp Setpt, use the Model Explorer to create Simulink.Parameter objects to represent the data. Create two model workspace parameters.

Configure Naming Rules for Variables

In the external code, internal data that does not participate in the module interfaces, such as state data and local variables in functions, conform to naming schemes. In the model, configure internal data that appears in the generated code to align with the external code naming schemes.

1. In the model Configuration Parameters dialog box, open the Code Generation > Identifiers pane.

2. Set Global variables to naming rule $R$N_data$M. This setting controls the names of global variables, such as those that represent state data. The naming rule $R$N_data_$M most closely approximates the scheme that the state variables in the external code use. In the naming rule:

3. Set Local temporary variables and Local block output variables to $N_local$M.

Configure Organization of Code in Generated Files

To match the organization of the files in the example external code, use the example template file ex_my_code_template.cgt. The template governs the organization and appearance of code in each generated file. For example, the template organizes similar code constructs into named sections (delimited by comments) and, at the top of the template, specifies minimal information about each generated file.

1. Copy ex_my_code_template.cgt to the ex_ext_ctrl_alg folder.

cd(exampleFolder);
copyfile("ex_my_code_template.cgt","ex_ext_ctrl_alg");

2. In the model Configuration Parameters dialog box, open the Code Generation > Templates pane.

3. Under Code templates and Data templates, set parameters Sourc file template and Header file template to ex_my_code_template.cgt.

Configure Model Service Code Interfaces for Code Generation

You determine whether to deploy your top model as an application or component based on the requirements for your project. In this example, the external code defines the requirements for the generated code in order to successfully integrate. Component deployment requires integration of generated function code with an external function scheduler and other target environment software. For this example, deploy the model as a component. For more information, see Deploy Generated Software.

For the code generator to produce interface code that aligns with the target environment requirements, there needs to be a mapping between the interface elements in the model and code interfaces. For this example, the code generator applies a service interface because the model is attached to shared Embedded Coder Dictionary PIDControllerDictionary.sldd, which defines a service interface configuration. The code generator uses the attached dictionary to establish default mappings that you can view and change by using the Code Mappings Editor or code mappings programming interface.

To open the Code Mappings editor and explore the interface settings, in the Embedded Coder app, under Code Interface, select Component Interface.

For this example, to meet the code interface requirements listed in Inspect Model to Assess Project Requirements and Inspect External Code to Assess Project Requirements, make these adjustments:

For more information, see Code Mappings Editor – C.

Assess Model Readiness for Component Deployment Using a Service Interface Configuration

Run the Simulink Model Advisor to confirm that the component model passes component modeling guideline and service interface configuration checks.

If the checks do not pass, use the information provided to correct the conditions reported.

For more information, see Modeling Guidelines for Generated Code and Model Readiness for Code Generation.

Generate and Inspect Service Interface Code

Because the external code defines a main function, select model configuration parameter Generate code only and clear parameter Generate an example main program.

set_param('ex_ext_ctrl_alg','GenCodeOnly','on');
set_param('ex_ext_ctrl_alg','GenerateSampleERTMain','off');

Generate code from the model.

slbuild('ex_ext_ctrl_alg');

### Starting build procedure for: ex_ext_ctrl_alg
### Successful completion of code generation for: ex_ext_ctrl_alg

Build Summary

Top model targets built:

Model            Action           Rebuild Reason                                    
====================================================================================
ex_ext_ctrl_alg  Code generated.  Code generation information file does not exist.  

1 of 1 models built (0 models already up to date)
Build duration: 0h 0m 21.398s

Use the Code Interface Report to inspect and verify that the generated code follows requirements. The Code Interface Report documents the generated code interface including model entry-point functions and services. The code interface information helps you to review the generated code and integrate it with other code.

For more information, see Analyze Generated Service Code Interface Report.

Integrate Generated Service Interface Code with Target Environment Code

Generated code will be placed into the folder ex_ext_ctrl_alg_ert_rtw.

To integrate the generated component code with a main function and other target environment code, you must:

In this example, make these adjustments to connect input and output data:

Function and variable names in the external code match with function and variable names in the generated code as a result of the naming rules defined in the coder dictionary.

Create an instance of the code descriptor object to get additional information about the service interface and use the results to confirm that generated interfaces meet integration requirements.

codeDescObj = coder.getCodeDescriptor('ex_ext_ctrl_alg');
serviceObj = codeDescObj.getServices();

For example, to retrieve the name of the header file that contains the service interface prototypes, use the getServicesHeaderFileName method. The code generator returns a character vector that represents the header file name.

serviceHeaderFile = getServicesHeaderFileName(serviceObj)

serviceHeaderFile = 
'services.h'

For more information about commands to retrieve metadata about service interfaces, see Get Metadata About Service Interface.