When you generate code for a model, the code generator by default creates shared utility
files that the model requires. When you generate code with different releases, the code
generators can produce functionally identical shared files that contain some nonfunctional
differences. For example, different comments and different coding style. When you use the same
release to generate code for different models in different folders, you can also produce
shared files with nonfunctional differences. For example, if you specify different
ExpressionFolding values for the
models, the code generator can produce shared files that contain different comments or
different coding styles.
Integrated code that includes functionally identical shared files:
Is more expensive to verify because each shared file requires verification.
Produces compilation errors if the shared files define duplicate symbols.
If you have an Embedded Coder® license, you can avoid these issues by specifying the reuse of shared code from an existing folder, for example, a read-only library of verified code. In this case, the code generator does not create new shared utility files. The build process uses external code or previously generated shared utility code from the folder. An administrator maintains and updates the read-only library.
In the Configuration Parameters dialog box:
In the Existing shared code field, enter the full path to your shared code folder.
Verify that the Use only existing shared code
diagnostic is set to
slprj folder or move to a new working folder.
Build your model. If you do not see an error, your shared code folder contains the required shared utility files.
If files are missing from the existing shared code folder, you see an error. To continue code generation with a locally generated version of the missing shared utility files:
Set the Use only existing shared code diagnostic to
Rebuild your model. The code generation process uses a locally generated version of the missing shared utility files.
Provide the administrator of the verified code library with your model and
information about missing shared utility files. With the model, the administrator
generates the required shared utility files. Using
sharedCodeUpdate (Embedded Coder), the administrator adds the files to the existing
shared code folder.
If you require reuse of shared code for a component exported from a previous
release, provide the administrator with information about the build folder
location for the component. The administrator can use
sharedCodeUpdate to copy the shared code for the component to
the existing shared code folder.
When the files are available in the existing shared code folder, repeat steps 1–3.
If the shared utility code is generated from library subsystems that are shared across models, you cannot reuse the code across releases because the code is release-specific—the symbol name and file name mangling includes the release number. The administrator must add the shared utility code generated for each release to the shared code folder.
sharedCodeUpdate (Embedded Coder) function can add files to
the shared code folder that have identical content but different file and function
names. This behavior is useful when you have different model components that require
their own shared utility functions. Although some code is duplicated, the different
model components can access the shared utility functions with which they were verified.
To force model components to have their own versions of shared utility functions,
configure naming rules to insert the model name into shared utility identifiers (Embedded Coder).
For most shared utility code files, you can specify master copies that you can reuse
across releases without modifying the files. With some files, for example,
zero_crossing_types.h, there are
situations where manual editing is required to produce master copies that you can use with
generated code from different releases. For example:
rtwtypes.h file generated by releases up to and including
R2013a contains a
/* This ID is used to detect inclusion of an incompatible rtwtypes.h */ #define RTWTYPES_ID_C08S16I32L64N64F0
rtwtypes.hfile that you want to include in your integration, copy the corresponding
#definestatement into your master copy of
In R2015a, the zero-crossing definitions moved from
zero_crossing_types.h. To create an
rtwtypes.h file that is compatible with generated model code from
different releases, in your master copy of
rtwtypes.h, insert this