Skip navigation.
Home
The QNX Community Portal

View topic - ISR using InterruptAttach

ISR using InterruptAttach

For discussion of realtime and/or embedded programming.

ISR using InterruptAttach

Postby rahil » Thu Oct 29, 2009 11:17 am

Hi

I have a single thread and in that thread I've defined my ISR_Handler() function. Now, I use the InterruptAttach() call to register this function with an IRQ (say 7).

Now when the IRQ line 7 is asserted,

1. Does the processor immediately performs the context-switch and execute the ISR or is there a delay?

2. Where is this ISR_Handler() function executed, in my thread (user-space) or somewhere else?

3. Why does ISR_Handler() function have limitations on use of library functions?
rahil
Active Member
 
Posts: 75
Joined: Wed Feb 11, 2009 12:13 pm
Location: India

Re: ISR using InterruptAttach

Postby mario » Thu Oct 29, 2009 12:44 pm

rahil wrote:Hi

I have a single thread and in that thread I've defined my ISR_Handler() function. Now, I use the InterruptAttach() call to register this function with an IRQ (say 7).

Now when the IRQ line 7 is asserted,

1. Does the processor immediately performs the context-switch and execute the ISR or is there a delay?

2. Where is this ISR_Handler() function executed, in my thread (user-space) or somewhere else?

3. Why does ISR_Handler() function have limitations on use of library functions?


1 - Yes
2- It's run in the context of the kernel ( but using the address space of the process)
3 - Because of 2

To fix 3, check out InterruptAttachEvent, but that does add a small delay/overhead.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

Re: ISR using InterruptAttach

Postby rahil » Thu Oct 29, 2009 2:00 pm

mario wrote:
rahil wrote:Hi

I have a single thread and in that thread I've defined my ISR_Handler() function. Now, I use the InterruptAttach() call to register this function with an IRQ (say 7).

Now when the IRQ line 7 is asserted,

1. Does the processor immediately performs the context-switch and execute the ISR or is there a delay?

2. Where is this ISR_Handler() function executed, in my thread (user-space) or somewhere else?

3. Why does ISR_Handler() function have limitations on use of library functions?


1 - Yes
2- It's run in the context of the kernel ( but using the address space of the process)
3 - Because of 2

To fix 3, check out InterruptAttachEvent, but that does add a small delay/overhead.


The answer 2 is very confusing....i must say i'm a novice, can you please elaborate more..... btw Thanks for the reply.
rahil
Active Member
 
Posts: 75
Joined: Wed Feb 11, 2009 12:13 pm
Location: India

RE: Re: ISR using InterruptAttach

Postby mario » Thu Oct 29, 2009 2:13 pm

The stack use will be that of the kernel, if the code crashed it will crash the kernel. If you try to allocated memory it will fail because it would be as if the kernel would try to allocate memory and not your program, which the kernel doesn't support.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

RE: Re: ISR using InterruptAttach

Postby maschoen » Fri Oct 30, 2009 3:46 pm

I'd like to add a little to what Mario has said.
1. When the interrupt handler fires, there is a hardware context switch that occurs. At that point you are not in your ISR yet. There are two reasons why your ISR might be delayed. 1) More than one ISR is attached to line 7. 2) A higher priority interrupt is in process. By the generally accepted rules of interrupt handlers (they need to be short) neither should involve a big delay, but if you are capturing the even on a scope, you could see these.

2-3. Running in the QNX Kernel is very different from running in a process context. The kernel is very small and most OS services eg. File I/O are done in a process so you don't spend much time in the kernel. The kernel cannot invoke itself. For example, the kernel cannot send a message to itself, this would make no sense since the kernel is not a process and the kernel implements messages. A lot of standard C calls, such as file or console I/O involve message passing, so they can't be called from the kernel.
maschoen
QNX Master
 
Posts: 2640
Joined: Wed Jun 25, 2003 5:18 pm

RE: Re: ISR using InterruptAttach

