Manage Build Process Files - MATLAB & Simulink (original) (raw)

Main Content

To apply generated code source and header files from the build process, it is helpful to understand the files that the build process generates and the conditions that control file generation. This information provides access to generated code resources, such as:

The code generator creates _`model`_.* files during the code generation and build process. You can customize the filenames for generated header, source, and data files. For more information, see Customize Generated File Names. The code generator creates additional folders and dependency files to support shared utilities and model references. For more information about the folders that the build process creates, see Manage Build Process Folders. For an example that shows how to use a project to manage build process folders, see Generate Code and Simulate Models in a Project.

Depending on model architectures and code generation options, the build process for a GRT-based system target file can produce files that the build process does not generate for an ERT-based system target file. Also, for ERT-based system target files, the build process packages generated files differently than for GRT-based system target files. See Manage File Packaging of Generated Code Modules.

Note

By default, the build process deletes foreign (not generated) source files in the build folder. It is possible to preserve foreign source files in the build folder by following the guidelines in Preserve External Code Files in Build Folder.

The table describes the principal generated files. Within the generated filenames shown in the table, the model represents the name of the model for which you are generating code. The subsystem represents the name of a subsystem within the model. When you select the Create code generation report parameter, the code generator produces a set of HTML files. There is one HTML file for each source file plus a_model__contents.html index file in thehtml subfolder within your build folder. The source and header files in the table have dependency relationships. For descriptions of other file dependencies, seeManage Build Process File Dependencies and Add Build Process Dependencies.

