Manage File Packaging of Generated Code Modules

The code generator produces code modules. The file packaging configuration controls where the code generator places code into code modules and header files.

To locate and examine the generated code files, use the Code view or the HTML code generation report. The code generation report provides hyperlinks in the comments that you can click to view the generated code in a MATLAB^® web browser. For more information, see Traceability in Generated Code.

Generated Code Modules
User-Written Code Modules
Customize Generated Code Modules

Generated Code Modules

The code generator creates a build folder in your working folder to store generated source code. The build folder contains object files, a makefile, and other files created during the code generation process. The default name of the build folder is model_ert_rtw.

Code Modules and Header Files Affected by File Packaging summarizes the structure of source code that the code generator produces.

You can customize the generated set of files in several ways:

File packaging formats: Manage the number of source files generated for your model. Select model configuration parameter File packaging format. For more information, see Customize Generated Code Modules.
Nonvirtual subsystem code generation: Instruct the code generator to produce separate functions within separate code files for nonvirtual subsystems. You can control the names of the functions and of the code files. For more information, see Generate Subsystem Code as Separate Function and Files.
Storage classes: Define and use storage classes that partition generated data structures into different files based on file names that you specify. For more information, see Organize Parameter Data into a Structure by Using Struct Storage Class.
Module packaging: Direct the generated code into a required set of .c or .cpp and .h files, and control the internal organization of the generated files. For details, see Code Interface Configuration.

Code Modules and Header Files Affected by File Packaging

File	Description
`model.c` or `.cpp`	By default, contains entry points for code implementing the model algorithm (for example, `model_step`, `model_initialize`, and `model_terminate`). For information about how to change the file packaging of entry-point functions, see Control File Packaging of Generated Entry-Point Functions and Simulink Functions.
`model_private.h`	Contains local macros and local data that the model and subsystems require. This file is included in the `model.c` file as a `#include` statement. You do not need to include `model_private.h` when interfacing handwritten code to the generated code of a model.
`model.h`	Declares model data structures and a public interface to the model entry-points and data structures. Provides an interface to the real-time model data structure (`model_M`) with accessor macros. The code generator: Produces a separate header file for each Simulink Function block in a model. Includes `model.h` in the subsystem `.c` or `.cpp` files of a model. If you interface handwritten code to generated code for one or more models, include `model.h` for each of those models.
`model_data.c` or `.cpp`	Contains (if conditionally generated) the declarations for the parameters data structure, the constant block I/O data structure, and any zero representations for the model structure data types. If the model does not use these data structures and zero representations, `model_data.c` or `.cpp` is not generated. These structures and zero representations are declared `extern` in `model.h`.
`model_types.h`	Provides forward declarations for the real-time model data structure and the parameters data structure. Function declarations of reusable functions can require these declarations. Provides type definitions for user-defined types that the model uses.
Certain utility files such as `rt_nonfinite.c`, `rt_nonfinite.h`, `rt_zcfcn.c`, and `rt_zcfcn.h`	Utility files that support fixed-point arithmetic operations or that define zero-crossing functions. Other utility files are not affected by file packaging and are instead affected by the Shared code placement model configuration parameter. The code generator generates utility code if the model contains blocks that require it.

User-Written Code Modules

Code that you write to interface with generated model code usually includes a customized main module. Base this module on a main program produced by the code generator. This customized main module can also include interrupt handlers, device driver blocks and other S-functions, and other supervisory or supporting code. Steps to set up the development environment to support a customized main module include:

Establish a working folder for your own code modules.
Put your working folder on the MATLAB path.
At minimum, inform the build process about the location of your source and object files with model configuration parameter Additional build information.
Your development process could require generating code for a particular microprocessor or development board and deploying the code on target hardware with a cross-development system. To accomplish these goals, make more extensive modifications to the ERT-based system target file.

For information on how to customize your ERT-based system target file for your production requirements, see Custom Software for Target Hardware.

