This section discusses the crucial topics of interrupt latency and determinism. For the purposes of this discussion, you need to be familiar with the following concepts:

• Interrupt latency—The difference between the time that a component instance asserts an interrupt and the execution of the first instruction at the interrupt vector address. This instruction is typically part of the interrupt funnel, rather than the interrupt handler itself.
• Interrupt response time—The time elapsed between the event that causes the interrupt and the execution of the handler.
• Determinism—An attribute of a piece of source code that is guaranteed to execute within a fixed amount of time. Overall interrupt latency impacts the deterministic behavior for all source code in the system for which interrupts are not disabled.

For more information, refer to "Nios II Exception Handling Overview" section in the "Exception Handling" chapter of the Nios II Software Developer's Handbook.

To minimize interrupt latency, thus directly improving system determinism, follow these guidelines:

• In the software ISR, perform the minimum processing necessary to clear the interrupt.
• Complete noncritical-section interrupt processing outside of the interrupt context. If your software is based on an operating system, a high priority task can be pending on an event flag. The ISR posts to the event flag, notifying the task to complete interrupt processing.
• Use an External Interrupt Controller (EIC), such as the VIC used in the hardware design for this application note.

If it is not possible to use an EIC, you can improve the performance of the internal interrupt controller (IIC) by using the interrupt vector custom instruction.

The interrupt vector custom instruction is not compatible with the EIC interface. The performance of the IIC with the interrupt vector custom instruction is generally inferior to the performance of the VIC.

For information about using the EIC and shadow register sets, or the interrupt vector custom instruction, refer to "Improving ISR Performance" in the "Exception Handling" chapter in the Nios II Software Developer's Handbook and "Exception and Interrupt Controllers" section in the "Processor Architecture" chapter in the Nios II Processor Reference Handbook. For information about tightly coupled memory, refer to the Using Tightly Coupled Memory with the Nios II Processor Tutorial.

For details of the interrupt vector custom instruction implementation, refer to the Exception and Interrupt Controllers section in the Processor Architecture chapter of the Nios II Processor Reference Handbook.

For more information about tightly-coupled memories, refer to the Tightly-Coupled Memory section in the Processor Architecture chapter of the Nios II Processor Reference Handbook.

Restrict the use of synchronization resources to post-function calls. Do not call the following types of functions from within an ISR:

• Functions and macros, such as ALT_SEM_PEND(), that explicitly wait for a resource
• Library functions, such as printf(), that might wait for a resource
• Other functions that wait for resources

Calling these types of functions from an ISR can have serious consequences, from the destruction of overall system latency to complete system deadlock.

Avoid using alt_irq_interruptible(), which can enable ISR nesting, but is likely to worsen interrupt latency (unless the ISR is abnormally long) because of the interrupt context switch overhead. If the ISR is lengthy, instead of making it interruptible, consider moving much of the less time-critical processing of the interrupt outside of the ISR to a task. Write the ISR to do only as much as is required to clear the interrupt and capture state so that the hardware can proceed, and then signal a task to complete processing of the interrupt request.