|
|
|
| R2012a Documentation → Embedded Coder | |
Learn more about Embedded Coder |
|
| Contents | Index |
You can use user-defined data types for Simulink signals and parameters and their corresponding identifiers in generated code. This is true whether or not a signal or parameter has a Simulink data object associated with it.
Before you can select a user data type for a signal or parameter, you must:
Create a user data type (alias), as explained in the description of Simulink.AliasType in the Simulink documentation. For the example in Select the User Data Types demonstrating how to select user data types for signals and parameters, create the alias data type f32.
Register the user data type so that it is associated with the corresponding MathWorks C/C++ data type, as explained in Create User Data Types for mpt Data Objects. For the example, register the data type f32 so that it is associated with type real32_T. The call to function addUserDataType in the sl_customization.m file you use for the registration must specify:
f32 as the user data type
real32_T as the built-in data type
<userdata_types.h> as the user header file that is to include the user data type definition
For example,
function sl_customization(cm) hObj = cm.slDataObjectCustomizer; addUserDataType(hObj, 'f32', 'real32_T', '<userdata_types.h>'); end
If you have not already done so, add the directory containing the sl_customization.m file that you created or modified in step 1 to the MATLAB search path.
Open a model. The example uses the following model.
Create a data dictionary for the model, as explained in Create Simulink and mpt Data Objects, to associate signals and parameters with data objects. For the example, the Model Explorer display must appear as shown below. The three data objects that appear, sig1, sig2, and g, and the registered user data type, f32, appear in the middle pane. The "T" indicates that f32 is an alias data type.
For the selection procedure and to continue with the example, continue to Select the User Data Types.
After completing the preparation explained in Prepare User Data Types, you can use the user-defined data types for Simulink signals and parameters and for their corresponding identifiers in the generated code. You can use user-defined data types with signals and parameters whether or not they have Simulink objects associated with them.
For an mpt object that is associated with a signal or parameter in your model, in the Data type field, select the user data type that you want. For example, select f32, for sig1.
This selects f32 for the sig1 data object in the data dictionary, but does not select f32 for the corresponding labeled signal in the model. Therefore, the two may be in conflict. If you try to update the model, you could get an error message.
To continue with the example, type f32 into the Data type field for sig1.
Select the model and double-click the signal or parameter source block. (The source block of a model signal or parameter controls the signal's or parameter's data type.) For example, in the example model the Sum block is the source block for sig1. Double-click the Sum block. The Function Block Parameters dialog box opens.
In the Output data type or Parameter data type field, type the name of the user data type that you specified for the data object in step 1, and click Apply. The user data type of the signal in the model and that of the signal object are now the same.
Alternatively, you can use dictionary-driven data typing. In the Output data type field, specify object.DataType, where object is the case-sensitive object name. For example, you can specify sig1.DataType instead of f32.
The advantage of using the alternative is that subsequent user data type changes for the object in the dictionary automatically change the user data type of the corresponding model signal or parameter.
Repeat steps 1 through 4 for each remaining model signal and parameter that has a corresponding signal object for which you selected a user data type.
Save the model and save all of the data objects in the MATLAB base workspace in a .mat file for reuse later. Generated code for sig1 in the example model (with default MPF settings) would appear as follows:
| In sampleUserDT.c | f32 sig1; |
| In sampleUserDT_types.h | #include <userdata_types.h> |
With this procedure, you can control the persistence level of signal and parameter objects associated with a model. Persistence level allows you to make intermediate variables or parameters global during initial development. At the later stages of development, you can use this procedure to remove these signals and parameters for efficiency. Notice the Persistence Level field on the Model Explorer, as illustrated in the figure below. For descriptions of the properties on the Model Explorer, see Parameter and Signal Property Values.
Notice also the Signal display level and Parameter tune level fields on the Code Placement pane of the Configuration Parameters dialog box, as illustrated in the next figure.
The Signal display level field allows you to specify whether or not the code generator defines a signal data object as global data in the generated code. The number you specify in this field is relative to the number you specify in the Persistence level field. The Signal display level number is for all mpt (module packaging tool) signal data objects in the model. The Persistence level number is for a particular mpt signal data object. If the data object's Persistence level is equal to or less than the Signal display level, the signal appears in the generated code as global data with all of the properties (custom attributes) specified in Create mpt Data Objects with Data Object Wizard. For example, this would occur if Persistence level is 2 and Signal display level is 5.
Otherwise, the code generator automatically determines how the particular signal data object appears in the generated code. Depending on the settings on the Optimization pane of the Configuration Parameters dialog box, the signal data object could appear in the code as local data and thus have none of the custom attributes you specified for that data object. Or, based on expression folding, the code generator could remove the data object so that it does not appear in the code. (See and .)
The Parameter tune level field allows you to specify whether or not the code generator declares a parameter data object as tunable global data in the generated code.
The number you specify in this field is relative to the number you specify in the Persistence level field. The Parameter tune level number is for all mpt parameter data objects in the model. The Persistence level number is for a particular mpt parameter data object. If the data object's Persistence level is equal to or less than the Parameter tune level, the parameter appears in the generated code with all of the properties (custom attributes) specified in Create mpt Data Objects with Data Object Wizard, and thus is tunable. For example, this would occur if Persistence level is 2 and Parameter tune level is 5.
Otherwise, the parameter is inlined in the generated code, and the code generation settings determine its exact form.
Note that, in the initial stages of development, you might be more concerned about debugging than code size. Or, you might want one or more particular data objects to appear in the code so that you can analyze intermediate calculations of an equation. In this case, you might want to specify the Parameter tune level (Signal display level for signals) to be higher than Persistence level for some or all mpt parameter (or signal) data objects. This results in larger code size, because the code generator defines the parameter (or signal) data objects as global data, which have all the custom properties you specified. As you approach production code generation, however, you might have more concern about reducing the size of the code and less need for debugging or intermediate analyses. In this stage of the tradeoff, you could make the Parameter tune level (Signal display level for signals) greater than Persistence level for one or more data objects, generate code and observe the results. Repeat until satisfied.
With the model open, in the Configuration Parameters dialog box, click Code Generation > Code Placement.
Type the desired number in the Signal display level or Parameter tune level field, and click Apply.
In the Model Explorer, type the desired number in the Persistence field for the selected signal or parameter, and click Apply.
When you use buses in a model for which you intend to generate code:
Setting diagnostic configuration parameters can add to the ease of development.
The bus implementation techniques used can influence the speed, size, and clarity of that code.
Some bus implementation techniques that can be useful are not immediately obvious.
This chapter contains guidelines that you can use to improve the results when you work with buses. The guidelines describe techniques for:
Simplifying the layout of the model
Increasing the efficiency of generated code
Defining data structures for function/subsystem interfaces
Defining data structures that match existing data structures in external C code
Some trade-offs inevitably exist among speed, size, and clarity. For example, the code for nonvirtual buses is easier to read because the buses appear in the code as structures, but the code for virtual buses is faster because virtual buses do not require copying signal data. The applicability of some guidelines can therefore depend on where you are in the application development process.
This chapter focuses on optimizations that are useful for final production code. Before you read this chapter, be sure that you have read Using Composite Signals. This chapter assumes that you understand all the concepts and procedures described in that one, including the blocks used for creating and manipulating buses.
Simulink provides diagnostics that you can use to optimize bus usage. Set the following values on the Configuration parameters > Diagnostics > Connectivity pane:
Bus signal treated as vector is enabled only when Mux blocks used to create bus signals is set to error. Setting Mux blocks used to create bus signals to none disables both diagnostics. Temporarily disabling the two mux and bus diagnostics allows you to debug other bus problems before addressing mux and bus mixtures. You can then enable the last two diagnostics and use them to eliminate any such mixtures. When you build existing models, the diagnostic settings should be as shown at all times. See Avoiding Mux/Bus Mixtures for more information.
Use Virtual Buses Wherever Possible. Virtual buses are graphical conveniences that do not affect generated code. As a result, the code generation engine is able to fully optimize the signals in the bus. You should therefore use virtual rather than nonvirtual buses wherever possible. You can convert between virtual and nonvirtual buses using Signal Conversion blocks. In many cases, Simulink automatically converts a virtual bus to a nonvirtual bus when required. For example, a virtual bus input to a Model block becomes a nonvirtual bus with no need for explicit conversion. See for more information.
When are Virtual and Nonvirtual Buses Required?.In some cases, Simulink requires the use of nonvirtual buses:
For non-auto storage classes
Inports and Outports of Model blocks
To generate a specific structure from the bus
Root level Inport or Outport blocks when the bus has mixed data types
In one case, Simulink requires the use of virtual buses:
Only virtual buses can be used for bundling function call signals.
Avoid Nonlocal Nested Buses in Nonvirtual Buses. Buses can contain subordinate buses. The storage class of any subordinate bus should be auto, which results in a local signal. Setting a subordinate bus to a non-auto storage class has two undesirable results:
Allocation of redundant memory (memory for the subordinate bus object and memory for the final bus object)
Additional copy operations (first copying to the subordinate bus and then copying from the subordinate bus to the final bus)
In the following example, the final bus is created from local scoped subordinate elements. The resulting assignment operations are relatively efficient:
By contrast in the next example the subordinate elements sub_bus_1 and sub_bus_2 are global in scope. First the assignment to the subordinate bus occurs (lines 54 – 59) then the copy of the subordinate bus to the main bus (lines 60 – 61). In most cases, this is not an efficient implementation:
Introduction. Nonvirtual buses do not support multiple rates. Virtual buses support multiple rates as long as the bus does not cross any root level inport or outport. The best techniques for optimizing a bus that contains signals that initially have different rates can depend on the type of the bus and the number of signals.
Techniques for Combining Multiple Rates. The simplest bus contains only two signals. The next figure shows two examples of two-element buses. The first example shows a virtual bus created from two signals that have different rates. The second example shows a nonvirtual bus created from the same two signals. The Sample Time Legend shows the different signal rates:
The signals with different rates in the first example can be combined into a virtual bus, because virtual buses support multiple rates. However, a multirate virtual bus cannot connect to a root-level output port. The bus therefore passes through a Rate Transition block that converts it to a single-rate bus, then connects to the Outport. This technique is preferable only for virtual buses that contain no more than two signals. See Larger Buses and Multiple Rates.
The signals with different rates in the second example cannot initially be combined into a nonvirtual bus, because nonvirtual buses do not support multiple rates. One of the signals therefore passes through a Rate Transition block, which converts it to have the same rate as the other signal, then connects to the Bus Creator block. The signals can then combine into a single-rate nonvirtual bus, which can connect to the root-level outport without further conversion.
Larger Buses and Multiple Rates. When you create a multirate virtual bus that contains more than two signals, you can convert the bus to single-rate by applying a Rate Transition block to the output of the Bus Creator block. Use a Rate Transition block on each input signal to give full control over the output rate. As the next figure shows, when a single Rate Transition block is used, the block sets all of the signals to the fastest rate (D1):
Note that the preferred techniques for a virtual bus with more than two signals, and the required technique for a nonvirtual bus with any number of signals, are the same. Note also that, in the preceding figure, the blocks that perform rate transition are not actual Rate Transition blocks, but other blocks that can change the signal rate as part of some other operation. The identity of the blocks that perform rate transition makes no difference. All that matters is that the signal rates match when required.
Specify Sample Time Rates. The sample time for buses should be specified through the signals that define the bus. If the sample times do not match, use Rate Transition (or equivalent) blocks to create a uniform rate, as shown in the previous figures. The signal rates should not be set by specifying Sample Time values in a Bus Creator block's bus object. Instead, set the sample time for each signal before inputting it to the Bus Creator, and set each Sample Time in the corresponding bus object to -1 (inherited), as shown in the next figure:
Introduction. Unlike scalar and vector signals, buses provide no direct way to initialize signals. This section describes techniques for initializing bus signals using Simulink, Stateflow, and MATLAB functions.
Initialize Bus Signals in Simulink. In Simulink, you can set initial values on a bus by using a set of conditionally executed subsystems, such as Function-Call subsystems, and a Merge block, as shown in this example:
Both subsystems (InitBus and StandardUpdate) create a bus signal of type CounterBus. However, the assignment to the variable GlobalCounter is controlled by the Merge block. See Function-Call Subsystems for more information.
This technique is limited because the StandardUpdate subsystem does not use the initial values from the InitBus subsystem. If the calculations depend on past information from the bus, consider using Stateflow or MATLAB functions to initialize bus signals.
Bus Initialization in Stateflow. Stateflow and MATLAB functions allow for conditional execution internally. In the following example, the init and update code are Functions in the Stateflow diagram. This technique simplifies the presentation in the generated code:
In the generated code, you can see that the UpdateCnt function uses the past value of GlobalCounter.cnt:
The previous example used Stateflow Graphical functions to initialize and update the buses. Alternatively, you can use MATLAB functions or Simulink subsystems embedded in a Stateflow diagram. The next figure illustrates this technique:
The Simulink subsystems are the same as those used in the earlier Simulink-only example.
Create a Bus of Constants. The code for specifying a bus of constant values will appear in either the Init or the Step function of the model. The code location depends on the configuration of the bus. In most cases the code appears in the Step function. However if the following conditions hold the code will be placed in the Init function:
The bus is a virtual bus
All signals have the same data type
The signals in the bus are all constants
In the next figure, only the bus named Bus_2 meets all the requirements:
The code for Bus_2 therefore appears in the Init function. The code for the other buses appears in the Step function:
To avoid repeatedly updating a bus of constants, place the bus code into a function-call subsystem, as described in Initialize Bus Signals in Simulink. When you use this technique, make sure the function-call subsystem is called at the start of execution. See Function-Call Subsystems for more information.
Extract Nonvirtual Bus Signals Inside of Atomic Subsystems. Selecting signals from a nonvirtual bus can result in unnecessary data copies when those signals cross an atomic boundary. In the following example the same code, a simple multiplication of two elements in a vector, is executed three times:
In the second instance when the bus signals are selected outside of the atomic subsystem an unnecessary copy of the bus data is created.
Although this example shows only signals with global scope, both global and local signals show the same behavior: the selection of the signals outside of the model results in an unnecessary copy, while the internal selection does not.
Virtual Bus Signals Crossing Atomic Boundaries. Virtual buses that cross atomic boundaries can result in the creation of unnecessary data copies. The following example shows the data copy that occurs when a virtual bus crosses an atomic boundary:
Lines 25–26 show the signals being selected out of the bus before they are used in the function on lines 19–20. By comparison the nonvirtual bus does not require the use of temporary variables.
Atomic Subsystems and Buses of Constants. If the bus passed into an atomic subsystem consists exclusively of constants, using a virtual bus is more efficient, because Simulink is able to inline the constant values into the code:
You can replace built-in data type names with user-defined replacement data type names in the generated code for a model.
To configure replacement data types,
In the Model Editor, set the simulation mode of the open model. From the Simulation menu, select Normal, Software-in-the-loop (SIL), or Processor-in-the-loop (PIL).
In the Configuration Parameters dialog box, click Code Generation > Data Type Replacement > Replace data type names in the generated code. A Data type names table appears. The table lists each Simulink built-in data type name with its corresponding code generation data type name.
Fill in fields in the third column with your replacement data types. Each replacement data type should be the name of a Simulink.AliasType object that exists in the base workspace. Replacements may be specified or not for each individual built-in type.
For each replacement data type you enter, the BaseType property of the associated Simulink.AliasType object must be consistent with the built-in data type it replaces.
For double, single, int32, int16, int8, uint32, uint16, and uint8, the replacement data type's BaseType must match the built-in data type.
For boolean, the replacement data type's BaseType must be either an 8-bit integer or an integer of the size displayed for Number of bits: int on the Hardware Implementation pane of the Configuration Parameters dialog box.
For int, uint, and char, the replacement data type's size must match the size displayed for Number of bits: int or Number of bits: char on the Hardware Implementation pane of the Configuration Parameters dialog box.
An error occurs, if
A replacement data type specification is inconsistent.
The Simulink.AliasType object has the Data scope parameter set to Exported.
The Embedded Coder software supports use of user-defined data type objects in code generation. These include objects of the following classes:
For information on the properties and usage of these data object classes, see Simulink.AliasType, Simulink.Bus, and Simulink.NumericType in the Simulink Classes section of the Simulink Reference documentation. For general information on creating and using data objects, see the Working with Data Objects section of the Simulink documentation
In code generation, you can use user-defined data objects to
Map your own data type definitions to Simulink built-in data types, and specify that your data types are to be used in generated code.
Optionally, generate #include directives specifying your own header files, containing your data type definitions. This technique lets you use legacy data types in generated code.
In general, code generated from user-defined data objects conforms to the properties and attributes of the objects as defined for use in simulation. When generating code from user-defined data objects, the name of the object is the name of the data type that is used in the generated code. Exception: for Simulink.NumericType objects whose IsAlias property is false, the name of the functionally equivalent built-in or fixed-point Simulink data type is used instead.
Note The names of data types defined using Simulink.AliasType objects are preserved in the generated code only for installations with a Embedded Coder license. |
When a model uses Simulink.DataType and Simulink.Bus objects, the generated code includes corresponding typedef definitions. Both Simulink.DataType and Simulink.Bus objects have a HeaderFile property that controls the location of the object's typedef. Setting a HeaderFile is optional and specific to code generation only.
Omit a HeaderFile Value. If the HeaderFile property for a Simulink.DataType or Simulink.Bus object is left empty, a generated typedef for the object appears in the generated file model_types.h.
Example.For a Simulink.NumericType object named myfloat with a Category of double and no HeaderFile property specified, model_types.h in the generated code contains:
typedef real_T myfloat;
Specify a HeaderFile Value. If the HeaderFile property for a Simulink.DataType or Simulink.Bus object is set to a string value,
The string must be the name of a header file that contains a typedef for the object.
The generated file model_types.h contains a #include that gives the header file name.
You can use this technique to include legacy or other externally created typedefs in generated code. When the generated code compiles, the specified header file must be accessible on the build process include path.
HeaderFile Property Syntax.The HeaderFile property should include the desired preprocessor delimiter ("" or '<>'), as in the following examples.
This example:
myfloat.HeaderFile = '<legacy_types.h>'
generates the directive:
#include <legacy_types.h>
This example:
myfloat.HeaderFile = '"legacy_types.h>"'
generates the directive:
#include "legacy_types.h"
To specify and use user-defined data types for code generation:
Create a user-defined data object and configure its properties, as described in the Working with Data Objects section of the Simulink documentation.
If you specified the HeaderFile property, copy the header file to the specified directory.
Set the output data type of selected blocks in your model to the user-defined data object. To do this, set the Data type parameter of the block to Specify with dialog. Then, enter the object name in the Output data type parameter.
The specified output data type propagates through the model and variables of the user-defined type are declared as required in the generated code.
About User Data Types for mpt Data Objects. By default, MathWorks data types (such as real32_T and uint8_T) are used to define data in the generated code. If you prefer using your company-standard data types (such as DBL and U8), you can define user data types. To use this feature, you must register and create your data types so that the code generator can associate them with the corresponding MathWorks C/C++ data types. Then, the code generator will use your user data types in the generated code instead of the MathWorks C/C++ data types.
Code generation software automatically associates the MathWorks C/C++ data types with the equivalent ANSI®[1] C/C++ data types. If you want to use only the default MathWorks C/C++ data types, you do not need to register and create your own data types.
To register user data types, use the Simulink customization file sl_customization.m. This file is a mechanism that allows you to use MATLAB code to perform customizations of the standard Simulink user interface. The Simulink software reads the sl_customization.m file, if present on the MATLAB path, when it starts and the customizations specified in the file are applied to the Simulink session. For more information on the sl_customization.m customization file, see Customizing the Simulink User Interface in the Simulink documentation.
Once you have registered your user data types using sl_customization.m, you must create the Simulink.AliasType objects corresponding to your user data types. If your model references a user data type either directly (for example, in the output data type of a block) or indirectly (for example, a Simulink.Signal object data type is set to the user data type), you must create the corresponding Simulink.AliasType object before updating the model, running a simulation, or generating code. To create the Simulink.AliasType objects, you can:
Invoke the MATLAB function ec_create_type_obj to programmatically create all the required Simulink.AliasType objects
Create Simulink.AliasType objects one at a time by selecting Add > Simulink.AliasType in the Model Explorer
Create Simulink.AliasType objects one at a time by entering the MATLAB command userdatatype = Simulink.AliasType, where userdatatype is a user data type registered in sl_customization.m
Register User Data Types Using sl_customization.m. To register user data type customizations, you create an instance of sl_customization.m and include it on the MATLAB path of the Simulink installation that you want to customize. The sl_customization function accepts one argument: a handle to a customization manager object. For example,
function sl_customization(cm)
As a starting point for your customizations, the sl_customization function must first get the default (factory) customizations, using the following assignment statement:
hObj = cm.slDataObjectCustomizer;
You then invoke methods to register your customizations. The customization manager object includes the following methods for registering Simulink user data type customizations:
addUserDataType(hObj, userName, builtinName, userHeader)
addUserDataType(hObj, userName, builtinName)
addUserDataType(hObj, userName, aliasTypeObj)
addUserDataType(hObj, userName, numericTypeObj)
addUserDataType(hObj, userName, fixdtString)
Registers the specified user-defined data type and adds it to the top of the data type list, as displayed in the Data type pull-down list in the Model Explorer.
userName — Name of the user data type
builtinName — MathWorks C/C++ data type to which userName is mapped
userHeader — Name of the user header file that includes the definition of the user data type
aliasTypeObj, numericTypeObj, or fixdtString — Simulink.AliasType, Simulink.NumericType, or fixdt to which userName is mapped
moveUserDataTypeToTop(hObj, userName)
Moves the specified user-defined data type to the top of the data type list, as displayed in the Data type pull-down list in the Model Explorer.
moveUserDataTypeToEnd(hObj, userName)
Moves the specified user-defined data type to the end of the data type list, as displayed in the Data type pull-down list in the Model Explorer.
removeUserDataType(hObj, userName)
Removes the specified user-defined data type from the data type list.
Your instance of the sl_customization function should use these methods to register user data types for your Simulink installation.
The Simulink software reads the sl_customization.m file when it starts. If you subsequently change the file, to use the changes you must restart your Simulink session or enter the following command at the MATLAB command line:
sl_refresh_customizations
Example User Data Type Customization Using sl_customization.m. The sl_customization.m file shown in sl_customization.m for User Data Type Customizations uses the following methods:
addUserDataType to register the user-defined data types MyInt16, MyInt32, MyBool, and fixdt(1,8)
moveUserDataTypeToTop to move MyBool to the top of the data type list, as displayed in the Data type pull-down list in the Model Explorer
removeUserDataType to remove the built-in data types boolean and double from the data type list
sl_customization.m for User Data Type Customizations
function sl_customization(cm)
% Register user customizations
% Get default (factory) customizations
hObj = cm.slDataObjectCustomizer;
% Add custom types
hObj.addUserDataType('MyInt16', 'int16_T', '<mytypes.h>');
hObj.addUserDataType('MyInt32', 'int32_T', '<mytypes.h>');
hObj.addUserDataType('MyBool','boolean_T');
hObj.addUserDataType('fixdt(1,8)');
% Make MyBool first in the list
hObj.moveUserDataTypeToTop('MyBool');
% Remove built-in boolean and double from the list
hObj.removeUserDataType('boolean');
hObj.removeUserDataType('double');
endIf you include the above file on the MATLAB path of the Simulink installation that you want to customize, the specified customizations will appear in Model Explorer. For example, you could view the customizations as follows:
Start a MATLAB session.
Open Model Explorer, for example, by entering the MATLAB command daexplr.
Select Base Workspace.
Add an mpt signal, for example, by selecting Add > MPT Signal.
In the right-hand pane display for the added mpt signal, examine the Data type drop-down list, noting the impact of the changes specified in sl_customization.m for User Data Type Customizations.
Introduction. Embedded Coder software allows you to create custom mpt object types and specify properties and property values to be associated with them (see Create mpt Data Objects with Data Object Wizard). Once created, a user object type can be applied to data objects displayed in Model Explorer. When you apply a user object type to a data object, by selecting a type name in the User object type pull-down list in Model Explorer, the data object is automatically populated with the properties and property values that you specified for the user object type.
To register mpt user object type customizations, use the Simulink customization file sl_customization.m. This file is a mechanism that allows you to use MATLAB code to perform customizations of the standard Simulink user interface. The Simulink software reads the sl_customization.m file, if present on the MATLAB path, when it starts and the customizations specified in the file are applied to the Simulink session. For more information on the sl_customization.m customization file, see Customizing the Simulink User Interface in the Simulink documentation.
Register mpt User Object Types Using sl_customization.m. To register mpt user object type customizations, you create an instance of sl_customization.m and include it on the MATLAB path of the Simulink installation that you want to customize. The sl_customization function accepts one argument: a handle to a customization manager object. For example,
function sl_customization(cm)
As a starting point for your customizations, the sl_customization function must first get the default (factory) customizations, using the following assignment statement:
hObj = cm.slDataObjectCustomizer;
You then invoke methods to register your customizations. The customization manager object includes the following methods for registering mpt user object type customizations:
addMPTObjectType(hObj, objectTypeName, classtype, propName1, propValue1, propName2, propValue2, ...)
addMPTObjectType(hObj, objectTypeName, classtype, {propName1, propName2, ...}, {propValue1, propValue2, ...})
Registers the specified user object type, along with specified values for object properties, and adds the object type to the top of the user object type list, as displayed in the User object type pull-down list in the Model Explorer.
objectTypeName — Name of the user object type
classType — Class to which the user object type applies: 'Signal', 'Parameter', or 'Both'
propName — Name of a property of an mpt or mpt-derived data object to be populated with a corresponding propValue when the registered user object type is selected
propValue — Specifies the value for a corresponding propName
moveMPTObjectTypeToTop(hObj, objectTypeName)
Moves the specified user object type to the top of the user object type list, as displayed in the User object type pull-down list in the Model Explorer.
moveMPTObjectTypeToEnd(hObj, objectTypeName)
Moves the specified user object type to the end of the user object type list, as displayed in the User object type pull-down list in the Model Explorer.
removeMPTObjectType(hObj, objectTypeName)
Removes the specified user object type from the user object type list.
Your instance of the sl_customization function should use these methods to register mpt object type customizations for your Simulink installation.
The Simulink software reads the sl_customization.m file when it starts. If you subsequently change the file, to use the changes, you must restart your MATLAB session.
Example mpt User Object Type Customization Using sl_customization.m. The sl_customization.m file shown in sl_customization.m for mpt Object Type Customizations uses the addMPTObjectType method to register the user signal types EngineType and FuelType for mpt objects.
sl_customization.m for mpt Object Type Customizations
function sl_customization(cm)
% Register user customizations
% Get default (factory) customizations
hObj = cm.slDataObjectCustomizer;
% Add commonly used signal types
hObj.addMPTObjectType(...
'EngineType','Signal',...
'DataType', 'uint8',...
'Min', 0,...
'Max', 255,...
'DocUnits','m/sec');
hObj.addMPTObjectType(...
'FuelType','Signal',...
'DataType', 'int16',...
'Min', -12,...
'Max', 3000,...
'DocUnits','mg/hr');
endIf you include the above file on the MATLAB path of the Simulink installation that you want to customize, the specified customizations will appear in Model Explorer. For example, you could view the customizations as follows:
Start a MATLAB session.
Open Model Explorer, for example, by entering the MATLAB command daexplr.
Select Base Workspace.
Add an mpt signal, for example, by selecting Add > MPT Signal.
In the right-hand pane display for the added mpt signal, examine the User object type drop-down list, noting the impact of the changes specified in sl_customization.m for mpt Object Type Customizations.
From the User object type drop-down list, select one of the registered user signal types, for example, FuelType, and verify that the displayed settings are consistent with the arguments specified to the addMPTObjectType method in sl_customization.m.
You can replace built-in data type names with user-defined replacement data type names in the generated code for a model.
To configure replacement data types,
In the Model Editor, set the simulation mode of the open model. From the Simulation menu, select Normal, Software-in-the-loop (SIL), or Processor-in-the-loop (PIL).
In the Configuration Parameters dialog box, click Code Generation > Data Type Replacement > Replace data type names in the generated code. A Data type names table appears. The table lists each Simulink built-in data type name with its corresponding code generation data type name.
Fill in fields in the third column with your replacement data types. Each replacement data type should be the name of a Simulink.AliasType object that exists in the base workspace. Replacements may be specified or not for each individual built-in type.
For each replacement data type you enter, the BaseType property of the associated Simulink.AliasType object must be consistent with the built-in data type it replaces.
For double, single, int32, int16, int8, uint32, uint16, and uint8, the replacement data type's BaseType must match the built-in data type.
For boolean, the replacement data type's BaseType must be either an 8-bit integer or an integer of the size displayed for Number of bits: int on the Hardware Implementation pane of the Configuration Parameters dialog box.
For int, uint, and char, the replacement data type's size must match the size displayed for Number of bits: int or Number of bits: char on the Hardware Implementation pane of the Configuration Parameters dialog box.
An error occurs, if
A replacement data type specification is inconsistent.
The Simulink.AliasType object has the Data scope parameter set to Exported.
If your application requires you to replace built-in data type names with user-defined replacement data type names in the generated code, you can do so from the Code Generation > Data Type Replacement pane of the Configuration Parameters dialog box.
This pane is available for ERT target based Simulink models. In addition to providing a mechanism for mapping built-in data types to user-defined replacement data types, this feature:
Performs consistency checks so that your specified data type replacements are consistent with your model's data types.
Allows many-to-one data type replacement, the ability to map multiple built-in data types to one replacement data type in generated code. For example, built-in data types uint8 and boolean could both be replaced in your generated code by a data type U8 that you have previously defined.
Note For limitations that apply, see Data Type Replacement Limitations. |
If you select Replace data type names in the generated code, the Data type names table is displayed.
The table Data type names lists each Simulink built-in data type name along with its code generation data type name. Selectively fill in fields in the third column with your replacement data types. Each replacement data type should be the name of a Simulink.AliasType object that exists in the base workspace. Replacements may be specified or not for each individual built-in type. For each replacement data type entered, the BaseType property of the associated Simulink.AliasType object must be consistent with the built-in data type it replaces.
For double, single, int32, int16, int8, uint32, uint16, uint8, the replacement data type's BaseType must match the built-in data type.
For boolean, the replacement data type's BaseType must be either an 8-bit integer or an integer of the size displayed for Number of bits: int on the Hardware Implementation pane of the Configuration Parameters dialog box.
For int, uint, and char, the replacement data type's size must match the size displayed for Number of bits: int or Number of bits: char on the Hardware Implementation pane of the Configuration Parameters dialog box.
An error occurs if a replacement data type specification is inconsistent.
Note It is not recommended to use data type replacement to work around data type checking. You should not intentionally replace a data type with a type that has inconsistent characteristics, such as replacing real_T with a type name that maps to a single-precision data type (inconsistent size). Remapping to inconsistent types might introduce significant numerical differences, relative to simulation results, and erroneous behavior. Examples of inconsistencies include:
|
For example, suppose that you have previously defined the following replacement data types, which exist as Simulink.AliasType objects in the base workspace:
| User-Defined Name | Description |
|---|---|
| FLOAT64 | 64-bit floating point |
| FLOAT32 | 32-bit floating point |
| S32 | 32-bit integer |
| S16 | 16-bit integer |
| S8 | 8-bit integer |
| U32 | Unsigned 32-bit integer |
| U16 | Unsigned 16-bit integer |
| U8 | Unsigned 8-bit integer |
| CHAR | Character data |
You can fill in the Data Type Replacement pane with a one-to-one replacement mapping, as follows:
You can also apply a many-to-one data type replacement mapping. For example, in the following display:
int32 and int are replaced with user type S32
uint32 and uint are replaced with user type U32
uint8 and boolean are replaced with user type U8
Note Many-to-one data type replacement does not support the char (char_T) built-in data type. Use char only in one-to-one data type replacements. |
The user-defined replacement types you specify will appear in your model's generated code in place of the corresponding built-in data types. For example, if you specify user-defined data type FLOAT64 to replace built-in data type real_T (double), then the original generated code shown in Example 3: Generated Code with real_T Built-In Data Type will become the modified generated code shown in Example 4: Generated Code with FLOAT64 Replacement Data Type.
Example 3: Generated Code with real_T Built-In Data Type
...
/* Model initialize function */
void sinwave_initialize(void)
{
...
{real_T *dwork_ptr = (real_T *) &sinwave_DWork.lastSin;
...
}
...Example 4: Generated Code with FLOAT64 Replacement Data Type
...
/* Model initialize function */
void sinwave_initialize(void)
{
...
{FLOAT64 *dwork_ptr = (FLOAT64 *) &sinwave_DWork.lastSin;
...
}
...To replace the built-in data type names for your model, modify the ReplacementTypes property, which is managed as a structure. The following lines of example code show how you can modify the ReplacementTypes property to replace the built-in data type names int8, uint8, and boolean with user-defined data type names my_T_S8, my_T_U8, and my_T_BOOL, respectively.
model = bdroot; cs = getActiveConfigSet(model); set_param(cs,'EnableUserReplacementTypes','on'); struc = get_param(cs,'ReplacementTypes'); struc.int8 = 'my_T_S8'; struc.uint8 = 'my_T_U8'; struc.boolean = 'my_T_BOOL'; set_param(cs,'ReplacementTypes',struc);
Using data type replacement, you can replace the boolean built-in data type with any integer type in the generated code. The integer type might improve the performance of the generated code on your production hardware:
int8
uint8
intn
where n is 8, 16, or 32, matching the integer word size for the production hardware (for example, int32 for 32-bit hardware).
For example, to map boolean to the int32 data type, perform the following steps.
Define a Simulink.AliasType object with a base type of int32:
mybool = Simulink.AliasType; mybool.BaseType = 'int32';
Open an ERT-based model. In the Data Type Replacement pane of the Configuration Parameters dialog box, map boolean (boolean_T) to the replacement data type mybool.
In the resulting generated code, boolean is replaced with mybool. For example, rtwtypes.h contains:
/* Generic type definitions ... */ ... typedef int boolean_T; ... /* Define RTW replacement data types. */ typedef boolean_T mybool; /* User defined replacement datatype for boolean_T */
Boolean data in the generated code is declared with mybool. For example, given a model with a Boolean output Out1, an Out1 declaration such as
boolean_T Out1; /* '<Root>/Out1' */
instead is generated in model.h as
mybool Out1; /* '<Root>/Out1' */
Data type replacements are ignored during code generation for a model unless the simulation mode of the model is set to Normal, Software-in-the-Loop (SIL), or Processor-in-the-Loop (PIL). Set the simulation mode from the Simulation menu in the Model Editor.
Data type replacement does not support multiple levels of mapping. Each replacement data type name maps directly to one or more built-in data types.
Data type replacement is not supported for simulation target code generation for referenced models.
Data type replacement is not supported if the Classic call interface option is selected for your model.
Data type replacement occurs during code generation for all .c, .cpp, and .h files generated in build directories (including top and referenced model build directories) and in the _sharedutils directory. Exceptions are as follows:
| rtwtypes.h |
| model_sf.c or .cpp (ERT S-function wrapper) |
| model_dt.h (C header file supporting external mode) |
| model_capi.c or .cpp |
| model_capi.h |
Data type replacement is not supported for complex data types.
Many-to-one data type replacement is not supported for the char built-in data type. Attempting to use char as part of a many-to-one mapping to a user-defined data type introduces a violation of the MISRA C specification. Specifically, if char (char_T) and either int8 (int8_T) or uint8 (uint8_T) are mapped to the same user replacement type, the result is a MISRA C violation. Additionally, if you try to generate C++ code, invalid implicit type casts are made and compile-time errors may result. Use char only in one-to-one data type replacements.
For ERT S-functions, you can replace the boolean built-in data type with only an 8–bit integer, int8 or uint8.
A data dictionary contains all of the parameters and signals that the source code uses, and a description of their properties. The data dictionary that is created for Simulink and Stateflow models is called the code generation data dictionary. (You can use the data dictionary for simulation. This does not require that you have a Embedded Coder license.) The dictionary is the total number of data objects that appear in the middle pane of the Model Explorer. These data objects also appear in the MATLAB workspace. The procedure described in this chapter allows you to create or edit the dictionary. The procedure allows you to control property values for each data object. This, in turn, determines how each parameter and signal is defined and declared in the automatically generated code.
The values of data object properties are used to determine where the code generator places a parameter or signal in the generated file. This is because some property values are associated with different template symbols. The location of a symbol in a template determines where the associated parameter or signal is located in the generated file. For details about templates and symbols, see Configure Templates for Customizing Code Organization and Format.
It is helpful to define terms you will see when managing the dictionary, especially when you view them using the Model Explorer. The Simulink software uses a hierarchy of terms that are drawn from object-oriented programming. For details, see Working with Data Objects in the Simulink documentation. The sketch below summarizes this hierarchy.
Simulink or mpt is the package. Parameter and Signal are two classes in each of these packages. Each class has a number of properties associated with it. Sometimes properties are called attributes. Data objects (the parameters and signals) are the instances of a package.class that make up the data dictionary. All parameter data objects have a set of properties. All signal data objects have a different set of properties than that for parameters. For each data object, each property in the set has its own property value that must be specified in the dictionary.
Ways to Create Data Objects. The Embedded Coder software provides the mpt (module packaging tool) data object, which contains all the properties of Simulink data objects plus properties that provide additional control over module packaging. For a comparison of the properties of Simulink and mpt data objects, see Simulink and mpt Data Object Comparison.
There are different ways of creating Simulink and mpt data objects for a data dictionary.
One-by-one, either using the MATLAB command line or using the Model Explorer Add menu and selecting Simulink Parameter, Simulink Signal, MPT Parameter, or MPT Signal. For more information, see Working with Data Objects in the Simulink documentation.
All at once, invoking Data Object Wizard for an existing model. For more information and examples, see Data Object Wizard in the Simulink documentation and Create mpt Data Objects with Data Object Wizard.
Creating data objects based on an external data dictionary. You can do this manually item by item, or all at once automatically using a script. For more information, see Create Data Objects Based on an External Data Dictionary.
The following sections illustrate how to create Simulink and mpt data objects and compares their properties as data types.
Create Simulink Data Objects with Data Object Wizard. You can use Data Object Wizard to create data objects for your model (see Data Object Wizard in the Simulink documentation).
Data Object Wizard is especially useful for creating multiple data objects for
Existing models that do not currently use data objects.
Existing models to which you have added signals or parameters and therefore you need to create more data objects.
This procedure creates Simulink data objects using Data Object Wizard.
Open the model whose data objects you want to be in the data dictionary. For example, open rtwdemo_mpf.mdl (which is located in toolbox/rtw/rtwdemos).
Open Data Object Wizard by entering dataobjectwizard at the MATLAB command line or by selecting Data Object Wizard from the Tools menu of your model. The Data Object Wizard dialog box appears:
The Model name field displays the name of the model. You could specify a different model by editing the field or by selecting the model using the adjacent Browse button. When the Model name field is nonempty, the Find button is enabled.
In the Find options pane, select the desired check boxes. For descriptions of each check box, see Data Object Wizard in the Simulink documentation. Be sure to check the Alias types option. This finds all user-registered data types in the sl_customization.m file plus all data type replacements specified for the model in the Data Type Replacement pane of the Configuration Parameters dialog box. Data Object Wizard can create Simulink.AliasType objects from these.
Click the Find button. After a moment, a list of all of the model's potential data objects appear that are not yet in the code generation data dictionary, as shown below. This includes all of the model's signals (root inputs, root outputs, and block outputs), discrete states, data stores, and parameters, depending on:
The check boxes you selected in the previous step
The constraint mentioned in the note above
Data Object Wizard finds only those signals, parameters, data stores, and states whose storage class is set to Auto. The Wizard lists each data store and discrete state that it finds as a signal class.
Click Check All to select all data objects. Notice in the Choose package for selected data objects field that Simulink, the default, is selected. So all of the data objects are associated with the Simulink package, as shown below.
Click Create. The data objects are added to the MATLAB workspace, and they disappear from Data Object Wizard.
Click Cancel. The Data Object Wizard dialog box disappears.
Now you can set property values for the data objects.
Most of the property values of data objects are supplied by defaults. A few are from the model. Note that for Simulink data objects, the default storage class is Auto.
Type daexplr on the MATLAB command line, and press Enter. The Model Explorer appears.
In the Model Hierarchy (left) pane, select Base Workspace. All of the Simulink data objects in the code generation data dictionary appear in the Contents (middle) pane, as shown below.
If the objects that you see do not appear in the order shown, click the Name column header in the middle pane to sort the objects in ascending order by name.
To see the properties of a Simulink data object, select a data object in the middle pane. The right pane displays the property names for that object. These property names also appear as column headings in the middle pane. Reshape the middle pane to see all the headings. For example, if you select signal data object A in the middle pane, the Model Explorer looks like this:
You can change the values specified for the properties of the selected object. For example, with A selected, change its StorageClass property from Auto to Default (Custom), then click Apply. The property changes as shown below:
You can use Control-Right-Click to select multiple objects in the center pane, then edit any property value. The wizard applies the new value to all selected objects. For descriptions of object properties and their values, see Parameter and Signal Property Values.
Generate and Inspect Code.All data objects for the model are in the code generation data dictionary. You have specified property values for each data object's properties. Now you generate and inspect the source code, to see if it needs correction or modification. If it does, you can change property values and regenerate the code until it is what you want.
In the Configuration Parameters dialog box, click Code Generation in the left pane.
In the Report pane, select the Create code generation report check box.
Note When you select the Create code generation report check box, the code generation software automatically selects two check boxes on the pane: Launch report automatically and Code-to-model. For large models, you may find that HTML report generation (step 4 below) takes longer than you want. In this case, consider clearing the Code-to-model check box (and the Model-to-code check box if selected). The report will be generated faster. |
In the Code Generation pane, select the Generate code only check box. The Build button changes to Generate code.
Note The generate code process generates the .c/.cpp and .h files. The build process adds compiling and linking to generate the executable. For details on build, see How an Executable Program Is Built From a Model . |
Click the Generate code button. After a moment, the HTML code generation report appears, listing the generated files on the left pane.
Select and review files in the HTML code generation report. See Include Traceability in HTML Code Generation Report for more information.
Create mpt Data Objects with Data Object Wizard. Create mpt data objects using Data Object Wizard the same way you did for Simulink data objects, as explained in Create Simulink Data Objects with Data Object Wizard, except select mpt as the package instead of Simulink.
Set the property values for the mpt data objects the same way you set them for Simulink data objects, as explained in Set Property Values for Simulink Data Objects, with the following exceptions:
Accept the default custom storage class for mpt data objects, Global(Custom)
For data objects A and F1, type mydefinitionfile in the Definition file field on the Model Explorer.
Then generate and inspect the code.
Note The Alias field is related to Apply Naming Rules to Identifiers Globally. |
Simulink and mpt Data Object Comparison. The mpt data object contains all the properties of Simulink data objects plus properties that provide additional control over module packaging. The differences between Simulink and mpt data objects can be illustrated by comparing
Key differences include the following:
Different custom storage classes displayed in the Model Explorer for mpt data objects provide more control over the appearance of the generated code.
Additional custom attributes (owner, definition file, persistence level, memory section) for mpt data objects provide more control over data packaging in the generated code.
On the Comments pane of the Configuration Parameters dialog box, the Custom comments (MPT objects only) option allows you to add a comment just above a signal or parameter's identifier in the generated code.
On the Code Placement pane of the Configuration Parameters dialog box, in the Global data placement (MPT data objects only) subpane:
The Signal display level parameter allows you to specify whether or not the code generator declares a signal data object as global data
The Parameter tune level parameter allows you to specify whether or not the code generator declares a parameter data object as tunable global data
The properties that appear in Model Explorer when mpt is the package include all the properties that appear when Simulink is the package plus additional properties. Notice this by comparing the next two figures. (For descriptions of all properties in Model Explorer, see Parameter and Signal Property Values.)
The following configuration parameters relate to module packaging features. These parameters are available in the Configuration Parameters dialog box and Model Explorer when the system target file selected for a Simulink model is ert.tlc (or a system target file derived from an ert.tlc):
Custom comments (MPT objects only) option on the Code Generation > Comments pane
In the Global data placement (MPT data objects only) subpane on the Code Generation > Code Placement pane:
Signal display level parameter
Parameter tune level parameter
In the example used in Set Property Values for Simulink Data Objects, you selected Default (Custom) in the Storage class field for signal A and parameter F1. You selected the default Auto in the Storage class field for the remaining data objects. But for the mpt data objects you used the default Global (Custom) in the Storage class field for all data objects. When you generated code, these selections resulted in the definitions and declarations shown in the table below.
| Simulink Data Object with Auto Storage Class | Simulink Data Object with Default (Custom) Storage Class | mpt Data Object with Global (Custom) Storage Class and Definition File Named mydefinitionfile |
|---|---|---|
In rtwdemo_mpf.c: /* For signal A */
ExternalInputs rtU;
/* For parameter F1 */
if(rtU.A * 2.0 > 10.0) {...In rtwdemo_mpf.h: /* For signal A */
typedef struct {
real_T A;
} ExternalInputs;
extern ExternalInputs rtU; | In global.c: real_T A; real_T F1 = 2.0; In global.h: extern real_T A; extern real_T F1; | In mydefinitionfile.c: real_T A; real_T F1 = 2.0; In global.h: extern real_T A; extern real_T F1; |
The results shown in the second and third columns of the preceding table require the following configuration parameter adjustments on the Code Generation > Code Placement pane:
Set Data definition to Data defined in single separate source file.
Set Data definition filename to global.c
Set Data declaration to Data declared in single separate source file.
Set Data definition filename to global.h
See the left column of the table, which shows generated code for Simulink signal and parameter data objects, whose Storage class field is Auto. The input A is defined as part of the structure rtU as shown above. In the case of the Simulink parameter data object F1, since the StorageClass was set to auto, the code generator chose to include the literal value of F1 in the generated code. F1 is a constant in the Stateflow diagram whose value is initialized as 2.0:
if(rtU.A * 2.0 > 10.0) { ...For more details, see Introduction to Custom Storage Classes and Summary of Signal Storage Class Options .
See the middle column of the table. The Simulink data objects whose Storage class is not Auto are defined in a definition statement in the global source file (global.c) and declared in a declaration statement in the global header file (global.h).
In the right column, Simulink data objects whose Storage class is not Auto are defined in mydefinitionfile, as you specified. The declarations for those objects are in the global header file.
Create Data Objects Based on an External Data Dictionary. This procedure creates data objects based on an external data dictionary (such as a Microsoft® Excel® file). You can do this manually (that is, one-by-one) or automatically (all at once).
Manually Creating Objects to Represent External Data.You can create data objects (and their properties) one-by-one, based on an external data dictionary, as follows:
Open the external file that contains the data (such as a spreadsheet or database file).
Determine all of the data in this file that correspond to the parameters and signals in the model. In the code generation data dictionary, parameters in the external file belong to the Simulink parameter class and signals belong to the Simulink signal class.
On the MATLAB command line, type daexplr and press Enter. The Model Explorer appears.
On the Model Hierarchy (left) pane, expand Simulink Root, and select Base Workspace.
On the Add menu, select MPT Parameter or Simulink Parameter. The default name Param appears in the Contents of (middle) pane.
Repeat steps 5 and 6 for each additional data item in the external file that belongs to the mpt.Parameter class or Simulink.Parameter class.
Now you will add data items in the external file that belong to the mpt.Signal class or Simulink.Signal class.
On the Add menu, select MPT Signal or Simulink Signal. The default name Sig appears in the Contents of pane.
Repeat steps 8 and 9 for each additional data item in the external file that belongs to the mpt.Signal class or Simulink.Signal class.
All external data items for the mpt.Parameter or Simulink.Parameter class, and the mpt.Signal or Simulink.Signal class now appear in the Contents of pane and in the MATLAB workspace. Therefore, they have been created in the code generation data dictionary.
You can create data objects (and their properties) all at once, based on an external data dictionary by creating and running a .m file. This file contains the same MATLAB commands you could use for creating data objects one-by-one on the command line, as explained in Working with Data Objects in the Simulink documentation. But instead of using the command line, you place the MATLAB commands in the .m file for all of the desired data in the external file:
Create a new .m file.
Place information in the file that describes all of the data in the external file that you want to be data objects. For example, the following information creates two mpt data objects with the indicated properties. The first is for a parameter and the second is for a signal:
% Parameters mptParCon = mpt.Parameter; mptParCon.CoderInfo.CustomStorageClass ='Const'; mptParCon.value = 3; % Signals mptSigGlb = mpt.Signal; mptSigGlb.DataType = 'int8';
Run the .m file. The data objects appear in the MATLAB workspace.
Note If you want to import data from an external data dictionary, you can write functions that read the information, convert these to data objects, and load them into the MATLAB workspace. Among available MATLAB functions that you can use for this process are xmlread, xmlwrite, xlsread, xlswrite, csvread, csvwrite, dlmread, and dlmwrite. |
In this procedure, you create a data dictionary for a model using Data Object Wizard, inspect the data dictionary, and generate code. Definitions for the data objects in the dictionary are generated into the model source file (model.c).
Open the demo model rtwdemo_mpf by clicking the link or by typing rtwdemo_mpf in the MATLAB Command Window.
In this model,
A, B, and C are input signals, and L and Final are output signals.
Subsystem1 receives inputs A and E and contains constants G1 and G2. Signal E is an output from Data Store Read1.
Subsystem2 receives inputs C and D. Signal D is an output from Data Store Read2. There is a constant in Subsystem2 named G3. Also, this subsystem has a Unit Delay block whose state name is SS.
Double-click the Stateflow chart and notice it has constants F1, Gain1, and Gain2, as shown below:
Change to a work folder that is not on an installation path and save the model in that work folder. The code generation software does not allow you to generate code from an installation folder.
Double-click the Invoke Data Object Wizard button on the model. Or, type dataobjectwizard('rtwdemo_mpf') in the MATLAB Command Window. Data Object Wizard opens and rtwdemo_mpf appears in the Model name field, as shown below.
Click Find on Data Object Wizard. After a moment, the model's parameters and signals appear in Data Object Wizard. These "data objects" make up the data dictionary.
Click Check All, to select all data objects for the data dictionary.
In the Choose package for selected objects field, select mpt. For an explanation of "package," see Overview of the Data Dictionary.
Click Apply Package. Data Object Wizard associates the selected data objects with the mpt package, as shown below.
Click Create. Data Object Wizard creates a data dictionary, consisting of data objects for the selected parameters and signals. Data Object Wizard removes the objects from its object view. Also, the objects are added to the MATLAB workspace, as shown below.
Inspect the Data Dictionary. You can verify that each data object you selected in Data Object Wizard is in the data dictionary, using the Model Explorer:
If you have not already done so, complete the steps in Use Data Object Wizard .
In the left pane, select Base Workspace. Notice that all data objects that you placed in the data dictionary appear in the middle pane.
In the middle pane, select data objects one at a time, and notice their property values in the right pane. The figure below shows this for signal A. All of the data objects have default property values. Note that for an mpt data object, the default in the Storage class field is Global (Custom). For descriptions of the properties on the Model Explorer, see Set Property Values for Simulink Data Objects.
If you have not already done so, complete the steps in Use Data Object Wizard and Inspect the Data Dictionary.
In the left pane of the Model Explorer, expand the rtwdemo_mpf node.
In the left pane, click Configuration (Active).
In the center pane, click Code Generation. The active configuration parameters appear in the right pane.
In the Report tab, select Create code generation report
Select the General tab. Select Generate code only, and then click Generate code. After a few moments, the names of the generated files are listed on the Code Generation Report on the left pane.
Open and inspect the content of the model source file rtwdemo_mpf.c. The following data objects in the data dictionary are initialized in this file.
real_T F1 = 2.0; real_T G1 = 6.0; real_T G2 = -2.6; real_T G3 = 9.0; real_T Gain1 = 5.0; real_T Gain2 = -3.0;
The previous procedure placed all of the model's data objects in the model source file. Now you place all of the global data objects in a file separate from the model source file:
Configure the model's generated code to include all Simulink data objects (signal and parameter) in a separate definition file. Set Diagnostics > Data Validity > Signal resolution to Explicit and implicit.
Specify that data be defined in a separate file. Set Code Generation > Code Placement > Data definition to Data defined in single separate source file. Accept the default for Data definition filename, global.c
Specify that data be declared in a separate file. Set Data declaration to Data declared in a single separate header file and accept the default for Data declaration filename, global.h. Then, click Apply.
Click Generate code. Notice that the code generation report lists global.c and global.h files.
Inspect the code generation report. Notice that
The data objects formerly initialized in rtwdemo_mpf.c now are initialized in global.c.
The file rtwdemo_mpf.c includes rtwdemo_mpf.h.
The file rtwdemo_mpf.h includes global.h.
The previous procedure placed all global data objects in a separate definition file, in one operation. You named that file global.c. (You named the corresponding declaration file global.h.) MPF allows you to override this and place a specific data object in its own definition file. In the following procedure, you move the Final signal to a file called finalsig.c, and keep all the other data objects defined in global.c:
In the Model Explorer, display the base workspace and select the Final signal object. The mpt.Signal properties appear in the right pane.
In the Code generation options section, type finalsig.h in the Header file text box, type finalsig.c in the Definition file text box, and click Apply.
On the Code Generation > General pane, click Generate code. The code generation report still lists global.c and global.h, but adds finalsig.c and finalsig.h.
Open all four files to inspect them. Notice that the Final signal is defined in finalsig.c. All other data objects in the dictionary are defined in global.c.
In a .mat file, you can save the set of data objects (and their properties) that you have created and load this information for later use or exchange it with another user. You can save some of the data objects in the workspace or all of them. See Opening, Loading, Saving Files in the MATLAB documentation.
Overview. Signal and parameter names appear on a Simulink model. The same names appear as data objects on the Model Explorer. By default, these names are replicated exactly in the generated code. For example, "Speed" on the model (and workspace) appears as the identifier "Speed" in the code, by default. But you can change how they appear in the code. For example, if desired, you can change "Speed" to SPEED or speed. Or, you can choose to use a different name altogether in the generated code, like MPH. The only restriction is that you follow ANSI C[2] /C++ rules for naming identifiers.
There are two ways of changing how a signal name or parameter name is represented in the generated code. You can do this globally, by following the procedure in this section. This procedure makes selections on the Configuration Parameters dialog box to change all of the names when code generation occurs, according to the same rule. Or, you can change the names individually by following the steps described in Set Property Values for Simulink Data Objects. The relevant field in that procedure is Alias on the Model Explorer.
If the Alias field is empty, the naming rule that you select on the Configuration Parameters dialog box applies to all data objects. But if you do specify a name in the Alias field, this overrides the naming rule for that data object. The table below illustrates these cases. The table assumes that you selected Force lower case as the naming rule. But with the information provided, you can determine how any of the naming rules works for an mpt data object or a Simulink data object (Force upper case, Force lower case, or Custom M-function).
Naming Rules and Alias Override (Global Change of Force Lower Case Rule)
| Name of Data Object in Model | Name in Alias Field | Package | Result in Generated Code |
|---|---|---|---|
A |
| Simulink or mpt | a |
A | D | Simulink or mpt | D |
Change Names of Identifiers. This procedure changes the names of all signal identifiers, except one, so that they are spelled with all lowercase letters. For example, A in the definition statement located in global.c is changed to a. The one exception is the Final signal in the finalsig.c file. You change this identifier name to Final_Signal. The names of the rest of the identifiers in the generated files remain the same:
Open the Code Generation > Symbols pane of the Configuration Parameters dialog.
In the Simulink data object naming rules section, set Signal naming to Force lower case, and click Apply.
In the right pane, type Final_Signal in the Alias text box, then click Apply.
On the Code Generation > General pane, click Generate code . Now, the signal identifiers in global.c and global.h appear with lowercase letters.
real_T F1 = 0.0; real_T G1 = 1.0; real_T G2 = 1.0; real_T G3 = 1.0; real_T Gain1 = 0.0; real_T Gain2 = 0.0; real_T a; real_T b; real_T c; real_T d; real_T ds; real_T e; real_T l; real_T ss;
The statement defining the Final signal in finalsig.c looks like this:
real T Final_Signal;
The statement declaring this identifier in finalsig.h looks like this:
extern real_T Final_Signal;
Specify Simulink Data Object Naming Rules. You specify Simulink data object naming rules on the Code Generation > Symbols pane of the Configuration Parameters dialog box. To access that pane,
Open an ERT-based model.
Open the Configuration Parameters dialog box from the Simulation menu or Model Explorer.
Open the Code Generation > Symbols pane. See the subpane Simulink data object naming rules.
Notice the preconfigured settings on this pane. If all of these are acceptable as is, proceed to Create User Data Types for mpt Data Objects. Otherwise, follow the procedures below, as desired, to change signal names, parameter names, or parameter names that you want to use in a #define preprocessor directive. Code Generation Pane: Symbols describes all fields on this pane and their possible settings for these procedures.
Define Rules That Change All Signal Names. This procedure allows you to change all of the model's signal names, using the same rule. The new names will appear as identifiers in the generated code:
In the Signal naming menu, click the desired selection. (Signal naming explains the possible selections.) The default is None. If you selected Custom M-function, go to the next step. Otherwise, click Apply and then generate and inspect code.
Write a MATLAB function that changes all occurrences of signal names in the model to appear the way you want as identifiers in the generated code. (An example is shown in Define Rules That Change All Parameter Names.)
Save the function as a .m file in any folder that is in the MATLAB path.
In the M-function field under Signal naming, type the name of the file you saved in the previous step.
Define Rules That Change All Parameter Names. This procedure allows you to change all of the model's parameter names, using the same rule. The new names will appear as identifiers in the generated code:
In the Parameter naming field, click the desired selection. (Parameter naming explains the possible selections.) The default is None. If you selected Custom M-function, go to the next step. Otherwise, click Apply, and proceed to Define Rules That Change All Signal Names.
Write a MATLAB function that changes all occurrences of parameter names in the model to appear the way you want as identifiers in the generated code. For example, the code below changes all parameter names to make their first letter uppercase, and their remaining letters lowercase.
function revisedName = initial_caps_only(name, object) % INITIAL_CAPS_ONLY: User-defined naming rule causing each % identifier in the generated code to have initial cap(s). % % name: name as spelled in model. % object: the object of name; includes name's properties. % % revisedName: manipulated name returned to MPT for the code. % % : revisedName = [upper(name(1)),lower(name(2:end))]; :
Save the function as a .m file in any folder that is in the MATLAB path.
In the M-function field under Parameter naming, type the name of the file you saved in the previous step.
Click Apply and then define rules that apply to all signal names.
Define Rules That Change All #defines. This procedure allows you to change all of the model's parameter names whose storage class you selected as Define in Create mpt Data Objects with Data Object Wizard, using the same rule. The new names will appear as identifiers in the generated code:
In #define naming, click the desired selection. (#define naming explains the possible selections.) The default is None. If you select Custom M-function, go to the next step. Otherwise, click Apply and proceed to Define Rules That Change All Parameter Names.
Write a MATLAB function that changes all occurrences of the parameter name whose storage class you specified as Define in Create mpt Data Objects with Data Object Wizard so that it appears the way you want as an identifier in the generated code. (An example is shown below.)
Save the function as a .m file in any folder that is in the MATLAB path.
In the M-function field under #define naming, type the name of the file you saved in the previous step.
Click Apply and then define rules that change all parameter names.
[1] ANSI is a registered trademark of the American National Standards Institute, Inc.
[2] ANSI is a registered trademark of the American National Standards Institute, Inc.
 | Data Representation | Module Packaging Tool (MPT) Data Objects |  |
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 |
