1

As we know we write Embedded C programming, for task management, memory management, ISR, File system and all.
I would like to know if some task or process is running and at the same time an interrupt occurred, then how SW or process or system comes to know that, the interrupt has occurred? and pauses the current task execution and starts serving ISR.

Suppose if I will write the below code like;

// Dummy Code
void main()
{
    for(;;)
        printf("\n forever");
}

// Dummy code for ISR for understanding
void ISR()
{
    printf("\n Interrupt occurred"); 
}

In this above code if an external interrupt(ISR) occurs, then how main() comes to know that the interrupt occurred? So that it would start serving ISR first?

Allen
  • 162
  • 2
  • 3
  • 15
Rasmi Ranjan Nayak
  • 11,510
  • 29
  • 82
  • 122
  • 2
    Main() should return int. And it is unsafe to invoke printf() from a signal handler or interrupt handler. – wildplasser Jun 12 '12 at 12:34
  • read your system documentation, which most likely is not hosted on stackoverflow.com – tbert Jun 12 '12 at 13:01
  • 2
    @wildplasser No main should _not_ return int, this is not a PC. The post is explicitly tagged as embedded system. Read [this](http://stackoverflow.com/questions/5296163/why-is-the-type-of-the-main-function-in-c-and-c-left-to-the-user-to-define/5296593#5296593). – Lundin Jun 12 '12 at 14:50
  • @Lundin: I just wrote a dummy code. It's not real – Rasmi Ranjan Nayak Jun 15 '12 at 02:58

7 Answers7

4

main doesn't know. You have to execute some-system dependent function in your setup code (maybe in main) that registers the interrupt handler with the hardware interrupt routine/vector, etc.

Whether that interrupt code can execute a C function directly varies quite a lot; runtime conventions for interrupt procedures don't always follow runtime conventions for application code. Usually there's some indirection involved in getting a signal from the interrupt routine to your C code.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
3

your query: I understood your answer. But I wanted to know when Interrupt occurs how the current task execution gets stopped/paused and the ISR starts executing?

well Rashmi to answer your query read below,

when microcontroller detects interrupt, it stops exucution of the program after executing current instruction. Then it pushes PC(program counter) on to stack and loads PC with the vector location of that inerrupt hence, program flow is directed to interrrupt service routine. On completion of ISR the microcontroller again pops the stored program counter from stack and loads it on to PC hence, program execution again resumes from next location it was stopped. does that replied to your query?

Kinjal Patel
  • 405
  • 2
  • 7
2

It depends on your target.

For example the ATMEL mega family uses a pre-processor directive to register the ISR with an interrupt vector. When an interrupt occurs the corrosponding interrupt flag is raised in the relevant status register. If the global interrupt flag is raised the program counter is stored on the stack before the ISR is called. This all happens in hardware and the main function knows nothing about it.

In order to allow main to know if an interrupt has occurred you need to implement a shared data resource between the interrupt routine and your main function and all the rules from RTOS programming apply here. This means that as the ISR may be executed at any time it as not safe to read from a shared resource from main without disabling interrupts first.

On an ATMEL target this could look like:

volatile int shared;

int main() {
  char status_register;
  int buffer;
  while(1) {
    status_register = SREG;
    CLI();
    buffer = shared;
    SREG = status_register;
    // perform some action on the shared resource here.
  }
  return 0;
}

void ISR(void) {
  // update shared resource here.
}

Please note that the ISR is not added to the vector table here. Check your compiler documentation for instructions on how to do that.

Also, an important thing to remember is that ISRs should be very short and very fast to execute.

Kenneth
  • 1,167
  • 1
  • 13
  • 26
  • 4
    All shared resources must be volatile, to guard against dangerous compiler optimizations. – Lundin Jun 12 '12 at 14:52
1

On most embedded systems the hardware has some specific memory address that the instruction pointer will move to when a hardware condition indicates an interrupt is required.

When the instruction pointer is at this specific location it will then begin to execute the code there.

On a lot of systems the programmer will place only an address of the ISR at this location so that when the interrupt occurs and the instruction pointer moves to the specific location it will then jump to the ISR

try doing a Google search on "interrupt vectoring"

Toby
  • 9,696
  • 16
  • 68
  • 132
1

An interrupt handling is transparent for the running program. The processor branchs automatically to a previously configured address, depending on the event, and this address being the corresponding ISR function. When returning from the interrupt, a special instruction restores the interrupted program.

Actually, most of the time you won't ever want that a program interrupted know it has been interrupted. If you need to know such info, the program should call a driver function instead.

Benny
  • 4,095
  • 1
  • 26
  • 27
1

interrupts are a hardware thing not a software thing. When the interrupt signal hits the processor the processor (generally) completes the current instruction. In some way shape or form preserves the state (so it can get back to where it was) and in some way shape or form starts executing the interrupt service routine. The isr is generally not C code at least the entry point is usually special as the processor does not conform to the calling convention for the compiler. The ISR might call C code, but you end up with the mistakes that you made, making calls like printf that should not be in an ISR. hard once in C to keep from trying to write general C code in an isr, rather than the typical get in and get out type of thing.

Ideally your application layer code should never know the interrupt happened, there should be no (hardware based) residuals affecting your program. You may choose to leave something for the application to see like a counter or other shared data which you need to mark as volatile so the application and isr can share it. this is not uncommon to have the isr simply flag that an interrupt happened and the application polls that flag/counter/variable and the handling happens primarily in the application not isr. This way the application can make whatever system calls it wants. So long as the overall bandwidth or performance is met this can and does work as a solution.

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • http://github.com/dwelch67/raspberrypi I just put an example there the other day, blinker05. There is asm that preserves registers then calls a C function, the C function increments a shared/global counter and changes the state of the led. Didnt but could easily have the application monitor the shared variable (icount) and just as easily had the application change the state of the leds based on that shared counter instead of the isr doing it. – old_timer Jun 12 '12 at 20:41
1

Software doesnt recognize the interrupt to be specific, it is microprocessor (INTC) or microcontrollers JOB.

Interrupt routine call is just like normal function call for Main(), the only difference is that main dont know when that routine will be called.

And every interrupt has specific priority and vector address. Once the interrput is received (either software or hardware), depending on interrupt priority, mask values and program flow is diverted to specific vector location associated with that interrupt.

hope it helps.

Kinjal Patel
  • 405
  • 2
  • 7
  • I understood your answer. But I wanted to know when Interrupt occurs how the current task execution gets stopped/paused and the ISR starts executing? – Rasmi Ranjan Nayak Jun 14 '12 at 02:54