ISR using InterruptAttach

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.

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.

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.

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?

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.

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.

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.

There is no need to start two instances of devc-ser8250. It can handle multiple com port at the same time.

Hi Mario, I was intrested to know what would be the case in case two instances are started. Thats the reason for posting.

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?

Its less efficient resource wise to start two instances. There could also be a slight increase in CPU usage but its probably negligible.

However it does bring the advantage (if that`s one for you), of being able to start/stop/restart independently.

okay…is there a possibility of race conditions with the two instances? am sorry for a silly question

No.