Interrupt services routines (ISR) are realized by connecting the outputs of the VxWorks Interrupt Block to the control input of a function-call subsystem, the input of a VxWorks Task Block(a function-call subsystem) or the input to a StateFlow Chart which is configured for a function-call input event.
This block installs the connected output as an ISR in VxWorks and enables the specified interrupt level. The current implementation of the VxWorks interrupt block supports VME interrupts 1-7 and uses the VxWorks system calls sysIntEnable(), sysIntDisable(), intConnect(), intLock() and intUnlock(). Ensure that your target architecture(BSP) supports these functions. There can only be 1 VxWorks Interrupt Block in a model and all desired interrupts should configured by it.
It is important to realize that when a function-call subsystem is connected to an Interrupt Block output, the generated code for that subsystem becomes the ISR. For large subsystems, this can have a large impact on interrupt response time for interrupts of equal and lower priority in the system. As a general rule, it is best to keep ISRs as short as possible, and thus you should only connect function-call subsystems that are small. A better solution is to use the Task Block to run a function-call subsystem. The Task Block is placed between the Interrupt Block and the function-call subsystem(or Stateflow Chart). The Interrupt Block then installs the Task Block as the ISR which simply performs a semGive() to the function-call subsystem and returns. See the VxWorks Task Block for more information.
NOTE: The hardware that will be generating the interrupt is not configured by this block. Typically, the interrupt source is a VME I/O board which will generate interrupts for specific events (ex: end of A/D conversion). The VME interrupt level and vector are setup in registers or using jumpers on the board. The mdlInitialConditions function of a user written device driver(s-function) can be used to setup the registers and enable interrupt generation on the board. It is required that the user matches the interrupt level and vector specified in the Interrupt block dialog to the level and vector setup on the I/O board.
For more information, see the Tornado and Asynchronous Support chapters in the Real-Time Workshop user guide.
In Simulation mode, the ISRs are executed non-preemptively and, if called simultaneously, are executed in the order specified by their number (1 being the highest priority). Interrupt mapping during simulation is left to right, top to bottom. For example, the first control input signal maps to the topmost ISR. The last control input signal maps to bottom most ISR.
RTW uses vxinterrupt.tlc to realize asynchronous interrupts in the generated code.
It is assumed the ISR has no arguments, and the Simulink definition of the function-call subsystem is remapped in accordance to this assumption. For example, vxinterrupt.tlc creates a function #define in the model's header file for a function-call subsystem block in the root model.
#define Sys_s5_Subtask_F_OutputUpdate(a,b) (Sys_s5_Subtask_F_OutputUpdate())
Specify the VME interrupt numbers for the interrupts to be installed. The valid range is 1-7 (Example: [4 2 5] ).
This number(#) will be used in the call intConnect(INUM_TO_IVEC(#),...). There should be a unique vector offset number specified for each interrupt number.
By default, higher priority interrupts can preempt lower priority interrupts in VxWorks. If desired, interrupts can be locked out during the execution of a ISR by setting the preemption flag to 0. This causes intLock() and intUnlock() calls to be inserted at the beginning and end of the ISR respectively. This should be used carefully as it increases the systems interrupt response time for all interrupts at the intLockLevelSet() and below.
In simulation mode a scalar IRQ direction is applied to all control inputs, and is specified as 1 (rising), -1 (falling), or 0 (either). Configuring inputs separately in simulation is done prior to the control input. For example, a gain block set to -1 prior to a specific IRQ input will change the behavior of one control input relative to another.
During RTW mode the IRQ Direction parameter is ignored.