Integrating the Generated Code into the External Environment

This example shows the external build process, including required files and interfaces for calling generated code.

Time: 45 minutes



  • How to collect files required for building outside of Simulink®

  • How to interface with external variables and functions

Task: Open the model.Task: Open the model.

Building and Collecting the Required Data and Files

The code that Embedded Coder® generates is dependent on support files provided by MathWorks®. If you need to relocate generated code to another development environment, such as a dedicated build system, you must also relocate the required support files. You can automatically collect all generated and necessary support files and package them in a zip file by using the Simulink® Coder™ packNGo utility. This utility uses tools for customizing the build process after code generation, including a buildinfo_data structure, and a packNGo function to find and package all files needed to build an executable image, including external files you define in the Code Generation > Custom Code pane of the Configuration Parameters dialog. The files are packaged in a standard zip file. The buildinfo MAT-file is saved automatically in the directory model_ert_rtw.

The example model is configured to run packNGo automatically after code generation.

Task: Generate code for the full model.Task: Generate code for the full model.

To generate the zip file manually, do the following in the MATLAB® Command Window:

  1. Load the file buildInfo.mat (located in the subdirectory rtwdemo_PCG_Eval_P5_ert_rtw).

  2. Enter the command packNGo(buildInfo).

The number of files included in the zip file depends on the version of Embedded Coder® and the configuration of the model you use. Not all of the files in the zip file are required by the compiler. The compiled executable size (RAM/ROM) is dependent on the link process. The linker should be configured to include only required object files.

Background: Integrating the Generated Code into an Existing System

This module covers tasks required to integrate the generated code into an existing code base. For this evaluation, the Eclipse™ IDE and Cygwin™/gcc compiler are used. The required integration tasks are common to all integration environments.

Background: Overview of the Integration Environment

A full embedded controls system is comprised of multiple components, both hardware and software. Control algorithms are just one type of component. The other standard types of components include:

  • An operating system (OS)

  • A scheduling layer

  • Physical hardware I/O

  • Low-level hardware device drivers

In general, Embedded Coder® does not generate code for any of these components. Instead, it generates interfaces that connect with the components. MathWorks® provides hardware interface block libraries for many common embedded controllers. For examples, see the Embedded Targets block library located in the Embedded Coder® product.

For this evaluation, files are provided to show how you can build a full system. The main file is example_main.c. It is a simple main function that performs the basic actions required to exercise the code. It is not intended as an example of an actual application main.

Task: View example_main.c.Task: View example_main.c.

Functions of example_main.c include the following:

  • Defines function interfaces (function prototypes)

  • Includes required files for data definition

  • Defines extern data

  • Initializes data

  • Calls simulated hardware

  • Calls algorithmic functions

The order of execution of functions in example_main.c matches the order in which the subsystems are called in the test harness and in rtwdemo_PCG_Eval_P5.h. If you change the order of execution in example_main.c, results produced by the executable image will differ from simulation results.

Matching the System Interfaces

Integration requires matching both the Data and Function interfaces of the generated code and the existing system code. In this example, the example_main.c file defines the data through #includes and calls the functions from the generated code.

Matching Data Interfaces: Input Data Specification

The system has three input signals: pos_rqst, fbk_1, and fbk_2. The two feedback signals are imported externs (ImportedExtern) and the position signal is an imported extern pointer (ImportedExternPointer). Due to how the signals are defined, Simulink® Coder™ does not define (create) variables for them. Instead, the signal variables are defined in a file that is external to the MATLAB environment.

For the example, the file defineImportedData.c was created. This file is a simple C stub used to define the signal variables. The generated code has access to the data from the extern definitions in the file rtwdemo_PCG_Eval_P5_Private.h. In a real system, the data would come from other software components or from hardware devices.

Task: View defineImportedData.c.Task: View defineImportedData.c.

Task: View rtwdemo_PCG_Eval_P5_Private.h.Task: View rtwdemo_PCG_Eval_P5_Private.h.

Matching Data Interfaces: Output Data Specification

The system does not require you to do anything with the output data. However, you can access the data by referring to the file rtwdemo_PCG_Eval_P5.h.

The module Testing the Generated Code shows how the output data can be saved to a standard log file.

Task: View rtwdemo_PCG_Eval_P5.h.Task: View rtwdemo_PCG_Eval_P5.h.

Matching Data Interfaces: Accessing Additional Data

Embedded Coder® creates several data structures during the code generation process. For this example accessing these structures was not required. Examples of common data elements that users wish to access include:

  • Block state values (integrator, transfer functions)

  • Local parameters

  • Time

The following table lists the common Simulink® Coder™ data structures. Depending on the configuration of the model, some or all of these structures will appear in the generated code. In this example, the data is declared in the file rtwdemo_PCG_Eval_P5.h.

Data Type      Data Name     Data Purpose
Constants      |model_cP|    Constant parameters
Constants      |model_cB|    Constant block I/O
Output         |model_U|     Root and atomic subsystem input
Output         |model_Y|     Root and atomic subsystem output
Internal data  |model_B|     Value of block output
Internal data  |model_D|     State information vectors
Internal data  |model_M|     Time and other system level data
Internal data  |model_Zero|  Zero-crossings
Parameters     |model_P|     Parameters

Matching Function Call Interfaces

Functions generated by Simulink® Coder™ have a void Func(void) interface, by default. If the model or atomic subsystem is configured as reentrant code, Simulink® Coder™ creates a more complex function prototype. As shown below, the example_main function is configured to call the functions with the correct input arguments.

Calls to the function PI_Cntrl_Reusable use a mixture of user-defined variables and Simulink® Coder™ structures. The structures are defined in rtwdemo_PCG_Eval_P5.h. The preceding code fragment also shows how the structures can be mapped onto user-defined variables.

Building a Project in the Eclipse™ Environment

This example uses the Eclipse™ IDE and the Cygwin™ GCC debugger to build the embedded system. The installation files for both programs are provided as part of this example. Software components and versions numbers are:

  • Eclipse™ SDK - 3.2

  • Eclipse™ CDT - 3.3

  • Cygwin™/GCC - 3.4.4-1

  • Cygwin™/GDB - 20060706-2

Instructions on how to install and use Eclipse™ and GCC appear in Installing and Using Cygwin™ and Eclipse™.

To install the files for this module automatically, do the following:

Task: Automatically set up the build directory.Task: Automatically set up the build directory.

To manually install the files, do the following:

  1. Create a build directory (Eclipse_Build_P5).

  2. Unzip the file into your build directory.

  3. Delete the files, rtwdemo_PCG_Eval_P5.c, ert_main.c and rt_logging.c which are replaced by example_main.c.

*Note:* If code has not been generated for the model or the zip file
does not exist, complete the steps in the module *Building and
Collecting the Required Data and Files* before continuing to the next module.

You can use the Eclipse™ debugger to step through and evaluate the execution behavior of the generated C code. Testing the Generated Code includes an example on how to exercise the model with input data.

Further Study Topics

Was this topic helpful?