EasyManua.ls Logo

ST SPC560P34 - Lowering Priority Within an ISR; Negating an Interrupt Request Outside of Its ISR

ST SPC560P34
936 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
Interrupt Controller (INTC) RM0046
238/936 Doc ID 16912 Rev 5
value in the INTC_PSRx_x and will not cause preemptive scheduling inefficiencies. After
generating a software settable interrupt request, the higher priority ISR completes. The
lower priority ISR is scheduled according to its priority. Execution of the higher priority ISR is
not resumed after the completion of the lower priority ISR.
Scheduling an ISR on another processor
Because the SETx bits in the INTC_SSCIRx_x are memory mapped, processors in multiple-
processor systems can schedule ISRs on the other processors. One application is that one
processor wants to command another processor to perform a piece of work and the initiating
processor does not need to use the results of that work. If the initiating processor is
concerned that the processor executing the software configurable ISR has not completed
the work before asking it to again execute the ISR, it can check if the corresponding CLRx
bit in INTC_SSCIRx_x is asserted before again writing a ‘1’ to the SETx bit.
Another application is the sharing of a block of data. For example, a first processor has
completed accessing a block of data and wants a second processor to then access it.
Furthermore, after the second processor has completed accessing the block of data, the
first processor again wants to access it. The accesses to the block of data must be done
coherently. To do this, the first processor writes a ‘1’ to a SETx bit on the second processor.
After accessing the block of data, the second processor clears the corresponding CLRx bit
and then writes 1 to a SETx bit on the first processor, informing it that it can now access the
block of data.
9.7.8 Lowering priority within an ISR
A common method for avoiding preemptive scheduling inefficiencies with an ISR whose
work spans multiple priorities (see Section , “Scheduling a lower priority portion of an ISR) is
to lower the current priority. However, the INTC has a LIFO whose depth is determined by
the number of priorities.
Note: Lowering the PRI value in INTC_CPR within an ISR to below the ISR’s corresponding PRI
value in INTC Priority Select Registers (INTC_PSR0_3–INTC_PSR220_221) allows more
preemptions than the LIFO depth can support.
Therefore, the INTC does not support lowering the current priority within an ISR as a way to
avoid preemptive scheduling inefficiencies.
9.7.9 Negating an interrupt request outside of its ISR
Negating an interrupt request as a side effect of an ISR
Some peripherals have flag bits that can be cleared as a side effect of servicing a peripheral
interrupt request. For example, reading a specific register can clear the flag bits and their
corresponding interrupt requests. This clearing as a side effect of servicing a peripheral
interrupt request can cause the negation of other peripheral interrupt requests besides the
peripheral interrupt request whose ISR presently is executing. This negating of a peripheral
interrupt request outside of its ISR can be a desired effect.
Negating multiple interrupt requests in one ISR
An ISR can clear other flag bits besides its own. One reason that an ISR clears multiple flag
bits is because it serviced those flag bits, and therefore the ISRs for these flag bits do not
need to be executed.

Table of Contents

Related product manuals