Learn more about xPC Target

xPC Target Interrupts

On this page…
Introduction Interrupt Processing in the xPC Target Environment

Introduction

If your device supports interrupts, you can use the procedures in this chapter to add your custom interrupt functions to the xPC Target framework.

Your users can use interrupts in xPC Target applications in one of the following ways:

• Use the interrupt with the xPC Target Async IRQ Source block to execute a function-call subsystem when an interrupt occurs.

• Use the interrupt to run the model in place of the timer interrupt, available through the model Configuration Parameters dialog box in the Real-Time Workshop > xPC Target options pane.

Note   Although users can use interrupts in one of two ways, you program for these interrupts using the same procedure, as described in Adding Interrupt Support. However, before you start programming the interrupts, see Interrupt Processing in the xPC Target Environment for a description of the flow of xPC Target interrupt processing.

Back to Top

Interrupt Processing in the xPC Target Environment

When a model executes, it executes in the following order:

1. Call all mdlStart routines in block execution order.

2. Call the Start function, if one exists.

3. Allow background graphics and network tasks to run until an interrupt occurs.

The following illustrates the flow of processing once a hardware interrupt occurs. This is background information to help you understand the context in which the interrupt functions run.

When a hardware interrupt occurs, the generated code uses the following steps for each device on this IRQ to determine which device generated the interrupt:

1. Call the PreHook function, if one exists. The return value determines the action.

2. The generated code determines whether this device generated the interrupt.

   • If the PreHook function returns XPC_RUN_ISR, execution continues to step 3.

   • If the PreHook function returns XPC_DROP_ISR, the generated code goes to step 5.

3. The generated code determines whether the Async IRQ Source block has a function-call subsystem connected.

   • If so, the generated code calls the interrupt service function-call subsystem. When the interrupt service function subsystem returns, the generated code goes to step 4.

   • If this board is configured to run the model, and this board did interrupt, send a wakeup call to the model thread. The model thread does not immediately execute. It waits until after all the boards that use this IRQ have been checked and the return from the interrupt has been executed.

4. Call the PostHook function, if one exists. If one does not exist, the generated code goes to step 5.

5. The generated code checks whether another device using the same IRQ exists in the system.

   If so, execution returns to the beginning of step 1.

   If no other device exists, generated code goes to step 6.

6. Returns from the interrupt.

The xPC Target kernel now runs the highest priority thread. The highest priority ready thread is the model if a wakeup call was sent to it.

Note   The Allow preemption of function call subsystem check box has no effect. Interrupts are never enabled when the function-call subsystem is executed.

Back to Top

Interrupt Support

Adding Interrupt Support

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