Priority and Usage

Overview

There is a priority order among interdependent MPF settings. From highest to lowest, the priorities are

Priority order varies inversely with frequency of use, as illustrated below. For example, Definition File is highest priority but least used.

MPF Settings Priority and Usage

Unless they are overridden, the Read-Write and Global priorities place in the generated files all of the model's MPF-derived data objects that you selected using Data Object Wizard. (See Creating Simulink Data Objects with Data Object Wizard for details.) Before generating the files, you can use the higher priority Definition file, Header file, and Ownership, as desired, to override Read-Write or Global priorities for single data objects. Most users will employ Read-Write or Global, without an override. A few users, however, will want to do an override for certain data objects. We expect that those users whose applications include multiple modules will want to use the Ownership priority.

The priorities are in effect only for those data objects that are derived from Simulink.Signal and Simulink.Parameter, and whose custom storage classes are specified using the Custom Storage Class Designer. (For details, see Designing Custom Storage Classes and Memory Sections in the Real-Time Workshop Embedded Coder documentation.) Otherwise, the Real-Time Workshop build process determines the data placement.

Read-Write Priority

This is the lowest priority. Consider that a model consists of one or more Simulink blocks or Stateflow diagrams. There can be subsystems within these. For the purpose of illustration, think of a model with one top-level block called fuelsys. You double-clicked the block and now see three subsystems labeled subsys1, subsys2 and subsys3, as shown in the next figure. Signals a and b are outputs from the top-level block (fuelsys). Signal a is an input to subsys1 and b is input to subsys2. Signal c is an output from subsys1. Notice the other inputs and outputs (d and e). Signals a through e have corresponding data objects and are part of the code generation data dictionary.

As explained in Managing the Data Dictionary MPF provides you with the means of selecting a data object that you want defined as an identifier in the generated code. MPF also allows you to specify property values for each data object. For this illustration, we choose to include all of the data objects to be in the dictionary.

The Generated Files

We generate code for this model. As shown in the figure below, this results in a .c source file corresponding to each of the subsystems. (In actual applications, there could be more than one .c source file for a subsystem. This is based on the file partitioning previously selected for the model. But for our illustration, we only need to show one for each subsystem.) Data objects a through e have corresponding identifiers in the generated files.

A .c source file has one or more functions in it, depending on the internal operations (functions) of its corresponding subsystem. An identifier in a generated .c file has local scope when it is used only in one function of that .c file. An identifier has file scope when more than one function in the same .c file uses it. An identifier has global scope when more than one of the generated files uses it.

A subsystem's source file always contains the definitions for all of that subsystem's data objects that have local scope or file scope. (These definitions are not shown in the figure.) But where are the definitions and declarations for data objects of global scope? These are shown in the next figure.

When the Read-Write priority is in effect, this source file contains the definitions for the subsystem's global data objects, if this is the file that first writes to the data object's address. Other files that read (use) that data object only include a reference to it. This is why this priority is called Read-Write. Since a read and a write of a file are analogous to input and output of a model's block, respectively, there is another way of saying this. The definitions of a block's global data objects are located in the corresponding generated file, if that data object is an output from that block. The declarations (extern) of a block's global data objects are located in the corresponding generated file, if that data object is an input to that block.

Settings for Read-Write Priority

The generated files and what they include, as just described, occur when the Read-Write priority is in effect. For this to be the case, the other priorities are turned off. That is,

Global Priority

This has the same priority as Read-Write (the lowest) priority. The settings for this are the same as for Read-Write Priority, except

The generated files that result are shown in the next figure. A subsystem's data objects of local or file scope are defined in the .c source file where the subsystem's functions are located (not shown). The data objects of global scope are defined in another .c file (called global.c in the figure). The declarations for the subsystem's data objects of global scope are placed in a .h file (called global.h).

For example, all data objects of local and file scope for subsys1 are defined in subsys1.c. Signal c in the model is an output of subsys1 and an input to subsys2. So c is used by more than one subsystem and thus is a global data object. Since global priority is in effect, the definition for c (int c;) is in global.c. The declaration for c (extern int c;) is in global.h. Since subsys2 uses (reads) c, #include "global.h" is in subsys2.c.

Definition File, Header File, and Ownership Priorities

While the Read-Write and Global priorities operate on all MPF-derived data objects that you want defined in the generated code, the remaining priorities allow you to override the Read-Write or Global priorities for one or more particular data objects. There is a high-to-low priority among these remaining priorities — Definition File, Header File, and Ownership — for a particular data object, as shown in MPF Settings Priority and Usage

  


 © 1984-2008- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS