Real-Time Workshop

Signal Storage Concepts

This section discusses structures and concepts you must understand in order to choose the best signal storage options for your application:

• The global block I/O data structure rtB
• The concept of signal storage classes as used in Real-Time Workshop

rtB: the Global Block I/O Structure

By default, Real-Time Workshop attempts to optimize memory usage by sharing signal memory and using local variables.

However, there are a number of circumstances in which it is desirable or necessary to place signals in global memory. For example:

• You may want a signal to be stored in a structure that is visible to externally written code.
• The number and/or size of signals in your model may exceed the stack space available for local variables.

In such cases, it is possible to override the default behavior and store selected (or all) signals in a model-specific global block I/O data structure. The global block I/O structure is called rtB.

The following code fragment illustrates how rtB is defined and declared in code generated (with signal storage optimizations off) from the Signals_examp model shown in Figure 5-4.

• typedef struct BlockIO_tag {
    real_T SinSig;                        /* <Root>/Sine Wave */
    real_T Gain1Sig;                      /* <Root>/Gain1 */
  } BlockIO;
  .
  .
  .
  /* Block I/O Structure */
  BlockIO rtB;
  

Field names for signals stored in rtB are generated according to the rules described in Symbolic Naming Conventions for Signals in Generated Code.

Storage Classes for Signals

In Real-Time Workshop, the storage class property of a signal specifies how Real-Time Workshop declares and stores the signal. In some cases this specification is qualified by further options.

Note that in the context of Real-Time Workshop, the term "storage class" is not synonymous with the term storage class specifier, as used in the C language.

Default Storage Class.   Auto is the default storage class. Auto is the appropriate storage class for signals that you do not need to interface to external code. Signals with Auto storage class may be stored in local and/or shared variables, or in a global data structure. The form of storage depends on the Signal storage reuse, Buffer reuse, and Local block outputs options, and on available stack space. See Signals with Auto Storage Class for a full description of code generation options for signals with Auto storage class.

Explicitly Assigned Storage Classes.   Signals with storage classes other than Auto are stored either as members of rtB, or in unstructured global variables, independent of rtB. These storage classes are appropriate for signals that you want to monitor and/or interface to external code.

The Signal storage reuse and Local block outputs optimizations do not apply to signals with storage classes other than Auto.

Use the Signal Properties dialog to assign these storage classes to signals:

• SimulinkGlobal(Test Point): Test points are stored as fields of the rtB structure that are not shared or reused by any other signal. See Declaring Test Points for further information.
• ExportedGlobal: The signal is stored in a global variable, independent of the rtB data structure. model_private.h exports the variable. Signals with ExportedGlobal storage class must have unique signal names. See Interfacing Signals to External Code for further information.
• ImportedExtern: model_private.h declares the signal as an extern variable. Your code must supply the proper variable definition. Signals with ImportedExtern storage class must have unique signal names. See Interfacing Signals to External Code for further information.
• ImportedExternPointer: model_private.h declares the signal as an extern pointer. Your code must supply a proper pointer variable definition. Signals with ImportedExtern storage class must have unique signal names. See Interfacing Signals to External Code for further information.

Signals: Storage, Optimization, and Interfacing

Signals with Auto Storage Class