3

Before using FreeRTOS on our PIC32MX, we were able to handle interrupts by simply using an ISR like:

void __ISR(_INTERRUPT_1_VECTOR, ipl7auto) {
    // Handle interrupt here
}

But ever since introducing us to FreeRTOS, my instructor has had us use an assembly wrapper to handle the interrupt. We use an attribute to bind the interrupt vector to the function that we want to handle the interrupt, then use some assembly to save context and what not like this:

void __attribute__((interrupt(ipl5), vector (_EXTERNAL_2_VECTOR))) vEXT2InterruptWrapper (void);

Why is it that we need to do this in FreeRTOS?

Matt Hintzke
  • 7,744
  • 16
  • 55
  • 113
  • Style, really...some people prefer assembly ISRs for historic or toolchain compatibility reasons. – nneonneo May 07 '14 at 22:56
  • 1
    Well, when using a preemptive RTOS, the interrupt-handlers commonly need to exit via the OS so that if they have signaled a semaphore or event, any thread/s waiting on it can be made ready 'immediately'. This requires detecting when the interrupt-return exits the top level of interrupt and returning to the RTOS kernel instead of the interrupted thread. That needs some twiddling about and assembler is required. Such stuff is not required if there is no preemptive RTOS. – Martin James May 09 '14 at 11:14
  • In fact, I'll make that an answer, since the other one is somewhat lacking. – Martin James May 09 '14 at 11:20

2 Answers2

3

__ISR is just a preprocessor macro. It will be expanded out to whatever is required for the compiler / linker to know that you wish for that function to be an ISR.

It's likely that the macro automatically does whatever assembly-level things (like saving register state) are necessary, in order for you to go on and process the interrupt from C language.

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
  • that makes sense, but still doesn't explain why it is needed when implementing an ISR in FreeRTOS. That is what I am trying to figure out – Matt Hintzke May 08 '14 at 20:26
2

Well, when using a preemptive RTOS, the interrupt-handlers commonly need to exit via the OS so that if they have signaled a semaphore or event, any thread/s waiting on it can be made ready 'immediately'. This requires detecting when the interrupt-return exits the top level of interrupt and returning to the RTOS kernel instead of the interrupted thread. That needs some twiddling about and assembler is required. Such stuff is not required if there is no preemptive RTOS.

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • in general ok, yes. Can you provide some more real explanation, e.g. pointer inside the FreeRTOS source forge source code repository and explanation of what does the "__attribute__(interrupt" evaluate to (when it leaves the preprocessor and before it gets translated to assembly language)? I have some experience with embedded C and ARM assembly language development and with RTOS in general but I did not find your answer useful in context of FreeRTOS (what OP asks about) – xmojmr May 10 '14 at 15:31