Reputation: 1629
Recently, I ran into a situation where I would like to use threaded IRQ's
for a Keypad driver. For some background on threaded IRQ
handlers:
http://lwn.net/Articles/302043/
From what I understand, every time an IRQ
would occur the IRQ
handler thread would be woken up. So, if i press KEY A
, it wakes up the thread and it runs through to completion. Now, what would be the behavior should i press KEY B
, when the handler thread is still running while servicing the IRQ
from KEY A
... Would the IRQ
from KEY B
be ignored ?
What would be the expected behavior ?
Upvotes: 3
Views: 7185
Reputation: 3602
The way it works with interrupts is that processor will call an enabled interrupt over and over again until application clears the corresponding interrupt flag. So what you do is disable that particular interrupt in the hardware handler and wake up your thread. When hardware handler exits, interrupt flags will be set but the interrupt will not be called again. So you then in your thread checkeach flag and clear it as you go. When you detect that a flag for a keypress is set, you read out the key and then clear it. If a new key is pressed after you read data register and there is no fifo in hardware then that key press will be lost. You then clear the interrupt flag and enable the hardware interrupt again. The idea is that this process happens so fast that there is no way to lose a key because your thread will always run sooner than human can press another key.
In the situation such as usb (ie if you write a usb driver that communicates with pc) you have the option to tell usb peripheral when you are done reading data so it can tell the host it can accept more data. In that situation you can never lose data because you will read data out and clear the flag and only then tell the peripheral that you are ready. All the time until then the peripheral will tell the host that it is not ready so no data will be clocked in over the usb bus.
Upvotes: 0
Reputation: 4914
Ideally the system would always acknowledge the sequence of Key A->Key B.
However to acknowledge that a key was pressed, the system must do something at the point at which each key is pressed, I.e. when the keyboard interrupt occurs - at a minimum it must record the key presses, perhaps in a queue.
And from the perspective of a single processor, it can only do one thing at a time, so if it is in the middle of recording key press A, then it can't at the same time record key press B. It would either have to abandon A and record B instead, or it would have to ignore B.
Thus the goal of interrupt handling is to minimise the amount of time the processor spends doing the minimum it needs to for acknowledging any given interrupt.
The goal of threaded interrupts is to push more of the work to separate threads, so that the minimum needed for acknowledging an interrupt is reduced, and therefore the time spent handling the interrupt (where it can't handle any other interrupts at the same time) is reduced.
Even then there is still no theoretical guarantee that the processor won't have to discard or ignore interrupts, but it does make it a lot less likely in practice.
For your specific example of key presses, if you were somehow able to be quick enough to press B before the processor had completed its minimum handling of A, then since both interrupts are from the same source, and therefore have the same priority, B would be ignored, and it would appear to you as if B was never pressed.
Upvotes: 4