TC1796
System Units (Vol. 1 of 2)
Interrupt System
User’s Manual
14-18
V2.0, 2007-07
Interrupt, V2.0
14.8
Usage of the TC1796 Interrupt System
The following sections provide some examples of using the TC1796 interrupt system to
solve both typical and special application requirements.
14.8.1
Spanning Interrupt Service Routines Across Vector Entries
Each Interrupt Vector Table entry consists of eight words of memory. If an ISR can be
made to fit directly in the Interrupt Vector Table there is no need for a jump instruction to
vector to the rest of the interrupt handler elsewhere in memory. However, only the
simplest ISRs can fit in the eight words available to a single entry in the table. But it is
easy to arrange for ISRs to span across multiple entries, since the Interrupt Vector Table
is ordered not by the interrupt source but by interrupt priority. This technique is explained
in this section.
In the example of
, entry locations 3 and 4 are occupied by the ISR for
entry 2. In
, the next available entry after entry 2 is entry 5. Of course, if this
technique is used, it would be improper to allow any SRN to request service at any of the
spanned vector priorities. Thus, priority levels 3 and 4 must not be assigned to SRNs
requesting CPU service. They can, however, be used to request PCP service.
There is a performance trade-off that may arise when using this technique because the
range of priority numbers used increases. This may have an impact on the number of
arbitration cycles required to perform arbitration. Consider the case in which a system
uses only three active interrupt sources, that is, where there are only three SRNs
enabled to request service. If these three active sources are assigned to priority numbers
1, 2, and 3, it would be sufficient to perform the arbitration in just one cycle. However, if
the ISR for interrupt priority 2 is spanned across three Interrupt Vector Table entries as
shown in
, the priority numbers 1, 2 and 5 would have to be assigned. Thus,
two arbitration cycles would have to be used to perform the full arbitration process.
The trade-off between the performance impact of the number of arbitration cycles and
the performance gain through spanning service routines can be made by the system
designer depending on system needs. Reducing the number of arbitration cycles
reduces the service request arbitration latency - spanning service routines reduces the
run time of service routines (and therefore also the latency for further interrupts at that
priority level or below). For example, if there are multiple fleeting measurements to be
made by a system, reducing arbitration latency may be most important. But if keeping
total interrupt response time to a minimum is most urgent, spanning Interrupt Vector
Table entries may be a solution.