Customize Generated Code Modules

Model configuration parameter File packaging format specifies how the code generator packages generated source code into files. You can set the parameter to Modular, Compact (with separate data file), and Compact. This table describes the generated files and the removed files for each file packaging format.

Generated Files According to File Packaging Format

File Packaging Format Generated Files Removed Files

File Packaging Format	Generated Files	Removed Files
`Modular` (default)	`model.c` subsystem files (optional) user-defined files that contain Simulink functions and entry-point functions (optional) `model.h` `model_types.h` `model_private.h` `model_data.c` (conditional) Utility files that support nonfinite values or that define zero-crossing functions, such as `rt_nonfinite.c`, `rt_nonfinite.h`, `rt_zcfcn.c`, and `rt_zcfcn.h`	None
`Compact (with separate data file)`	`model.c` `model.h` `model_data.c` (conditional)	`model_private.h` `model_types.h` (conditional, see Removed Files According to File Packaging Format) Utility files that support nonfinite values or that define zero-crossing functions, such as `rt_nonfinite.c`, `rt_nonfinite.h`, `rt_zcfcn.c`, and `rt_zcfcn.h`
`Compact`	`model.c` `model.h`	`model_data.c` `model_private.h` `model_types.h` (conditional, see Removed Files According to File Packaging Format) Utility files that support nonfinite values or that define zero-crossing functions, such as `rt_nonfinite.c`, `rt_nonfinite.h`, `rt_zcfcn.c`, and `rt_zcfcn.h`

Modular (default)

model.c

subsystem files (optional)

user-defined files that contain Simulink functions and entry-point functions (optional)

model.h

model_types.h

model_private.h

model_data.c (conditional)

Utility files that support nonfinite values or that define zero-crossing functions, such as rt_nonfinite.c, rt_nonfinite.h, rt_zcfcn.c, and rt_zcfcn.h

None

Compact (with separate data file)

model.c

model.h

model_data.c (conditional)

model_private.h

model_types.h (conditional, see Removed Files According to File Packaging Format)

Utility files that support nonfinite values or that define zero-crossing functions, such as rt_nonfinite.c, rt_nonfinite.h, rt_zcfcn.c, and rt_zcfcn.h

Compact

model.c

model.h

model_data.c

model_private.h

model_types.h (conditional, see Removed Files According to File Packaging Format)

Utility files that support nonfinite values or that define zero-crossing functions, such as rt_nonfinite.c, rt_nonfinite.h, rt_zcfcn.c, and rt_zcfcn.h

This table describes content placement from the removed files.

Removed Files According to File Packaging Format

Removed File	Generated Content In File
`model_private.h`	`model.c` and `model.h`
`model_types.h`	`model.h`
`model_data.c`	`model.c`

You can specify a different file packaging format for each referenced model.

Model configuration parameter Shared code placement interacts with file packaging operations. If you set Shared code placement to Shared location, the code generator produces separate files for utility code in a shared location, regardless of the file packaging format. If you set Shared code placement to Auto, the code generator generates code for utilities according to the file packaging format selection.

Modular: Some shared utility files are in the build folder.
Compact (with separate data file): Utility code is generated in model.c.
Compact: Utility code is generated in model.c.

File packaging formats Compact and Compact (with separate data file) generate model_types.h for models containing:

A Variant Subsystem block. The model_types.h file includes preprocessor directives defining the variant objects associated with a variant block.
Storage classes generating a separate header file.

File packaging formats Compact and Compact (with separate data file) are not compatible with:

A model containing a subsystem, which is configured to generate separate source files
A model containing a noninlined S-function
A model for which Shared code placement is set to Auto, which uses data objects for which Data scope is set to Exported

Note

The File packaging format parameter does not impact Stateflow^® charts in which you select the Treat exported functions as globally visible parameter. These exported functions are global and shared by other source files. Therefore, the functions must produce headers with function declarations, which other source files can include.