the value of next_interrupt_vector is a zero when printed. Should I check for that before calling ioint_link()? When I start an output, for example, my print statements in MyISR are constantly being displayed. Why is my interrupt service being called by the system? Am I not initializing my ISR correctly?
>the value of next_interrupt_vector is a zero when printed. Should I >check for that before calling ioint_link()? >When I start an output, for example, my print statements in MyISR are >constantly being displayed. >Why is my interrupt service being called by the system? >Am I not initializing my ISR correctly?
I have more information.
MyISR performs an ssignal to wake up a thread to process the interrupt The thread will acknowledge the interrupt once it starts. I think (newbie here) the problem is that since the interrupt has not been acknowledge the system generates another interrupt. The thread never awakes because the OS is busy generating the interrupt that I have not processed.
Does this sound like what might be happening. MyISR is constantly being call because the interrupt is still be generated by the device. should I acknowledge the interrupt in the interrupt context?
>>the value of next_interrupt_vector is a zero when printed. Should I >>check for that before calling ioint_link()? >>When I start an output, for example, my print statements in MyISR are >>constantly being displayed. >>Why is my interrupt service being called by the system? >>Am I not initializing my ISR correctly?
Remember that other device drivers may share the interrupt vector with yours. Inside your ISR, you need to check to make sure the interrupt came from your device before you take action.
>MyISR performs an ssignal to wake up a thread to process the interrupt >The thread will acknowledge the interrupt once it starts. I think >(newbie here) the problem is that since the interrupt has not been >acknowledge the system generates another interrupt. The thread never >awakes because the OS is busy generating the interrupt that I have not >processed.
>Does this sound like what might be happening. MyISR is constantly >being call because the interrupt is still be generated by the device. >should I acknowledge the interrupt in the interrupt context?
Yes, you need to either acknowledge or disable the interrupt in interrupt context. Which one to do depends on your device. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices...
>>>the value of next_interrupt_vector is a zero when printed. Should I >>>check for that before calling ioint_link()? >>>When I start an output, for example, my print statements in MyISR are >>>constantly being displayed. >>>Why is my interrupt service being called by the system? >>>Am I not initializing my ISR correctly?
>Remember that other device drivers may share the interrupt vector >with yours. Inside your ISR, you need to check to make sure the >interrupt came from your device before you take action.
>>MyISR performs an ssignal to wake up a thread to process the interrupt >>The thread will acknowledge the interrupt once it starts. I think >>(newbie here) the problem is that since the interrupt has not been >>acknowledge the system generates another interrupt. The thread never >>awakes because the OS is busy generating the interrupt that I have not >>processed.
>>Does this sound like what might be happening. MyISR is constantly >>being call because the interrupt is still be generated by the device. >>should I acknowledge the interrupt in the interrupt context?
>Yes, you need to either acknowledge or disable the interrupt in >interrupt context. Which one to do depends on your device.
Thanks for the reply.
I got the interrupts working. I had to read the interrupt value from the hardware interrupt vector register. When I did this, it acknowledges the interrupt which, in turn allows me to wake up the interrupt thread. The only thing I had to do was create a queue to hold the interrupt vector because it was possible to have two interrupts back to back (Read/Write). The stored interrupt vector is then processed by the sleeping thread.
Do you have any ideas how long it takes for an interrupt thread to be woken-up from a non-signal state? When I try to cancel an output, for example, I'm waiting 250ms using usec_wait(). then I check the output status to determine if the output was cancelled. It's not. Eventually it is. I can see in the print statements. Maybe these debug print statement are messing thing up. Got to check on that.
>> the value of next_interrupt_vector is a zero when printed. Should I >> check for that before calling ioint_link()? >> When I start an output, for example, my print statements in MyISR are >> constantly being displayed. >> Why is my interrupt service being called by the system? >> Am I not initializing my ISR correctly?
> I have more information.
> MyISR performs an ssignal to wake up a thread to process the interrupt > The thread will acknowledge the interrupt once it starts. I think > (newbie here) the problem is that since the interrupt has not been > acknowledge the system generates another interrupt. The thread never > awakes because the OS is busy generating the interrupt that I have not > processed.
This can happen with some devices. In such a case it's better to ack the interrupt in the handler and defer processing to the thread.
> Does this sound like what might be happening. MyISR is constantly > being call because the interrupt is still be generated by the device. > should I acknowledge the interrupt in the interrupt context?
Yes, you should at least try that and see what happens.
In article <ucgq649brm3bkfdmk0s4d2kfqis6i7l...@4ax.com>,
John <jvasq...@cox.net> wrote: >Do you have any ideas how long it takes for an interrupt thread to be >woken-up from a non-signal state?
Depends on what higher-priority tasks are running. If there aren't any, it should be in a few tens of microseconds. LynuxWorks used to publish that number, but I've managed to forget what we called it back then (hey, it's been 8 years, I figure I'm entitled).
>When I try to cancel an output, for example, I'm waiting 250ms using >usec_wait(). then I check the output status to determine if the output >was cancelled. It's not. Eventually it is. I can see in the print >statements. Maybe these debug print statement are messing thing up. >Got to check on that.
Debug prints take a huge amount of time, and can screw up critical timing. If you have important timing, log little bits into a memory area and dump it out from something else. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices...
>>> the value of next_interrupt_vector is a zero when printed. Should I >>> check for that before calling ioint_link()? >>> When I start an output, for example, my print statements in MyISR are >>> constantly being displayed. >>> Why is my interrupt service being called by the system? >>> Am I not initializing my ISR correctly?
>> I have more information.
>> MyISR performs an ssignal to wake up a thread to process the interrupt >> The thread will acknowledge the interrupt once it starts. I think >> (newbie here) the problem is that since the interrupt has not been >> acknowledge the system generates another interrupt. The thread never >> awakes because the OS is busy generating the interrupt that I have not >> processed.
>This can happen with some devices. In such a case it's better to ack the >interrupt in the handler and defer processing to the thread.
>> Does this sound like what might be happening. MyISR is constantly >> being call because the interrupt is still be generated by the device. >> should I acknowledge the interrupt in the interrupt context?
>Yes, you should at least try that and see what happens.
I got my interrupt working. I had to create a small queue that will contain the interrupt to process. The Interrupt Thread, when woken up, will then check the queue and process the interrupt.
