CHAPTER 10 INTERRUPT MANAGEMENT FUNCTIONS
This chapter describes the interrupt management functions performed by the RI850V4.
The RI850V4 provides as interrupt management functions related to the interrupt handlers activated when an EI level maskable interrupt is occurred.
10.2 User-Own Coding Module
To support various execution environments, the RI850V4 extracts from the interrupt management functions the hardware-dependent processing (
Interrupt entry processing) that is required to execute processing, as a user-own coding module. This enhances portability for various execution environments and facilitates customization as well.
10.2.1 Interrupt entry processing
Interrupt entry processing is a routine dedicated to entry processing that is extracted as a user-own coding module to assign processing for branching to the relevant processing (such as interrupt preprocessing), to the handler address to which the CPU forcibly passes control when an interrupt occurs.
The interrupt entry processing for the EI level maskable interrupts defined in the
Interrupt handler information in the system configuration file is included in the entry file created by executing the configurator for the system configuration file. Therefore, coding of interrupt entry processing is necessary for other interrupts (such as a reset) that are not EI level maskable interrupts.
- Basic form of interrupt entry processing
When coding an interrupt entry processing, the code should match the branch method selected in the
Property panel ->
[System Configuration File Related Information] tabbed page -> [Entry File] category -> [Generate method].
The following shows the basic form of interrupt entry processing in assembly language, related to other interrupts (such as EI level maskable interrupts not defined in the
Interrupt handler information, reset, or FE level maskable interrupts) that are not EI level maskable interrupts defined in the
Interrupt handler information in the system configuration file.
For interrupt types other than the EI level maskable interrupt, interrupt entry processing should always be coded in the direct vector method.
.extern _inthdr -- External label declaration .org base_adress + offset -- Setting of branch destination address jr32 _inthdr -- Branch to interrupt processing
|
[
Table reference method ]
.extern _inthdr -- External label declaration .org base_adress + offset -- Setting of branch destination address dw !_inthdr -- Branch to interrupt processing
|
- Internal processing of interrupt entry processing
Interrupt entry processing is a routine dedicated to entry processing that is called without RI850V4 intervention when an interrupt occurs. Therefore, note the following points when coding interrupt
- Coding method
Code it in assembly language according to the calling convention in the compiler used.
- Stack switching
There is no stack that requires switching before executing interrupt entry processing.
Therefore, coding regarding stack switching is not required in interrupt entry processing.
- Service call issue
To achieve faster response for processing (such as an
Interrupt Handlers) corresponding to an interrupt that has occurred, the issue of service calls is prohibited during interrupt entry processing.
The following is a list of processes that should be executed in interrupt entry processing.
- External label declaration
- Setting of branch destination address
- Branch to interrupt processing
The interrupt handler is a routine dedicated to interrupt servicing that is activated when an EI level maskable interrupt occurs.
The RI850V4 handles the interrupt handler as a non-task (module independent from tasks). Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when an interrupt occurs, and the control is passed to the interrupt handler.
The RI850V4 manages the states in which each interrupt handler may enter and interrupt handlers themselves, by using management objects (interrupt handler control blocks) corresponding to interrupt handlers one-to-one.
The following shows a processing flow from when an interrupt occurs until the control is passed to the interrupt handler.
Figure 10-1 Processing Flow (Interrupt Handler)
10.3.1 Basic form of interrupt handlers
Code interrupt handlers by using the void type function that has no arguments.
The following shows the basic form of interrupt handlers in C.
#include <kernel.h> /*Standard header file definition*/
#include <kernel_id.h> /*System information header file definition*/
void inthdr (void)
{
.........
return; /*Terminate interrupt handler*/
}
|
10.3.2 Internal processing of interrupt handler
The RI850V4 executes "original pre-interrupt processing" when passing control from the processing program where an EI level maskable interrupt occurred to the interrupt handler, as well as "original post-interrupt processing" when restoring control from the interrupt handler to the processing program where the EI level maskable interrupt occurred. Therefore, note the following points when coding interrupt handlers.
- Coding method
Code interrupt handlers using C or assembly language.
When coding in C, they can be coded in the same manner as ordinary functions coded.
When coding in assembly language, code them according to the calling rules prescribed in the compiler used.
- Stack switching
The RI850V4 switches to the system stack specified in
Basic information when passing control to an interrupt handler, and switches to the relevant stack when returning control to the processing program for which a base clock timer interrupt occurred. Coding regarding stack switching is therefore not required in interrupt handler processing.
- Service call issue
The RI850V4 handles the interrupt handler as a "non-task".
Service calls that can be issued in interrupt handlers are limited to the service calls that can be issued from non-tasks.
Note 1 If a service call (
isig_sem,
iset_flg, etc.) accompanying dispatch processing (task scheduling processing) is issued in order to quickly complete the processing in the interrupt handler during the interval until the processing in the interrupt handler ends, the RI850V4 executes only processing such as queue manipulation, counter manipulation, etc., and the actual dispatch processing is delayed until a return instruction is issued by the interrupt handler, upon which the actual dispatch processing is performed in batch.
- Acceptance of EI level maskable interrupts
When passing control to an interrupt handler, the RI850V4 disables acceptance of EI level maskable interrupts by manipulating the PM
n bits (set to enabled) in the priority mask register (PMR) and the ID bit (set to disabled) in the program status word (PSW).
10.3.3 Define interrupt handler
The RI850V4 supports the static registration of interrupt handlers only. They cannot be registered dynamically by issuing a service call from the processing program.
Static interrupt handler registration means defining of interrupt handlers using static API "DEF_INH" in the system configuration file.
10.4 Base Clock Timer Interrupts
If a base clock timer interrupt occurs, The RI850V4's time management interrupt handler is activated and executes time-related processing (system time update, delayed wakeup/timeout of task, cyclic handler activation, etc.).
In the RI850V4, occurrence of an interrupt in an interrupt handler is called "multiple interrupts".
Execution of interrupt handler is started in the interrupt disabled state (the ID flag of the program status word PSW is set to 1). To generate multiple interrupts, processing to cancel the interrupt disabled state (such as issuing of EI instruction) must therefore be coded in the interrupt handler explicitly.
The following shows a processing flow when multiple interrupts occur.
Figure 10-2 Multiple Interrupts
