Software Interrupts
4-30
Note: Two things to remember about SWI:
When an SWI starts executing it must run to completion without blocking.
When called from within an HWI, the code sequence calling any of the SWI
functions which can trigger or post a software interrupt must be either
wrapped within an HWI_enter/HWI_exit pair or invoked by the HWI
dispatcher.
SWI functions can be preempted by threads of higher priority (such as an
HWI or an SWI of higher priority). However, SWI functions cannot block. You
cannot suspend a software interrupt while it waits for something—like a
device—to be ready.
If an SWI is posted multiple times before the SWI Manager has removed it
from the posted SWI list, its SWI function executes only once, much like an
HWI is executed only once if the hardware interrupt is triggered multiple times
before the CPU clears the corresponding interrupt flag bit in the interrupt flag
register. (See Section 4.3.5, Using an SWI Object’s Mailbox, page 4-30, for
more information on how to handle SWIs that are posted multiple times
before they are scheduled for execution.)
Applications should not make any assumptions about the order in which SWI
handlers of equal priority are called. However, an SWI handler can safely post
itself (or be posted by another interrupt). If more than one is pending, all SWI
handlers are called before any tasks run.
4.3.5 Using an SWI Object’s Mailbox
Each SWI object has a 32-bit mailbox, which is used either to determine
whether to post the software interrupt or as values that can be evaluated
within the SWI function.
SWI_post, SWI_or, and SWI_inc post an SWI object unconditionally:
❏ SWI_post does not modify the value of the SWI object mailbox when it is
used to post a software interrupt.
❏ SWI_or sets the bits in the mailbox determined by a mask that is passed
as a parameter, and then posts the software interrupt.
❏ SWI_inc increases the SWI's mailbox value by one before posting the
SWI object.
To Next Page
Loading...
Need help?
General
