Bridge Marking

The bridge.mark is used to mark interrupt functions.

Marking a Bridge Safe for Interrupt Invocation

MC-3020 allows functions and messages to be marked as callable from interrupt handlers or other asynchronous sources (such as other tasks, signal handlers, etc). Functions and messages marked here will generate a short stub routine that will defer execution of the function or message to be between dispatched state actions. When a function or message marked as safe for interrupts is invoked, its action body is posted to a queue for dispatch after any currently running state action completes. This provides architecture data mechanism integrity while maintaining application data access set consistency.

Functions and messages marked safe for interrupts cannot return data. They must be of return type void. However, core data type data can be passed into these functions. Such data is packaged safely at interrupt level and then unpacked during function execution.

To indicate to the model compiler that a function may be invoked in a manner safe for invocation from an interrupt handler or other asynchronous activation (one for each function):

TagSyncServiceSafeForInterrupts(string "component",
 string "function");
 

Where the input parameters are:

component

xtUML component name

function

is name of the function being tagged as safe for calling.

Example 4.1. Tagging Interrupt Bridges

.invoke TagSyncServiceSafeForInterrupts( "ILB", "kick_start" )
        


To indicate to the model compiler that a message may be invoked in a manner safe for invocation from an interrupt handler or other asynchronous activation (one for each message):

MarkMessageSafeForInterrupts(string "component_name",
 string "port_name",
 string "message_name");
 

Where the input parameters are:

component_name

xtUML component name

port_name

name of port on the component labeled in the first parameter

message_name

is the name of the message within the port being tagged as safe for calling.

Example 4.2. Tagging Interrupt Bridges

.invoke MarkMessageSafeForInterrupts( "Tracking", "UI", "startStopButtonPressed" )
        


Enabling/Disabling Interrupts

To protect data structures for Interrupt Safe Bridges, interrupts are disabled for a very few instructions. The method of disabling interrupts varies from target to target and from compiler to compiler. Therefore, the responsibility of defining the specific flavor of EI/DI instruction is left to the user. The marking functions UserEnableInterrupts and UserDisableInterrupts are are provided for specifying the specific way interrupts are enabled and disabled with your specific target.

To define the instruction sequence for enabling and disabling interrupts, edit the system-level user defined rule file sys_functions.arc.

Bit Fields

Bit fields provide a means of packing many small value attributes into single words of computer storage. MC-3020 allows attributes to be stored as bit fields in ANSI C structs.

Attributes are marked with BridgePoint Builder. The string BIT_WIDTH: n is placed within a comment as the first line of the attribute description. ``n'' is the width in bits required to store the attribute.

It should be understood that bit fields are inherently somewhat less portable than most other ANSI C constructs. Dependence upon ``Endian-ness'', memory models and other compiler/target implementation specifics is not uncommon. Use bit fields with care.

The maximum width for a bit field member attribute is 16 bits. Bit field members are of type unsigned int.

Fixing Class Extents

MC-3020 provides a means of establishing the base memory address of class instance collections (extents). Within BridgePoint Builder the string BASE_ADDRESS: n is placed within a comment as the first line of the class description. ``n'' is the memory address anchoring the start of the collection of class instances.

Two user defined rule file functions at the system-level define how this number (``n'') will appear in the generated code. One function (UserFixExtentBaseBegin) is used to insert code before the definition of the class instance collection memory. Another function (UserFixExtentBaseEnd) is used to insert code directly after the data definition. This combination of functions will allow a pragma around the data definition.

To define the instruction sequence for fixing the class extent, edit the system-level user defined rule file sys_functions.arc.