File Description
builtin_typeid_types.h Defines an enumerated type corresponding to built-in data types.A model build generates this file when one or more of these conditions apply:Your model contains a Stateflow chart that uses messages.Your model configuration enables .Your model configuration enables C API options in > .
model.bat Contains Windows® batch file commands that set the compiler environment and invoke themake utility.For more information about using this file, see model.bat.
model.c_model_.cpp Corresponds to the model file. The file contains: Include files model.h and_model__private.h Data, except data placed in_model__data.c Model-specific scheduler codeModel-specific solver codeModel registration codeAlgorithm codeOptional GRT wrapper functions
model.exe (Windows platform)model (UNIX® and Macintosh platforms) Executable program file. A model build generates this file unless you explicitly specify that the code generator produce code only. The build generates the executable in the current folder (not the build folder) under control of the make utility of your development system.
model.h Defines 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_rtM) via access macros.Subsystem .c or .cpp files in the model include model.h. This file includes:Exported Simulink® data symbolsModel data structures, including rtMModel entry-point functions, except those for which you specify a filename in the Embedded Coder Dictionary. For more information, see Control File Packaging of Generated Entry-Point Functions and Simulink Functions.For more information, see model.h.
model.mk Generated makefile that controls compiling and linking the generated code into the final binary file by the make utility of your development system. If you set theMAKEFLAGS environment variable, do not select options with this variable that conflict with the current make utility used by the build process.
model.rtw Represents the compiled model. By default, the build process deletes this ASCII file when the build process is complete. You can choose to retain the file for inspection.
model_capi.h_model__capi.c Contain data structures that describe the model signals, states, and parameters without using external mode. For more information, see Write External Code to Access Generated C API Code.
model_data.c Contains (if conditionally generated) declarations for the parameters data structure and the constant block I/O data structure, and zero representations for structure data types that the model uses. A model build generates this file when the model uses these data structures. The extern declarations for structures appear in_model_.h. When present, this file contains: Constant block I/O parametersInclude files model.h and_model__private.h Definitions for the zero representations for user-defined structure data types that the model usesConstant parameters
model_dt.h Declares structures that contain data type and data type transition information for generated model data structures for supporting external mode.
model_private.h Contains local define constants and local data for the model and subsystems. The generated source files from the model build include this file. When you interface external code with generated code from a model, include model_private.h. The file contains: Imported Simulink data symbolsStateflow® entry pointsSimulink Coder™ details (various macros, enums, and so forth, that are private to the code)For more information, see Manage Build Process File Dependencies.
model_reference_types.h Contains type definitions for timing bridges. A model build generates this file for a referenced model or a model containing model reference blocks.
model_targ_data_map.m Contains MATLAB® language commands that external mode uses to initialize the external mode connection.
model_types.h Provides forward declarations for the real-time model data structure and the parameters data structure. The generated header files from the model build include this file. Function declarations of reusable functions can use these structures.
multiword_types.h Contains type definitions for multiple-word wide data types and their word-size chunks. If your code uses multiword data types, include this header file.A model build generates this file when one or more of these conditions apply: Your model uses multiword data types. Your model configuration enables .Your model configuration enables > > .
rtGetInf.crtGetInf.hrtGetNaN.crtGetNaN.hrt_nonfinite.crt_nonfinite.h Declares and initializes global nonfinite values forinf, minus inf, and nan. Provides nonfinite comparison functions. A model build generates these files when one or more of these conditions apply: The model contains S-functions.The generated code from the model requires nonfinite numbers.Your model configuration enables .
rtmodel.h Contains #include directives required by static main function modules such as rt_main.c.The build process does not create these modules at code generation time. The modules includertmodel.h to access model-specific data structures and entry points. If you create your own main program module, make sure to includertmodel.h.
rtwtypes.h Provides type definitions, #define statements, and enumerations. For ERT system target files, the code generator createsrtwtypes.h only if one of these conditions applies: Data type replacement is set toUse coder typedefs.Data type replacement is set toUse C data types with fixed-width integers andCoder typedefs compatibility is selected. If you use legacy custom code or static source files (undermatlabroot) that require Simulink Coder data type definitions, the settings force the generation ofrtwtypes.h.For ERT-based system target files that do not generate a GRT interface and do not have noninlined S-functions, rtwtypes.h does not include simstruc_types.h. For more information, see rtwtypes.h and Manage Build Process File Dependencies.
rtw_proj.tmwsl_proj.tmw Marker files. The build process generates these files to help the make utility determine when to recompile and link the generated code.
rt_defines.h Contains type definitions for special mathematical constants (such as π and_e_) and defines the UNUSED_PARAMETER macro.A model build generates this file when the generated code requires a mathematical constant definition or when the function body does not access a required model function argument.
rt_sfcn_helper.hrt_sfcn_helper.c Provide functions that the noninlined S-functions use in a model.The noninlined S-functions use functions rt_CallSys,rt_enableSys, and rt_DisableSys to call downstream function-call subsystems.
subsystem.c Contains C source code for each noninlined nonvirtual subsystem when the subsystem is configured to place code in a separate file.
subsystem.h Contains exported symbols for noninlined nonvirtual subsystems.
__cf_ model.h Serves as a constant obfuscator and is generated when: slbuild uses the ObfuscateCode name-value argument.You build a model that references a protected model, previously created by using Protected Model Creator withContent type set to Obfuscated source code or Binaries. The obfuscated code uses random identifiers to disguise constants. The file contains #define statements that correspond to the random identifiers, which links the identifiers to the constant values.

model.bat

This file contains Windows batch file commands that set the compiler environment and invoke themake utility.

If you are using the toolchain approach for the build process, you also can use this batch file to extract information from the generated makefile,_`model`_.mk. The information includes macro definitions and values that appear in the makefile, such as CFLAGS (C compiler flags) and CPP_FLAGS (C++ compiler flags). With the folder containing _`model`_.bat selected as the current working folder, in the Command Window, type:

system('model.bat info')

On UNIX and Macintosh platforms, the code generator does not create the_`model`_.bat file. To extract information for toolchain approach builds from the generated makefile on these systems, in the Command Window, type:

system('gmake -f model.mk info')

model.h

The header file _`model`_.h declares model data structures and a public interface to the model entry points and data structures. This header file also provides an interface to the real-time model data structure (_`model`__M) by using access macros. If your code interfaces to model functions or model data structures, include_`model`_.h:

#ifndef rtmGetSampleTime

define rtmGetSampleTime(rtm, idx)

((rtm)->Timing.sampleTimes[idx])
#endif

To generate model entry-point functions in files other than_`model`_.h and_`model`_.c, use a function customization template in the Embedded Coder Dictionary. For more information, see Configure Default C Code Generation for Categories of Data Elements and Functions.

The main.c (or .cpp) file includes_`model`_.h. If the model build generates themain.c (or .cpp) file from a TLC script, the TLC source can include _`model`_.h.

