www.gusucode.com > rtwdemos 工具箱matlab源码程序 > rtwdemos/rtwdemo_pcgd_stage_7_p1_script.m

    %% Evaluating the Generated Code
% This example shows the build characteristics of the generated code and
% RAM/ROM data for several model configurations.
%
% *Time*: 15 minutes
%
% *Goals*
% 
% Understand...
%
% * How different configurations affect the RAM/ROM metric
%
%% Background on Code Evaluation
% Generated code is evaluated based on two primary metrics: _execution
% speed_ and _memory usage_.  There is often, though not always, a tradeoff 
% between execution speed and memory where faster execution requires more memory.
% Memory usage can be further classified into ROM (Read-only memory) and 
% RAM (Random access memory).  
%
% There are tradeoffs between using RAM and ROM. 
%
% * Accessing data from RAM is faster than accessing ROM.
% * Executables and data must be stored on ROM, because RAM does not maintain data
% between power cycles.
%
% This module shows memory requirements divided into
% function and data components. Execution speed was not evaluated.
%
%% Compiler Information
% The Freescale(TM) CodeWarrior(R) was used in this evaluation. Details on
% the compiler appear below.
% 
% * *Compiler:* Freescale(TM) CodeWarrior(R) 
% * *Version:* v5.5.1.1430
% * *Target Processor:* Power PC 565
% 
%% Viewing the Code Metrics
% As described in *Integrating the Generated Code into the External Environment* and
% *Testing the Generated Code*, the generated code may require the use of
% utility functions.  The utility functions have a fixed overhead;
% their memory requirements is a one-time cost.  Because of this, the data in this module shows memory usage for:
% 
% * Algorithms: The C code generated from the Simulink(R) diagrams and the data
% definition functions
% * Utilities: Functions that are part of the Simulink(R) Coder(TM) library
% source
% * Full: The sum of both the Algorithm and Utilities
%
%% Build Options Configuration
% The same configuration options are used in all three evaluations.  
% Freescale(TM) CodeWarrior(R) was configured to minimize memory usage and apply all allowed
% optimizations.
%
% <<CodeWarrior_Small_Full_Opt.jpg>>
%
%% Configuration 1: Reusable Functions Data Type Double
% * *Source files:* |PCG_Eval_File_1.zip|
% * *Data Type:* All doubles
% * *Included Data:* All data required for the build is included in the
% project (including data defined as |extern|: |pos_rqst|, |fbk_1|, and |fbk_2|)
% * *Main Function:* A modified version of |example_main| from *Integrating
% the Generated Code into the External Environment*
% * *Function Call Method:* Reusable functions for the PI controllers
% 
% <<CodeWarrior_P4_Data_Details.jpg>>
%
% *Memory Usage*
%
%              Function    Data
%  Algorithms  1172 bytes  549 bytes
%  Utilities   592 bytes   40 bytes
%  Full        1764 bytes  589 bytes
%
%% Configuration 2: Reusable Functions Data Type Single
% In this configuration, the data types for the model where changed from the
% default of double to single.  
%
% *Model Configuration*
%
% * *Source files:* |PCG_Eval_File_2.zip|
% * *Data Type:* All singles
% * *Included Data:* All data required for the build is included in the
% project (including data defined as |extern|: |pos_rqst|, |fbk_1|, and |fbk_2|)
% * *Main Function:* A modified version of example_main from *Integrating
% the Generated Code into the External Environment*
% * *Function Call Method:* Reusable functions for the PI controllers
%
% *Memory Usage*
%
%              Function    Data
%  Algorithms  800 bytes   308 bytes
%  Utilities   592 bytes   40 bytes
%  Full        1392 bytes  348 bytes
%
% Comparing the memory used by the algorithms in the first configuration to
% the current configuration we see a large drop in the data memory,
% from 549 bytes to 308 bytes or 56 percent.  The function size also 
% decreased from 1172 to 800 bytes, or 68 percent.  Running the simulation
% with data type set to single does not reduce the accuracy of the control
% algorithm, therefore this would be an acceptable design decision.
%
%% Configuration 3: Nonreusable Functions Data Type Single
% * *Source files:* PCG_Eval_File_3.zip
% * *Data Type:* All singles
% * *Included Data:* All data required for the build is included in the
% project (including data defined as |extern|: |pos_rqst|, |fbk_1|, and |fbk_2|)
% * *Main Function:* A modified version of |example_main| from *Integrating
% the Generated Code into the External Environment*
% * *Function Call Method:* The function interface is |void void|.  Data
% is passed by global parameters
%
% *Memory Usage*
%
%              Function    Data
%  Algorithms  948 bytes   348 bytes
%  Utilities   592 bytes   40 bytes
%  Full        1540 bytes  388 bytes
%
% The memory requirements for the third configuration are higher than the
% second configuration.  Had the data type been double they would have been
% higher than the first configuration as well.   

%   Copyright 2007-2012 The MathWorks, Inc.