13.3.6. Example of Angel processing: a simple IRQ

This section gives an example of processing a simple IRQ from start to finish, and describes in more detail how Angel task management affects the receipt of data through interrupts. Refer also to Angel communications architecture for an overview of Angel communications.

Figure 13.4 shows the application running, when an interrupt request (IRQ) is made that completes the reception of a packet.

Figure 13.4. Processing a simple IRQ

The IRQ is handled as follows:

  1. The Interrupt exception is noticed by the processor. The processor:

    • fetches the IRQ vector

    • enters Interrupt mode

    • starts executing the Angel Interrupt Service Routine.

    On entry to the IRQ handler, FIQ interrupts are disabled if HANDLE_INTERRUPTS_ON_FIQ=1 (the default is 0, FIQ interrupts enabled). Interrupts are not re-enabled until either:

    • Angel_SerialiseTask() is called

    • the interrupt completes.

  2. The Angel ISR saves the processor state in a register block, uses the GETSOURCE macro to determine the interrupt source, and jumps to the handler. The processor state is saved because this data is required by Angel_SerialiseTask().

  3. The interrupt handler determines the cause of the IRQ. If the interrupt is not an Angel interrupt it returns immediately.

    If the interrupt is an Angel interrupt and the driver uses polled input, the handler calls Angel_SerialiseTask() to schedule processing. If the driver does not use polled input, the handler calls Angel_SerialiseTask() to schedule processing if:

    • the end of packet character is reached

    • the end of request is reached for a raw device (determined by length)

    • the ring buffer is empty (tx), or full (rx).

  4. If Angel_SerialiseTask() is not required, the ISR reads out any characters from the interrupting device and returns immediately.

  5. Angel_SerialiseTask() saves the stored context from step 2 and creates a new task. It then executes the current highest priority task. The new task is executed after all tasks of higher priority have been executed.

  6. The new task executes in Supervisor mode. It reads the packet from the device driver to create a proper ADP packet from the byte stream.

  7. When the packet is complete, the task schedules a callback task to process the newly arrived packet.

  8. The callback routine processes the packet and terminates. Angel_NextTask() finds that the application is the highest priority task, and Angel_SelectNextTask() restarts the application by loading the context stored at step 2 into the processor registers.

Copyright © 1997, 1998 ARM Limited. All rights reserved.ARM DUI 0040D