QDK PIC24/dsPIC-XC16 - Quantum Leaps

QDK
PIC24/dsPIC-XC16
www.state-machine.com/pic
5 Implementing “Zero Interrupt Latency” with the NMI
As noted in Section 3.2, the interrupt locking policy in this QP port locks only interrupts with IPL from 1 to
6. The highest-level interrupts with IPL=7 are not locked at all. In other words, IPL=7-interrupts are nonmaskable
(they are NMIs). This interrupt locking policy has two important consequences.
First, the IPL=7-interrupts cannot call any QP services (e.g., NMIs cannot post events to QP tasks),
because any system call from an NMI would run the risk of corrupting the internal QP data since the
protection by critical sections does not apply for NMIs.
On the flip side, however, the IPL=7-interrupts run completely “free” with the interrupt latency determined
only by the underlying hardware and independent on the critical sections implemented in the QP. This is
what is meant here by the term “Zero Interrupt Latency”.
Such NMIs (IPL=7-interrupts, in this case) have many potential uses. They are very useful when the
software must perform some simple operations very fast, but most of the time the software does not need
to communicate with the task-level of QP active objects. Consider for example a fast interrupt-driven
UART interface. The ISR that receives bytes must remove the bytes from the FIFO very fast or else the
FIFO will quickly overflow. However, the ISR might buffer the bytes and only need to notify the task level
when the buffer fills up, which is relatively infrequently.
NOTE: NMIs (IPL=7-interrupts, in this case) can be equally well used in the non-preemptive QP port
as well as in the preemptive port with the QK kernel.
5.1 Communication between NMIs and QP
From the previous discussion it is obvious that the NMIs must be able to communicate from time to time
with the task level (active objects in QP). The question is how to achieve such communication without
calling QP services directly
The solution is to call QP services indirectly, by triggering a regular (maskable) interrupt from the NMI. In
the PIC24/dsPIC architecture you can very easily trigger an ISR by explicitly setting the corresponding
interrupt flag (the same that you explicitly clear in the ISR). The triggered interrupt can call QP services,
such as posting or publishing events to QP active objects.
The subtle, but important consideration is the communication between the NMI and the triggered
maskable interrupt. Typically, such communication must occur by means of atomically-accessed shared
variables. In the PIC24/dsPIC CISC architecture most 8- and 16-bit variables are read and written
atomically (in one machine instruction), so implementing this way of communication is quite easy. In other
CPUs, such as RISC load-store architectures, the implementation of atomic access is trickier and requires
using special swap (SWP) instructions.
5.2 Implementation Considerations for the NMIs
Because the NMIs run completely “free” and outside the QP framework, they don’t need to follow any
conventions associated with regular maskable ISRs that can call QP services. Generally, the NMIs should
run as fast as possible, because the interrupt latency for NMIs is determined typically by the execution
time of the NMI itself. (In this QP port, only one IPL level 7 is available for NMIs, so NMIs cannot preempt
each other).
NMIs can be coded in C, and in fact the XC16 compiler offers options to make these interrupts very
efficient. On of these options is __shadow__, which uses fast context save and restore to the shadow
registers. Obviously, you can use only one such fast ISR in your system to avoid corruption of the shadow
registers. And finally, you should generally avoid calling any functions from the NMI, as this would force
the compiler to save and restore w0-w7.
Copyright © Quantum Leaps, LLC. All Rights Reserved.
26 of 35