DPC means Delayed Procedure Call
You can see how are working DPC's in the source of OpenXDK :
The goal is to not spend too much time in the code that handles a fired interrupt (or VERY bad things may occur, usually a nice impossible to understand freeze). So you schedule another call, which will be as long as you want, but later.
Progress around OpenXDK, as a whole, was gloomy for some time because of nasty issues, like Controller not responding, etc... It was due to a lack of DPC usage.
In your module you just need these declarations :
static KINTERRUPT InterruptObject;
static KDPC DPCObject;
To initialize :
Inside your interrupt handler (be quick!) :
KeInsertQueueDpc queues Dpc and returns TRUE if Dpc not already queued. Dpc will be queued only once. So only one Dpc is fired after ISRs cease fire. The last parameters are the two SystemArgumentN pointers that can be passed to DPC later
Do only fast things that can't be delayed, like setting some Ack/Enable bit to respond to chipset correctly.
The code that handles the delayed procedure call (will be called by kernel later, in a safe way) :
static void __stdcall DPC(PKDPC Dpc,
You can take your time here! Of course interrupts can fire anytime, but they will just enqueue DPC's. DPC's are always launched one afther another. They don't interrupt each other, they won't be 'nested'.
DPCs avoid crashes inside non reentrant user callbacks called by nested ISRs. CAUTION : if you use fpu in DPC you have to save & restore yourself fpu state!!! (fpu=floating point unit, i.e the coprocessor executing floating point opcodes)
Do your lengthy stuff here. It's only safe here.
Typically you call a user defined callback
(think about saving/restoring fpu state).
It's heavily used in all Microsoft operating systems.
If you are a XDK user, be aware it's used a lots of course, but you don't know it. Under OpenXDK, if you play with interrupts, you need to master DPC's yourself.
Edited by openxdkman, 14 June 2008 - 10:37 AM.