Hi all,

I have an interrupt which is caused every 10 ms and it is served by an ISR. I am also executing a user-space process inside a while(1) loop.

The problem is that the user-space process is affecting the ISR execution. Is this reasonable? How can I assure that when my ISR is executed no other processes are running?

The thing that I want looks like the following graph:

-------------------------------------------------------
ISR | Processes | ISR | Processes |
--------------------------------------------------------(ms)
0____________10_____________20

and not something like:
-------------------------------------------------------
ISR |_________| ISR |_________|
--------------------------------------------------------
__________Processes_________|
--------------------------------------------------------(ms)
0___________10____________20


Any help would be more than welcomed!

Thank you all!

The interrupts are as their name say interrupts - they will interrupt any processing running and call the handler. I do not know what do you want, maybe the interrupts are not the solution.

Also, besides stating the problem, you should give more info (operating system, how do you set interrupts).

Perhaps you are doing too much in the ISR? Regardless of what other processes are doing, any enabled interrupt will cause the kernel's interrupt dispatch routine to be invoked. If you need greater "determinism" in the scheduling of the ISR you should look at the "Real Time" patches. However, no tweaking of the kernel will save you if you're simply trying to do too much work on a single processor.

Hi, and thanks for the very quick reply!

I am using kernel 2.6.20.4 in an ARM EP9302 based embedded board.

My ISR is being served when I have an overflow of an on-board timer.

What I want is when my handler runs (every 10 ms) no other processes to run until the handler ends its work.

I want all the processes to run after the end of the ISR and until its next call as in the following graph:


-------------------------------------------------------
ISR | Processes | ISR | Processes |
--------------------------------------------------------(ms)
0____________10_____________20


I know that this is not the case because I have interference from a user-space process to the proper execution of my handler.

In my case, I want on top of all proper execution of the handler.

Any ideas?

P.S: I want to have the above scenario but without the use of a RT patch such as RTAI and RT-Linux.

Thank you all!

I don't think that this is the case because when I am not running a particular user-space process (which uses a while(1) loop), the execution of the ISR is proper.

But when I am running this user-space process with the while(1) loop, it affects the proper execution of my ISR.

In particular, I am blinking an LED every second inside my ISR and when I am runnning the user-space process the LED starts blinking randomly.

I am really having hard time with this!

Thank you again!

Did you disabled interrupts in you ISR (put a disable interrupt at start and an enable interrupt at the end) ? If you didn't other things might happen while you process your interrupt.

I do not understand how do you do blink the LED every second ? You mean, each 100 runs of the ISR you blink the LED ?

I do not know what kind of interrupt controller do you have. Does it has something like priorities ? (maybe another interrupt gets served first)

Consider very strongly that you are doing unnecessary things in your Interrupt Handler if you are executing more than two instructions (plus enable and disable instructions). That's two machine code instructions, not two high level language statements.

You get into a handler, it has to increment a count and then go away. That shouldn't need much complication. A separate issue is to toggle the state of a port pin on every 50th run of the ISR. That's incrementing a count up to fifty setting the count to zero and flipping a bit; you might be able to regard that part of the process as interruptible (but your 'user space' code wouldn't get in).

What other interrupts are active at the same time? Can they be masked, at least for the duration of this interrupt? (Have you any idea of the duration of your ISR? You could measure that.)

Without interrupts, the thing that you are calling a user-space process shouldn't be getting in, once the ISR has started, but your OS probably does stuff with interrupts too, that you may or may not know about.

I'm not sure about the EP9302, but some ARMs (Cortex M3s for example), have quite configurable interrupt controllers and there may well stuff you can do there to help. The danger is that you stop the OS doing stuff it has to do, particularly if you don't know what your OS is doing...

Do it like this:

1. The only purpose of the interrupt is to say, "tick!" All that the interrupt handler does is to, say, increment a counter and wake-up a user-mode process that is waiting on the timer. (Let's say you have a /dev defined for the device, and the user-mode process is waiting on a fcntl() or even a read.) Or some kind of event. It doesn't do anything else.
2. The user-mode process does the work that you now delegate to the interrupt-handler.
3. The user-mode process now signals an event or semaphore that the other, lower-priority user-mode processes are waiting for. Each of those processes (running in no particular order on an unknown number of CPUs) now does their work.
4. If the first process wants to wait for the others to be done, an event or semaphore is used for that.
5. If the interrupt handler increments a counter, or sets an event-flag, this gives the first process a way to know when it is "running behind." (The counter value changed within the loop.) It waits, or not, as necessary.