|
|
|
| R2012a Documentation → Simulink Coder | |
Learn more about Simulink Coder |
|
| Contents | Index |
| On this page… |
|---|
Build a Generic Real-Time Program Control Regeneration of Top Model Code Reduce Build Time for Referenced Models |
You can enter Target Language Compiler (TLC) command line options in the TLC options edit field, for example
-aVarName=1 to declare a TLC variable and/or assign a value to it
-IC:\Work to specify an include path
-v to obtain verbose output from TLC processing (for example, when debugging)
Specifying TLC options does not add any flags to the Make command field, as do some of the targets available in the System Target File Browser.
For additional information, see the Target Language Compiler documentation.
The Generate makefile option specifies whether the Simulink Coder build process is to generate a makefile for a model. By default, the Simulink Coder build process generates a makefile. You can suppress the generation of a makefile, for example in support of custom build processing that is not based on makefiles, by clearing Generate makefile . When you clear this option,
The Make command and Template makefile options are unavailable.
You must set up any post code generation build processing, using a user-defined command, as explained in Customize Post-Code-Generation Build Processing.
A high-level MATLAB command, invoked when a build is initiated, controls the Simulink Coder build process. Each target has an associated make command. The Make command field displays this command.
Almost all targets use the default command, make_rtw. Third-party targets might supply another make command. See the vendor's documentation.
In addition to the name of the make command, you can supply arguments in the Make command field. These arguments include compiler-specific options, include paths, and other parameters. When the build process invokes the make utility, these arguments are passed along in the make command line.
Template Makefiles and Make Options lists the Make command arguments you can use with each supported compiler.
The Template makefile field has these functions:
If you have selected a target configuration using the System Target File Browser, this field displays the name of a MATLAB language file that selects a template makefile for your development environment. For example, in Code Generation Pane: General, the Template makefile field displays grt_default_tmf, indicating that the build process invokes grt_default_tmf.m.
Template Makefiles and Make Options gives a detailed description of the logic by which the Simulink Coder build process selects a template makefile.
Alternatively, you can explicitly enter the name of a specific template makefile (including the extension) or a MATLAB language file that returns a template make file in this field. You must do this if you are using a target configuration that does not appear in the System Target File Browser. For example, do this if you have written your own template makefile for a custom target environment or you.
If you specify your own template makefile, be sure to include the filename extension. If you omit the extension, the Simulink Coder build process attempts to find and execute a file with the extension .m (that is, a MATLAB language file). The template make file (or a MATLAB language file that returns a template make file) must be on the MATLAB path. To determine whether the file is on the MATLAB path, enter the following command in the MATLAB Command Window:
which tmf_filename
You can initiate code generation and the build process by using the following options:
Clear the Generate code only option on the Code Generation pane of the Configuration Parameters dialog box and click Build.
Press Ctrl+B.
Select Tools > Code Generation > Build Model.
Invoke the rtwbuild command from the MATLAB command line.
Invoke the slbuild command from the MATLAB command line.
This section walks through the process of generating C code and building an executable program from an examplemodel. The resulting stand-alone program runs on your workstation, independent of external timing and events.
It is convenient to work with a local copy of the rtwdemo_f14 model, stored in its own folder, f14example. Set up your working folder as follows:
In the MATLAB Current Folder browser, navigate to a folder where you have write access.
Create the working folder from the MATLAB command line by typing:
mkdir f14example
Make f14example your working folder:
cd f14example
rtwdemo_f14
The model appears in the Simulink window.
In the model window, choose File > Save As. Navigate to your working folder, f14examplesave a copy of the rtwdemo_f14 model.
During code generation, the Simulink Coder software creates a build folder within your working folder. The build folder name is model_target_rtw, derived from the name of the source model and the chosen target. The build folder stores generated source code and other files created during the build process. You examine the build folder contents at the end of this example.
Note When a model contains Model blocks (which enable one Simulink model to include others), special project folders are created in your working folder to organize code for referenced models. Project folders exist alongside of Simulink Coder build folders, and are always named slprj. Generate Code for Referenced Models describes navigating project folder structures in Model Explorer. |
To generate code from your rtwdemo_f14 model, you must change some of the simulation parameters. In particular, note that generic real-time (GRT) and most other targets require that the model specify a fixed-step solver.
Note The Simulink Coder software can generate code for models using variable-step solvers for rapid simulation (rsim) and S-function targets only. |
To set parameters, use the Model Explorer as follows:
Open Model Explorer by selecting Model Explorer from the model's View menu.
In the Model Hierarchy pane, click the + sign preceding the model name to reveal its components.
Click Configuration (Active) in the left pane.
Click Solver in the center pane. The Solver pane appears at the right.
Enter the following parameter values on the Solver pane (some may already be set):
Start time: 0.0
Stop time: 60
Type: Fixed-step
Solver: ode5 (Dormand-Prince)
Fixed step size (fundamental sample time): 0.1
Tasking mode for periodic sample times: SingleTasking
The Solver pane with the modified parameter settings is shown below. Note the tan background color of the controls you just changed. The color also appears on fields that were set automatically by your choices in other fields. Use this visual feedback to verify that what you set is what you intended. When you apply your changes, the background color reverts to white.
Save the model. Simulation parameters persist with the model, for use in future sessions.
Note Some of the steps in this section do not require you to make changes. They are included to help you familiarize yourself with the Simulink Coder user interface. As you step through the dialog boxes, place the mouse pointer on any item of interest to see a tooltip describing its function. |
To specify the desired target configuration, you choose a system target file, a template makefile, and a make command.
In these examples (and in most applications), you do not need to specify these parameters individually. Here, you use the ready-to-run generic real-time target (GRT) configuration. The GRT target is designed to build a stand-alone executable program that runs on your workstation.
To select the GRT target via the Model Explorer:
With the rtwdemo_f14 model open, open Model Explorer by selecting Model Explorer from the model's View menu.
In the Model Hierarchy pane, click the + sign preceding the model name to reveal its components.
Click Configuration (Active) in the left pane.
Click Code Generation in the center pane. The Code Generation pane appears at the right. This pane has several tabs.
Click the General tab to activate the pane that controls target selection.
Click the Browse button next to the System target file field. This opens the System Target File Browser, illustrated below. The browser displays a list of all currently available target configurations. Your available configurations may differ. When you select a target configuration, the Simulink Coder software automatically chooses the system target file, template makefile, and make command for that configuration. Their names appear at the bottom left of the window.
Note The system target file browser lists all system target files found on the MATLAB path. Using some of these might require additional licensed products, such as the Embedded Coder product. |
From the list of available configurations, select Generic Real-Time Target (as shown above) and then click OK.
The Code Generation pane displays the system target file (grt.tlc), make command (make_rtw), and template makefile (grt_default_tmf), as shown below:
Select the Debug tab of the Code Generation pane. The options displayed here control build verbosity and debugging support, and are common to all target configurations. Make sure that all options are set to their defaults, as shown below.
Select the Symbols tab of the Code Generation pane. The options on this pane control the look and feel of generated code.
Select the Comments tab of the Code Generation pane. The options displayed here control the types of comments included in generated code. Make sure that all options are set to their defaults, as shown below.
Make sure that the Generate code only check box at the bottom of the pane is cleared.
The Simulink Coder build process generates C code from the model, and then compiles and links the generated program to create an executable image. To build and run the program,
With the rtwdemo_f14 model open, go to the Model Explorer window. In the Code Generation pane, select the General tab, then click the Build button to start the build process.
A number of messages concerning code generation and compilation appear in the MATLAB Command Window. The initial message is
### Starting build procedure for model: rtwdemo_f14
The contents of many of the succeeding messages depends on your compiler and operating system. The final message is
### Successful completion of build procedure for model: rtwdemo_f14
The working folder now contains an executable, rtwdemo_f14.exe (Microsoft Windows platforms) or rtwdemo_f14 (UNIX platforms). In addition, the Simulink Coder build process has created a project folder, slprj, and a build folder, rtwdemo_f14_grt_rtw, in your working folder.
Note The Simulink Coder build process displays a code generation report after generating the code for the rtwdemo_f14 model. The example Optimizing Generated Code provides more information about how to create and use a code generation report. |
To observe the contents of the working folder after the build, type the dir command from the MATLAB Command Window.
dir . rtwdemo_f14.exe rtwdemo_f14_grt_rtw .. rtwdemo_f14.mdl slprj
To run the executable from the Command Window, type
!rtwdemo_f14
The ! character passes the command that follows it to the operating system, which runs the stand-alone rtwdemo_f14 program.
The program produces one line of output in the Command Window:
**starting the model**
No data is output.
Finally, to see the files created in the build folder, type
dir rtwdemo_f14_grt_rtw
The exact list of files produced varies among MATLAB platforms and versions. Here is a sample list from a Windows platform.
. grt_main.obj rt_nonfinite.h .. html rt_nonfinite.obj buildInfo.mat modelsources.txt rt_rand.c defines.txt ode5.obj rt_rand.h rtwdemo_f14.bat rtGetInf.c rt_rand.obj rtwdemo_f14.c rtGetInf.h rt_sim.obj rtwdemo_f14.h rtGetInf.obj rtmodel.h rtwdemo_f14.mk rtGetNaN.c rtw_proj.tmw rtwdemo_f14.obj rtGetNaN.h rtwtypes.h rtwdemo_f14_private.h rtGetNaN.obj rtwtypeschksum.mat rtwdemo_f14_ref.rsp rt_logging.obj rtwdemo_f14_types.h rt_nonfinite.c
The build process creates a build folder and names it model_target_rtw, where model is the name of the source model and target is the target selected for the model. In this example, the build folder is named rtwdemo_f14_grt_rtw.
The build folder includes the following generated files.
Note The code generation report you created for the rtwdemo_f14 model in the previous section displays a link for each file listed below, which you can click to explore the file contents. |
| File | Description |
|---|---|
rtwdemo_f14.c | Standalone C code that implements the model |
rt_nonfinite.c | Functions to initialize nonfinite types (Inf, NaN, and -Inf) |
rt_rand.c | Random functions, included only if used by the application |
rtwdemo_f14.h | An include header file containing definitions of parameters and state variables |
rtwdemo_f14_private.h | Header file containing common include definitions |
rtwdemo_f14_types.h | Forward declarations of data types used in the code |
rt_nonfinite.h | Provides support for nonfinite numbers in the generated code, dynamically generates Inf, NaN, and -Inf |
rt_rand.h | Imported declarations for random functions, included only if used by the application |
rtmodel.h | Master header file for including generated code in the static main program (its name never changes, and it simply includes rtwdemo_f14.h) |
rtwtypes.h | Static include file for Simulink simstruct data types; some embedded targets tailor this file to reduce overhead, but GRT does not |
The build folder contains other files used in the build process, most of which you can disregard for the present:
rtwdemo_f14.mk — Makefile generated from a template for the GRT target
Object (.obj) files
rtwdemo_f14.bat — Batch control file
rtw_proj.tmw — Marker file
buildInfo.mat — Build information for relocating generated code to another development environment
defines.txt — Preprocessor defines required for compiling the generated code
rtwdemo_f14_ref.rsp — Data to include as command-line arguments to mex (Windows systems only)
The build folder also contains a subfolder, html, which contains the files that make up the code generation report. For more information about the code generation report, see Report Generation.
If you update generated source code or makefiles manually to add customizations, you can rebuild the files with the rtwrebuild command. This command recompiles the modified files by invoking the generated makefile. Alternatively, you can use this command from the Model Explorer,
In the Model Hierarchy pane, expand the node for the model of interest.
Click the Code for model node.
In the Code pane, click run rtwrebuild, listed to the right of the label Code Recompile Command.
When you rebuild a model, by default, the build process checks the structural checksum of the model to determine whether changes to the model require regeneration of the top model code, and takes one of the following actions:
If the checksum indicates that code regeneration is required, the build process fully regenerates and compiles the model code.
If the checksum indicates that the generated code is current with respect to the model, the build process omits regeneration of the top model code. This can significantly reduce model build times.
Regardless of whether the top model code is regenerated, the build process subsequently calls all build process hooks, including STF_make_rtw_hook functions and the post code generation command, and reruns the makefile so that any external dependencies are recompiled and relinked.
If you want to control or override the default top model build behavior, use one of the following command-line options:
To ignore the checksum and force regeneration of the top model code:
To clean the model build area enough to trigger regeneration of the top model code at the next build (slbuild only):
| slbuild(model,'CleanTopModel') |
Note You can also force regeneration of the top model code by deleting code generation folders, for example, slprj or the generated model code folder. |
In a parallel computing environment, you can increase the speed of code generation and compilation for models containing large model reference hierarchies by building referenced models in parallel whenever conditions allow. For example, if you have Parallel Computing Toolbox™ software, code generation and compilation for each referenced model can be distributed across the cores of a multicore host computer. If you additionally have MATLAB Distributed Computing Server™ (MDCS) software, code generation and compilation for each referenced model can be distributed across remote workers in your MATLAB Distributed Computing Server configuration.
The performance gain realized by using parallel builds for referenced models depends on several factors, including how many models can be built in parallel for a given model referencing hierarchy, the size of the referenced models, and parallel computing resources such as number of local and/or remote workers available and the hardware attributes of the local and remote machines (amount of RAM, number of cores, and so on).
For configuration requirements that might apply to your parallel computing environment, see Parallel Building Configuration Requirements.
For a description of the general workflow for building referenced models in parallel whenever conditions allow, see Build a Model In a Parallel Computing Environment.
For information on how to configure a custom embedded target to support parallel builds, see Support Model Referencing.
Note In an MDCS parallel computing configuration, parallel building is designed to work interactively with the MATLAB Distributed Computing Server software. You can initiate builds from the Simulink user interface or from the MATLAB Command Window using commands such as slbuild. You cannot initiate builds using batch or other batch mode workflows. |
The following requirements apply to configuring your parallel computing environment for building model reference hierarchies in parallel whenever conditions allow:
For local pools, the host machine must have enough RAM to support the number of local workers (MATLAB sessions) that you plan to use. For example, setting matlabpool to 4 results in five MATLAB sessions on your machine, each using approximately 120 MB of memory at startup.
Remote MDCS workers participating in a parallel build must use a common platform and compiler.
A consistent MATLAB environment must be set up in each MATLAB worker session as in the MATLAB client session — for example, all shared base workspace variables, MATLAB path settings, and so forth. One approach is to use the PreLoadFcn callback of the top model. If you configure your model to load the top model with each MATLAB worker session, its preload function can be used for any MATLAB worker session setup.
To take advantage of parallel building for a model reference hierarchy:
Set up a pool of local and/or remote MATLAB workers in your parallel computing environment.
Make sure that Parallel Computing Toolbox software is licensed and installed.
To use remote workers, make sure that MATLAB Distributed Computing Server software is licensed and installed.
Issue MATLAB commands to set up the worker pool, for example, matlabpool 4.
In the Configuration Parameters dialog box, go to the Model Referencing pane and select the Enable parallel model reference builds option. This selection enables the parameter MATLAB worker initialization for builds.
For MATLAB worker initialization for builds, select one of the following values:
None if the software should perform no special worker initialization. Specify this value if the child models in the model reference hierarchy do not rely on anything in the base workspace beyond what they explicitly set up (for example, with a model load function).
Copy base workspace if the software should attempt to copy the base workspace to each worker. Specify this value if you use a setup script to prepare the base workspace for all models to use.
Load top model if the software should load the top model on each worker. Specify this value if the top model in the model reference hierarchy handles all of the base workspace setup (for example, with a model load function).
Optionally, inspect the model reference hierarchy to determine, based on model dependencies, which models will be built in parallel. For example, you can use the Model Dependency Viewer from the Simulink Tools menu.
Build your model. Messages in the MATLAB Command Window record when each parallel or serial build starts and finishes. The order in which referenced models build is nondeterministic. They might build in a different order each time the model is built.
If you need more information about a parallel build, for example, if a build fails, see Locate Parallel Build Logs.
When you build a model for which referenced models are built in parallel, messages in the MATLAB Command Window record when each parallel or serial build starts and finishes. Any referenced models that build in parallel have only summary log entries in the command window, even if verbose builds are turned on. For example,
### Initializing parallel workers for parallel model reference build. ### Parallel worker initialization complete. ### Starting parallel model reference SIM build for 'bot_model001' ### Starting parallel model reference SIM build for 'bot_model002' ### Starting parallel model reference SIM build for 'bot_model003' ### Starting parallel model reference SIM build for 'bot_model004' ### Finished parallel model reference SIM build for 'bot_model001' ### Finished parallel model reference SIM build for 'bot_model002' ### Finished parallel model reference SIM build for 'bot_model003' ### Finished parallel model reference SIM build for 'bot_model004' ### Starting parallel model reference RTW build for 'bot_model001' ### Starting parallel model reference RTW build for 'bot_model002' ### Starting parallel model reference RTW build for 'bot_model003' ### Starting parallel model reference RTW build for 'bot_model004' ### Finished parallel model reference RTW build for 'bot_model001' ### Finished parallel model reference RTW build for 'bot_model002' ### Finished parallel model reference RTW build for 'bot_model003' ### Finished parallel model reference RTW build for 'bot_model004'
If a parallel builds fails, you might see output similar to the following:
### Initializing parallel workers for parallel model reference build. ### Parallel worker initialization complete. ... ### Starting parallel model reference RTW build for 'bot_model002' ### Starting parallel model reference RTW build for 'bot_model003' ### Finished parallel model reference RTW build for 'bot_model002' ### Finished parallel model reference RTW build for 'bot_model003' ### Starting parallel model reference RTW build for 'bot_model001' ### Starting parallel model reference RTW build for 'bot_model004' ### Finished parallel model reference RTW build for 'bot_model004' ### The following error occurred during the parallel model reference RTW build for 'bot_model001': Error(s) encountered while building model "bot_model001" ### Cleaning up parallel workers.
To obtain more detailed information about the failed build, you can examine the parallel build log. For each referenced model built in parallel, the build process generates a file named model_buildlog.txt, where model is the name of the referenced model. This file contains the full build log for that model.
If a parallel build completes, the build log file is placed in the build subfolder corresponding to the referenced model. For example, for a build of referenced model bot_model004, you would look for the build log file bot_model004_buildlog.txt in a referenced model subfolder such as build_folder/slprj/grt/bot_model004, build_folder/slprj/ert/bot_model004, or build_folder/slprj/sim/bot_model004.
If a parallel build fails, the build log can be found in a referenced model subfolder under the build subfolder /par_mdl_ref/model. For example, for a failed parallel build of model bot_model001, you would look for the build log file bot_model001_buildlog.txt in a subfolder such as build_folder/par_mdl_ref/bot_model001/slprj/grt/bot_model001, build_folder/par_mdl_ref/bot_model001/slprj/ert/bot_model001, or build_folder/par_mdl_ref/bot_model001/slprj/sim/bot_model001.
If you need to relocate the static and generated code files for a model to another development environment, such as a system or an integrated development environment (IDE) that does not include MATLAB and Simulink products, use the Simulink Coder pack-and-go utility. This utility uses the tools for customizing the build process after code generation and a packNGo function to find and package files for building an executable image. The files are packaged in a compressed file that you can relocate and unpack using a standard zip utility.
To relocate a model's code files,
Before you generate and package the files for a model build, decide whether you want the files to be packaged in a flat or hierarchical folder structure. By default, the packNGo function packages the files in a single, flat folder structure. This is the simplest approach and might be the optimal choice.
| If... | Then Use a... |
|---|---|
| You are relocating files to an IDE that does not use the generated makefile or the code is not dependent on the relative location of required static files | Single, flat folder structure |
| The target development environment must maintain the folder structure of the source environment because it uses the generated makefile or the code is dependent on the relative location of files | Hierarchical structure |
If you use a hierarchical structure, the packNGo function creates two levels of zip files, a primary zip file, which in turn contains the following secondary zip files:
mlrFiles.zip — files in your matlabroot folder tree
sDirFiles.zip — files in and under your build folder where you initiated the model's code generation
otherFiles.zip — required files not in the matlabroot or start folder trees
Paths for the secondary zip files are relative to the root folder of the primary zip file, maintaining the source development folder structure.
By default, the packNGo function names the primary zip file model.zip. You have the option of specifying a different name. If you specify a file name and omit the file type extension, the function appends .zip to the name you specify.
You package model code files by using the PostCodeGenCommand configuration parameter, packNGo function, and the model's build information object. You can set up the packaging operation to use
A system generated build information object.
In this case, use set_param to set the configuration parameter PostCodeGenCommand to an explicit call to the packNGo function before generating the model code. For example:
set_param(bdroot, 'PostCodeGenCommand', 'packNGo(buildInfo);');
This command instructs the Simulink Coder build process to evaluate the call to packNGo, using the system generated build information object for the currently selected model, after generating and writing the model's code to disk and before generating a makefile.
A build information object that you construct programmatically, as explained in Customize Post-Code-Generation Build Processing.
In this case, you might use other build information functions to selectively include paths and files in the build information object that you then specify with the packNGo function. For example:
.
.
.
myModelBuildInfo = RTW.BuildInfo;
addSourceFiles(myModelBuildInfo, {'test1.c' 'test2.c' 'driver.c'});
.
.
.
packNGo(myModelBuildInfo);To change the default behavior of packNGo, see the following examples:
| To... | Specify... |
|---|---|
| Change the structure of the file packaging to hierarchical | packNGo(buildInfo, {'packType' 'hierarchical'}); |
| Rename the primary zip file | packNGo(buildInfo, {'fileName' 'zippedsrcs'}); |
| Change the structure of the file packaging to hierarchical and rename the primary zip file | packNGo(buildInfo, {'packType' 'hierarchical'... 'fileName' 'zippedsrcs'}); |
| Include all header files found on the include path (rather than the minimal header files required to build the code) in the zip file | packNGo(buildInfo, {'minimalHeaders' false}); |
Note The packNGo function potentially can modify the build information passed in the first packNGo argument. As part of packaging model code, packNGo might find additional files from source and include paths recorded in the model's build information and add them to the build information. |
Inspect the resulting zip file in your working folder on the source system to verify that it is ready for relocation to the destination system. Depending on the zip tool you use you might be able to open and inspect the file without unpacking it. If you need to unpack the file and you packaged the model code files as a hierarchical structure, you will need to unpack the primary and secondary zip files. When you unpack the secondary zip files, relative paths of all files are preserved.
Relocate the resulting zip file to the destination development environment and unpack the file.
The following example guides you through the steps for packaging code files generated for the demo model rtwdemo_f14.
Set your working folder to a writable folder.
Open the model rtwdemo_f14 and save a copy to your working folder.
Enter the following command in the MATLAB Command Window:
set_param('rtwdemo_f14', 'PostCodeGenCommand',...
'packNGo(buildInfo, {''packType'' ''hierarchical''})');You must double the single-quotes due to the nesting of character arrays 'packType' and 'hierarchical' within the character array that specifies the call to packNGo.
Generate code for the model.
Inspect the generated zip file, rtwdemo_f14.zip. The zip file contains the two secondary zip files, mlrFiles.zip and sDirFiles.zip.
Inspect the zip files mlrFiles.zip and sDirFiles.zip.
Relocate the zip file to a destination environment and unpack it.
The following limitations apply to use of the packNGo function:
The function operates on source files, such as *.c, *.cpp, and *.h files, only. The function does not support compile flags, defines, or makefiles.
Unnecessary files might be included. The function might find additional files from source and include paths recorded in the model's build information and include them, even if they are not used.
The Simulink Coder software generates C code only or generates the C code and produces an executable image, depending on the level of processing you choose. By default, a Build button appears on the Code Generation pane of the Configuration Parameters dialog box. This button completes the entire build process and an executable image results. If you select the Generate code only check box to the left of the button, the button label changes to Generate code.
When you click the Build or Generate code button, the Simulink Coder software performs the following build process. If the software detects code generation constraints for your model, it issues warning or error messages.
For more information, see Generate an HTML Code Generation Report. You can also view an HTML report in Model Explorer.
After generating the code, the Simulink Coder software generates a customized makefile, model.mk. The generated makefile instructs the make system utility to compile and link source code generated from the model, as well as any required harness program, libraries, or user-provided modules.
The Simulink Coder software creates model.mk from a system template file, system.tmf (where system stands for the selected target name). The system template makefile is designed for your target environment. You have the option of modifying the template makefile to specify compilers, compiler options, and additional information used during the creation of the executable.
The Simulink Coder software creates the model.mk file by copying the contents of system.tmf and expanding lexical tokens (symbolic names) that describe your model's configuration.
The Simulink Coder software provides many system template makefiles, configured for specific target environments and development systems. Selecting a Target in the Simulink Coder documentation lists all template makefiles that are bundled with the Simulink Coder software. To see an example template makefile, navigate to matlabroot/rtw/c/grt, and open with an editor the file grt_msvc.tmf. You can fully customize your build process by modifying an existing template makefile or providing your own template makefile.
The following figure shows how the Simulink Coder software controls automatic program building.
During the final stage of processing, the Simulink Coder build process invokes the generated makefile, model.mk, which in turn compiles and links the generated code. On PC platforms, a batch file is created to invoke the generated makefile. The batch file sets up the environment for invoking the make utility and related compiler tools. To avoid recompilation of C files, the make utility performs date checking on the dependencies between the object and C files; only out-of-date source files are compiled. Optionally, the makefile can download the resulting executable image to your target hardware.
This stage is optional, as illustrated by the control logic in the preceding figure. You might choose to omit this stage, for example, if you are targeting an embedded microcontroller or a digital signal processing (DSP) board.
To omit this stage of processing, select the Generate code only check box on the Code Generation pane of the Configuration Parameters dialog box. You can then cross-compile your code and download it to your target hardware. Program Building, Interaction, and Debugging in the Simulink Coder documentation discusses the options that control whether or not the build creates an executable image.
If you select Create code generation report on the Code Generation > Report pane, a navigable summary of source files is produced when the model is built. The report files occupy a folder called html within the build folder. The report contents vary depending on the target, but all reports feature links to generated source files. The following display shows an example of an HTML code generation report for a generic real-time (GRT) target.
 | Compiler or IDE Selection and Configuration | Build and Run a Program |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