#include "%<CompiledModel.Name>.h"

If main.c is a static source file, you can use the fixed header filename rtmodel.h. This file includes the_`model`_.h header file:

#include "model.h" /* If main.c is generated */

or

#include "rtmodel.h" /* If static main.c is used */

Other external source files can require to include_`model`_.h to interface to model data, for example exported global parameters or signals. The_`model`_.h file itself can have additional header dependencies due to requirements of generated code. See System Header Files and Code Generator Header Files.

To reduce dependencies and reduce the number of included header files, see Manage Build Process File Dependencies.

rtwtypes.h

When the configuration parameter Data type replacement is set toUse coder typedefs, the generated code includesrtwtypes.h. The header file rtwtypes.h defines data types, structures, and macros required by the generated code.

Often, the generated code requires that integer operations overflow or underflow at specific values. For example, when the code expects a 16-bit integer, the code does not accept an 8-bit or a 32-bit integer type. The C language does not set a standard for the number of bits in types such as char and int.

Note

Before the creation of the C99 language standard, there was no universally accepted data type for sized integers. The C99 standard provides the header files stdint.h andstdbool.h. The stdint.h file contains sized-integer implementations that were previously unavailable.

To accommodate this feature of the C language, the generated code uses sized integer types, such as int8_T and uint32_T, which are not standard C types. In rtwtypes.h, the generated code maps these sized-integer types to the corresponding C keyword base type using information in the pane of the Configuration Parameters dialog box.

The code generator produces an optimized version of rtwtypes.h for ERT-based system target files when the model does not contain noninlined S-functions. The optimized rtwtypes.h file contains definitions that are specific to the hardware configuration of the model.

The location of rtwtypes.h depends on whether the build process uses the shared utilities location. If it uses a shared location, the code generator places rtwtypes.h inslprj/target/_sharedutils. Otherwise, it placesrtwtypes.h in the build folder (_`model`__ _`target`__rtw). See Specify Generated Code Interfaces and Control Placement of rtwtypes.h for Shared Utility Code.

Source files include the rtwtypes.h header file when the source files use code generator type names or other code generator definitions. For example, files that declare variables by using a code generator data type:

In some cases, an S-function, custom source file is compiled, first, by themex command, and second, by the code generation build. Duringmex compilation, rtwtypes.h is typically unavailable. To obtain the definitions normally supplied by rtwtypes.h, the custom source file can conditionally (through the MATLAB_MEX_FILE macro definition) include tmwtypes.h:

#ifdef MATLAB_MEX_FILE #include "tmwtypes.h" #else #include "rtwtypes.h" #endif

A source file for the code generator main.c (or.cpp) file includes rtwtypes.h without preprocessor checks.

Custom source files that the Target Language Compiler generates can also emit theinclude statements into their generated file.

If the Data type replacement configuration parameter is set toUse C data types with fixed-width integers, the code generator does not create rtwtypes.h because the generated code does not require definitions from rtwtypes.h. If the generated code uses static files under matlabroot that require Simulink Coder data type definitions, the software generates a simplified version ofrtwtypes.h. If you have custom code that includesrtwtypes.h, you can force the generation of the simplified version ofrtwtypes.h by selecting the Coder typedefs compatibility check box.

Simplified rtwtypes.h

/*

#ifndef RTWTYPES_H #define RTWTYPES_H

#include <stdint.h> #include <stdbool.h>

typedef int8_t int8_T; typedef uint8_t uint8_T; typedef int16_t int16_T; typedef uint16_t uint16_T; typedef int32_t int32_T; typedef uint32_t uint32_T; typedef bool boolean_T; typedef char char_T; typedef char byte_T; typedef int int_T; typedef unsigned char uchar_T; typedef unsigned int uint_T; typedef unsigned long ulong_T;

#define MIN_int8_T INT8_MIN #define MAX_int8_T INT8_MAX #define MAX_uint8_T UINT8_MAX #define MIN_int16_T INT16_MIN #define MAX_int16_T INT16_MAX #define MAX_uint16_T UINT16_MAX #define MIN_int32_T INT32_MIN #define MAX_int32_T INT32_MAX #define MAX_uint32_T UINT32_MAX

#endif /* RTWTYPES_H */

See Also

Topics