3.8Interrupt Processing

As shown in Section 3.2.4, the only device generating interrupts is the DUART using interrupt level 2, which corresponds to autovector #2 in the CPU’s vector table. After reset, interrupts from the DUART are disabled in the DUART, and in addition, the CPU’s interrupt mask is set to level 7, thus preventing interrupts from the DUART. Before discussing the interrupt processing, we shall have a look at the hardware initialization.

3.8.1 Hardware Initialization

Hardware initialization is performed in two steps, which are controlled by the variable os::init_level and by the function os::init() which performs initialization up to a requested level.

1 /* os.hh */

...

18class os

19{

After RESET, the init_level is Not_initialized. The Polled_IO level refers to a hardware state, where the DUART is initialized, but interrupts are masked. The final level is Interrupt_IO, where interrupts are also enabled. If an initialization to Interrupt_IO is requested, then the initialization for level Polled_IO is automatically performed by the os:init() function. During normal system start-up, the Polled_IO level is never requested; instead, the initialization jumps directly from Not_initialized to Interrupt_IO. This happens at a rather late stage in the start-up of the system. If debugging printouts are inserted during system start-up, then the Putc_0/1_polled() functions request initialization to level Polled_IO.

128void os::init(INIT_LEVEL iLevel)

129{

132if (init_level < Polled_IO)

133{

134initDuart(DUART, CSR_9600, CSR_9600);

135init_level = Polled_IO;

136}

137

that all interrupts are accepted. The main() function is actually executed by the idle task, which deschedules itself and then enters an infinite loop. Since the idle task has the lowest priority of all tasks, it only executes if all other tasks are blocked. It thus stops the CPU until the next interrupt occurs.

3.8.2 Interrupt Service Routine

As we already saw, the only interrupt that could occur in our system is an autolevel 2 interrupt. Of course, the system can be easily extended to support more peripherals. Thus if an interrupt occurs, the CPU fetches the corresponding interrupt vector and proceeds at the address _duart_isr, where the interrupt service routine for the DUART starts. The CPU is in supervisor mode at this point.

The CPU first turns on a LED. This LED is turned off each time the CPU is stopped. The brightness of the LED thus shows the actual CPU load, which is very useful sometimes. The CPU then saves its registers onto the system stack and reads the interrupt status from the DUART which indicates the source(s) of the interrupt.

If the interrupt is caused by the receiver for SERIAL_0, then the received character is read from the DUART and put into the receive queue of SERIAL_0. This queue has a get semaphore, so that as a consequence, a task blocked on the receive queue may be unblocked. Reading the received character from the DUART automatically clears this interrupt.

...

The same applies for an interrupt from the receiver for SERIAL_1.

If the interrupt is caused by the transmitter for SERIAL_0, then the next character from the transmit queue for SERIAL_0 is fetched. The transmit queue may be empty, however; in this case, the transmitter is disabled to clear the interrupt. This is also indicated towards the Putc_0() function by the SerialOut::TxEnabled_0 variable (see also Section 3.7.3). If the queue is not empty, then the next character is written to the DUART which clears this interrupt.

The same is true for an interrupt from the transmitter for SERIAL_1.

The last option is a timer interrupt. In this case, the interrupt is cleared by writing to the DUART’s stop/start registers. Next, a pair of variables indicating the system time since power on in milliseconds is updated. This implements a simple system clock:

A common problem is to poll a peripheral (e.g. a switch) in regular intervals or to wait for certain period of time. Neither blocking a task or busy wait is appropriate for this purpose. Instead, we implement a function Task::Sleep() which will be explained later on. This Sleep() function uses a variable TaskSleepCount for each task which is decremented with every timer interrupt. If the variable reaches 0, the task return to state RUN by clearing a particular bit in the task’s status register.

Now all interrupt sources causing the present interrupt are cleared. During this process, new interrupts may have occurred. In that case, the interrupt service routine will be entered again when returning from exception processing. The interrupt processing is finished by restoring the interrupts saved at the beginning.

The variable _consider_ts may or may not have been set during the interrupt service routine. The final step is to proceed at label _return_from_exception.

The processing at label _return_from_exception has already been described in Section 3.3, i.e. it will be checked whether a task switch is required. Note that for the code starting at _return_from_exception it makes no difference whether a task switch was caused by an interrupt or not.