Learn how characteristics of generated code and RAM/ROM data affect the RAM/ROM metric.
For information about the example model and other examples in this series, see Prepare a Control Algorithm Model for C Code Generation.
You can evaluate the generated code based on two primary metrics: execution speed and memory usage. In some cases, improvement in one metric implies a sacrifice in the other metric. For example, you can often gain faster execution by consuming more memory.
You can further classify memory usage as ROM (read-only memory) and RAM (random access memory).
Accessing data from RAM is faster than accessing data from ROM.
Executables and data must be stored on ROM because RAM does not maintain data between power cycles.
This example evaluates memory requirements and divides the memory usage into function and data components. The example does not evaluate execution speed.
This evaluation uses the Freescale™ CodeWarrior® compiler.
Compiler: Freescale™ CodeWarrior®
Version: 5.5.1.1430
Target Processor: Power PC 565
As described in Build Integrated Code Outside the Simulink Environment and Test Generated Code, the generated code can require the use of utility functions. The utility functions incur a one-time, fixed cost of memory. Due to this fixed overhead, the data in this example show memory usage for:
Algorithms: The C code generated from the Simulink® block diagrams plus the data definition functions
Utilities: Functions that are part of the Simulink® Coder™ library source
Full: The sum of both the algorithm and utilities
The three evaluations in this example use the same build configuration. Freescale™ CodeWarrior® was configured to minimize memory usage and apply all applicable optimizations.
Source files: PCG_Eval_File_1.zip
Data Type: All doubles
Included Data: The project includes all data that the build requires (including data declared as extern
: pos_rqst
, fbk_1
, and fbk_2
)
Main Function: A modified version of example_main
from Build Integrated Code Outside the Simulink Environment
Function Call Method: Reusable functions for the PI controllers
Memory Usage
Function Data Algorithms 1172 bytes 549 bytes Utilities 592 bytes 40 bytes Full 1764 bytes 589 bytes
In this configuration, the model data use a single-precision floating-point data type instead of double precision.
Model Configuration
Source files: PCG_Eval_File_2.zip
Data Type: All singles
Included Data: The project includes all data that the build requires (including data declared as extern
: pos_rqst
, fbk_1
, and fbk_2
)
Main Function: A modified version of example_main
from Build Integrated Code Outside the Simulink 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
This configuration uses only 56% of the data memory from the first configuration: 308 bytes instead of 549 bytes. This configuration also uses 68% of the function memory: 800 bytes instead of 1172 bytes. For this system, using single precision instead of double precision does not affect the accuracy of the control algorithm, so you can use this configuration to achieve more efficient code.
Source files: PCG_Eval_File_3.zip
Data Type: All singles
Included Data: The project includes all data that the build requires (including data declared as extern
: pos_rqst
, fbk_1
, and fbk_2
)
Main Function: A modified version of example_main
from Build Integrated Code Outside the Simulink Environment
Function Call Method: The function interface is void void
so data exchange occurs through global variables
Memory Usage
Function Data Algorithms 948 bytes 348 bytes Utilities 592 bytes 40 bytes Full 1540 bytes 388 bytes
This configuration consumes more data and function memory than the previous configuration.