www.gusucode.com > ecoder 案例源码程序 matlab代码 > ecoder/ConfigureDataInterfaceDemoExample.m
%% Configure Data Interface in the Generated Code % Specify signals, states, and parameters for inclusion in generated code. % % Learn how to control these attributes of data % in the generated code: % % * Name % * Data type % * Data storage class % % For information about the example model and other examples in this % series, see <docid:ecoder_examples.example-rtwdemo_pcgd_stage_1_p1_script>. %% Open Example Model % <matlab:RTWDemos.pcgd_open_pcg_model(2,0); Open the example model, |rtwdemo_PCG_Eval_P2|>. open_system('rtwdemo_PCG_Eval_P2') %% Data Declaration % Most programming languages require that you _declare_ data and functions % before using them. The declaration specifies: % % * Scope: The region of the program that has access to the data % * Duration: The period during which the data exist in memory % * Data type: The amount of memory allocated for the data % * Initialization: A value, a pointer to memory, or NULL % % The combination of scope and duration is the _storage class_. If you do not % provide an initial value, most compilers assign a zero value or a null pointer. % % Supported data types include: % % * |double|: Double-precision floating point % * |single|: Single-precision floating point % * |int8|: Signed 8-bit integer % * |uint8|: Unsigned 8-bit integer % * |int16|: Signed 16-bit integer % * |uint16|: Unsigned 16-bit integer % * |int32|: Signed 32-bit integer % * |uint32|: Unsigned 32-bit integer % * Fixed Point: 8-, 16-, 32-bit word lengths % % With storage classes and custom storage classes, you can: % % * Generate exported files, with custom names, that contain global % variable declarations and definitions. % * Import custom header files that contain global variable declarations. % * Generate |const| or |volatile| type qualifiers in declarations. % * Represent a parameter as a macro (|#define| or compiler option). % * Package signals or parameters into flat structures or bit fields. %% Control Data in Simulink(R) and Stateflow(R) % This example uses data objects to specify code generation settings for % data. Alternatively, you can store the settings in the model by using dialog boxes. % Both methods allow full control over the data type and storage % class. You can use both methods in a single model. % % This example focuses on these types of data objects: % % * Signal % * Parameter % * Bus % % The code generator uses the objects from the MATLAB base workspace or a Simulink data dictionary. You % can create and inspect the objects with commands at the command % prompt % or in the Model Explorer. % % As an example, inspect the definition of the |Simulink.Signal| object % |pos_cmd_one|, which the model created in the base workspace: pos_cmd_one %% % You can open the Model Explorer and display details about a specific data % object in the example model. % % Open the Model Explorer. daexplr %% % In the *Model Hierarchy* pane, select *Base Workspace*. In the *Contents* pane, inspect the definitions of these objects: % % * |pos_cmd_one|: Top-level output, Double, Exported Global % * |pos_rqst|: Top-level input, Double, Imported Extern Pointer % * |P_InErrMap|: Calibration parameter, Auto, Constant % * |ThrotComm| (1): Top-level output structure, Auto, Exported Global % * |ThrottleCommands| (1): Bus definition, Struct, None % % (1) |ThrottleCommands| defines a |Simulink.Bus| object. % |ThrotComm| is a bus signal, which is an instantiation of |ThrottleCommands|. If a bus signal is nonvirtual, % the signal appears as a structure in the C code. % % As in C, you can use a bus definition (|ThrottleCommands|) to create % multiple instances of the structure. In a model diagram, a bus signal % appears as a wide line with central dashes. % % <<../BusObjectLine.png>> % % A data object has properties that you configure for simulation and for % code generation, including: % % * |DataType| (numeric data type for storage in the generated code) % * |StorageClass| (storage class for code generation) % * |Value| (parameter value) % * |InitialValue| (initial value for signal) % * |Alias| (alternative name for the data, which the code generator uses) % * |Dimensions| (size and number of dimensions of parameter or signal % value) % * |Complexity| (numeric complexity) % * |Unit| (physical units such as cm) % * |Min| (minimum value) % * |Max| (maximum value) % % Use the property |Description| to specify custom documentation for data objects. %% Add New Data Objects % You can create data objects for named signals, states, and parameters. % To associate a data object with a construct, the construct must have a % name. % % The Data Object Wizard tool finds constructs for which you % can create data objects, and then creates the objects for you. The example % model includes two signals that are not associated with data objects: % |fbk_1| and |pos_cmd_two|. % % To find the signals and create data objects for them: % % 1. Open the Data Object Wizard. dataobjectwizard('rtwdemo_PCG_Eval_P2') %% % 2. Click *Find* to find candidate constructs. % % <<../data_object_wiz.jpg>> % % 3. Click *Select All* to select all candidates. % % 4. Click *Create* to create the data objects. % % The Data Object Wizard performs the equivalent of the following commands: fbk_1 = Simulink.Signal; fbk_1.Dimensions = 1; fbk_1.DataType = 'double'; outport = get_param('rtwdemo_PCG_Eval_P2/fbk_1','PortHandles'); outport = outport.Outport; set_param(outport,'MustResolveToSignalObject','on') pos_cmd_two = Simulink.Signal; pos_cmd_two.Dimensions = 1; pos_cmd_two.DataType = 'double'; outport = get_param('rtwdemo_PCG_Eval_P2/PI_ctrl_2','PortHandles'); outport = outport.Outport; set_param(outport,'MustResolveToSignalObject','on') %% Configure Data Objects % Set the data type and storage class for each data object. % To configure data object properties, in the Model Explorer *Contents* % pane, click an object. You can edit the properties by using the corresponding columns % in the *Contents* pane, or edit the properties in the Dialog pane. % % Use the Model Explorer to configure these data object properties: % % * |fbk_1|: Data type |double|, storage class |ImportedExtern| % * |pos_cmd_two|: Data type |double|, storage class |ExportedGlobal| % % Alternatively, you can use these commands to configure the objects: fbk_1.DataType = 'double'; fbk_1.StorageClass = 'ImportedExtern'; pos_cmd_two.DataType = 'double'; pos_cmd_two.StorageClass = 'ExportedGlobal'; %% Control File Placement of Parameter Data % With Embedded Coder(R), you can control the file placement of % definitions for % parameters and constants. The example model writes all parameter definitions % to the file |eval_data.c|. % % To change the placement of parameter and constant definitions, set the % data placement options for the model configuration. In the % Configuration Parameters dialog box, configure the options on the % *Code Generation > Code Placement* pane. % % In the example model, inspect the *Code Placement* pane in the Configuration Parameters dialog % box. The model places data definitions in the file % |eval_data.c| and declarations in the file |eval_data.h|. %% Declare Block Parameters Tunable or Inlined % You can control the default tunability of block parameters in the generated % code. In the Configuration Parameters dialog box, on the *Optimization > % Signals and Parameters* pane, % adjust the setting for *Default % parameter behavior*. % % For the example model, the default parameter behavior is set to |Inlined|. By % default, block parameters appear in the code as numeric literal values, % not as variables stored in memory. You can use |Simulink.Parameter| objects to % override inlining and preserve tunability for individual % parameters. %% Enable Signal Data Objects in Generated Code % Make sure that the signal data objects (|Simulink.Signal|) appear % in the generated code. For individual signal lines in the model, set the option *Signal % name must resolve to Simulink signal object* to explicitly resolve the % signal name to a |Simulink.Signal| object in a workspace or data % dictionary. % % 1. Right-click the signal line. % % 2. Select *Properties*. % % 3. In the Signal Properties dialog box, make sure that the option *Signal name must resolve to Simulink signal % object* is selected. % % You can manually select this option for individual signal lines. Alternatively, you % can select the option for all such signals in a model. At the command prompt, use the % |disableimplicitsignalresolution| function. %% View Data Objects in Generated Code % <matlab:RTWDemos.pcgd_buildDemo(2,0); Generate code from the example model>. rtwbuild('rtwdemo_PCG_Eval_P2'); %% % Create a code generation report to more easily view the generated files. % In the Simulink Editor, select *Code > C/C++ Code > Code Generation % Report > Open Model Report*. % % You can access these generated files: % % * |rtwdemo_PCG_Eval_P2.c|: Defines the step and initialization functions. Uses the defined data objects. % * |eval_data.c|: Assigns initial values to the defined parameters. The model % configuration specifically sets the file name. % * |eval_data.h|: Provides |extern| declarations of parameter data. % The model configuration specifically sets the file name. % * |ert_main.c|: Defines scheduling functions. % * |rtwdemo_PCG_Eval_P2.h|: Contains the type definitions of the default % structures that store % signal, state, and parameter data. Due to the data object settings, some data appear in |eval_data.c| % instead. % * |PCG_Eval_p2_private.h|: Declares private (local) data for the generated functions. % * |rtwdemo_PCG_Eval_P2_types.h|: Declares the real-time model data structure. % * |rtwtypes.h|: Provides mapping to the data types that Simulink(R) Coder(TM) defines (|typedef|). Used for integration with external systems. % % For example, view the file |eval_data.c|, % which allocates |const| memory for global variables that correspond to % the |Simulink.Parameter| objects in the base workspace. cfile = fullfile('rtwdemo_PCG_Eval_P2_ert_rtw','eval_data.c'); rtwdemodbtype(cfile,'/* Exported data definition */','* [EOF]',1,1) %% % View the code algorithm in the model |step| function in the % file |rtwdemo_PCG_Eval_P2.c|. The algorithm uses the data object names % directly. % cfile = fullfile('rtwdemo_PCG_Eval_P2_ert_rtw','rtwdemo_PCG_Eval_P2.c'); rtwdemodbtype(cfile,'/* Model step function */',... '/* Sum: ''<S2>/Sum3'' incorporates:',1,0); %% % Without storage classes and other code generation settings that the data objects specify, the generated code: % % * Inlines invariant signals and block parameters when you select these % optimizations in the model configuration parameters % * Places model input and output signals, block states, and tunable parameters in global % data structures % * Does not create global variables that correspond to MATLAB(R) variables % % In contrast, the example code shows that most of the default data structures have been % replaced with user-defined data objects. For example, these signals % and parameters appear as global variables in the code: % % * |pos_rqst| % * |fbk_1| % * |I_Gain| % * |I_OutMap| % * |I_InErrMap| % % However, the local variable |rtb_IntegralGainShape| and the % state variable |rtwdemo_PCG_Eval_P2_DWork.Discrete_Time_Integrator1_DSTAT| % still use the Simulink(R) Coder(TM) data structures. Data objects do not % exist for these entities. %% Store Model Data in Data Dictionary % When you end your MATLAB session, variables that you create in the base % workspace do not persist. To permanently store data objects and bus % objects, consider linking the model to a data dictionary. % % # In the example model, select *File > Model Properties % > Link to Data Dictionary*. % # In the Model Properties dialog box, select *Data Dictionary*. Click % *New*. % # In the Create a new Data Dictionary dialog box, set *File name* to % |rtwdemo_PCG_Eval_dict| and click *Save*. In the Model Properties dialog box, click *OK*. % # Click *Yes* in response to the message about migrating base workspace data. Click *Yes* in % response to the message about removing the imported items from the base % workspace. % % Alternatively, to manually migrate the objects into a data dictionary, you % can use programmatic commands: % Create a list of the variables and objects that the target % model uses. usedVars = {Simulink.findVars('rtwdemo_PCG_Eval_P2').Name}; % Create a new data dictionary in your current folder. Link the model to % this new dictionary. dictObj = Simulink.data.dictionary.create('rtwdemo_PCG_Eval_dict.sldd'); set_param('rtwdemo_PCG_Eval_P2','DataDictionary','rtwdemo_PCG_Eval_dict.sldd') % Import only the target variables from the base workspace to the data % dictionary. importFromBaseWorkspace(dictObj,'clearWorkspaceVars',true,'varList',usedVars); %% % The data dictionary now permanently stores the objects that the model % uses. To view the contents of the dictionary, click the data dictionary % badge in the lower-left corner of the model. % % The separation of data from the model provides these benefits: % % *One model, multiple data sets* % % * Use of different data types to change the targeted hardware (for example, for floating-point and fixed-point targets) % * Use of different parameter values to change the behavior of the control algorithm (for example, for reusable components with different calibration values) % % *Multiple models, one data set* % % * Sharing of data between Simulink(R) models in a system % * Sharing of data between projects (for example, transmission, engine, and wheel controllers might all use the same CAN message data set) % % For the next example in this series, see <docid:ecoder_examples.example-rtwdemo_pcgd_stage_3_p1_script>. % % Copyright 2007-2015 The MathWorks, Inc.