Postby rahil » Sat Nov 07, 2009 5:54 am

Thanks for the replies. I'd like to know one more thing here.
If I call the InterruptAttach(5, interrupt_handler1, NULL, NULL, NULL) on IRQ # 5 in one thread and then again InterruptAttach(5, interrupt_handler2, NULL, NULL, NULL) on IRQ # 5 in another thread. What will happen when the IRQ Line # 5 is asserted. Will the kernel call interrupt_handler1 or interrupt_handler2? What will happen in scenario of these threads in a same process and in a different process? What will happen when both these calls are in the same thread?
rahil
Active Member
 
Posts: 75
Joined: Wed Feb 11, 2009 12:13 pm
Location: India

RE: Re: ISR using InterruptAttach

Postby maschoen » Sat Nov 07, 2009 6:40 am

I don't think it matters whether you call InterruptAttach() twice from two different threads, the same thread, or different processes. What you are doing in is telling the kernel that when IRQ fires, call these handlers. Both should be called. I don't think you have any control over which is called first, however I suspect it is either a FIFO or LIFO situation, one you could check for and figure out.
maschoen
QNX Master
 
Posts: 2640
Joined: Wed Jun 25, 2003 5:18 pm

RE: Re: ISR using InterruptAttach

Postby anvesh » Sat Nov 07, 2009 6:59 am

Hi, I need some clarification of the below scenario: If an IRQ line say 5 is shared and attached to two serial COM ports, then how does the respective processes know whether the IRQ line asserted is for COMX or COMY . I have invoked devc-ser8250 twice, once for COMX and other for COMY.
anvesh
Active Member
 
Posts: 31
Joined: Wed Dec 03, 2008 6:57 am

RE: Re: ISR using InterruptAttach

Postby maschoen » Sat Nov 07, 2009 5:46 pm

They don't. The interrupt fires, and it is the job of the respective interrupt handler or process to query its hardware to see if there was an interrupt. A wakeup with nothing to do is always a possibility. the 8250 UART and like devices have a single register that can be read to see if there was an interrupt event and what it was.
maschoen
QNX Master
 
Posts: 2640
Joined: Wed Jun 25, 2003 5:18 pm

RE: Re: ISR using InterruptAttach

Postby mario » Mon Nov 09, 2009 7:44 pm

There is no need to start two instances of devc-ser8250. It can handle multiple com port at the same time.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

RE: Re: ISR using InterruptAttach

Postby anvesh » Tue Nov 10, 2009 6:24 am

Hi Mario, I was intrested to know what would be the case in case two instances are started. Thats the reason for posting.
anvesh
Active Member
 
Posts: 31
Joined: Wed Dec 03, 2008 6:57 am

RE: Re: ISR using InterruptAttach

Postby maschoen » Tue Nov 10, 2009 6:30 am

If each is configured for different hardware ports and different device names, they both should coexist and run. It is slightly less efficient for two Interrupt routines to be called, but that shouldn't cause a big problem. That said, other than curiosity, what's the reason for the question?
maschoen
QNX Master
 
Posts: 2640
Joined: Wed Jun 25, 2003 5:18 pm

RE: Re: ISR using InterruptAttach

Postby mario » Tue Nov 10, 2009 1:13 pm

It`s less efficient resource wise to start two instances. There could also be a slight increase in CPU usage but it`s probably negligible.

However it does bring the advantage (if that`s one for you), of being able to start/stop/restart independently.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

RE: Re: ISR using InterruptAttach

Postby rahil » Wed Nov 11, 2009 5:28 am

okay....is there a possibility of race conditions with the two instances? am sorry for a silly question
rahil
Active Member
 
Posts: 75
Joined: Wed Feb 11, 2009 12:13 pm
Location: India

RE: Re: ISR using InterruptAttach

Postby mario » Wed Nov 11, 2009 12:17 pm

No.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am


Return to Realtime and Embedded

Who is online

Users browsing this forum: No registered users and 1 guest