Can you feed it periodically, before it is actually empty? If so, you should be able to fudge things a bit by telling the app the previous transfer is done prior to it actually completing, so you get another request, and then feeding the first few bytes of the next data as soon as the app sends the next block of data.
Can you read the state of the FIFO to determine how full it is, or do you only get empty/not empty?
If you really only get an interrupt when the FIFO is completely empty, and you can’t keep feeding it periodically, before it actually goes empty, then you’ll probably get the best results with a dedicated worker thread that dumps the data into the FIFO and completes the request, and then spins on the status register that tells your ISR it was your device that interrupted, and as soon as it toggles, starts dumping another block of data into the FIFO. Since you know it takes a while to write out the bytes you just dumped in, you can DelayExecution for a while, before you star spinning on the register.
Your callback would just stick the WDFREQUEST into a WDFQUEUE, and the worker would take the request out of the queue, write the data, and complete the request.
Phil
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Marion Bond
Sent: Tuesday, April 14, 2015 4:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: [ntdev] Re: [ntdev] IRQL Priority Problems
Hijacking your only core is equivalent to simply doing the work & stalling in your ISR. In that case, Peter’s hybrid approach is probably the best choice
Sent from Surface Pro
From: Brad Asweganmailto:xxxxx
Sent: Tuesday, April 14, 2015 6:28 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
I’m actually on a conference call discussing this now. We really appreciate all the suggestions. We did look into other possible interrupting options, this chip ONLY supports an FIFO_EMPTY interrupt. We have approximately 360 microseconds after the empty interrupt to put more data into the buffer before that final word is done being transmitted.
We only have a single core processor as we disabled hyperthreading. Hyperthreading was causing lots and lots of problems with timings and our very deterministic application. Is it possible to “hijack” the only core we have? When we still had hyperthreading enabled, I tried reassigning our driver to the second “core” and it appears the framework still executes all ISRs on the primary “core”.
Cheers,
Brad</mailto:xxxxx></mailto:xxxxx>