Interrpts in FreeRTOS

salgat wrote on Sunday, May 24, 2009:

I’m new to embedded OSs and was curious how interrupts work in FreeRTOS. For example, when I receive a message via the UART peripheral and an interrupt occurs, how do I tell FreeRTOS what task to execute to handle that?

sotd wrote on Sunday, May 24, 2009:

Every demo comes with example interrupt to copy. Every demo document page on the web site has a writing an interrupt section.

salgat wrote on Sunday, May 24, 2009:

I went through my demo, everything worked great, and I read through the website but have not found a page devoted to explaining how interrupts work as far as starting up a specific task. Can you be more specific as to where I can find this?

spacewrench wrote on Sunday, May 24, 2009:

You didn’t post your platform information (at least, not in this thread) so I can’t be more specific, but:

In FreeRTOS, you frequently set up an ordinary task (maybe with a high priority) to handle interrupts.  This task spends most of its time sleeping while waiting for a semaphore to be tickled.  When an interrupt occurs, the low-level ISR does any work that must happen immediately and then tickles the semaphore.  The task wakes up and does whatever else is necessary.

In my code, I have the ISR disable the interrupt at issue, and then the interrupt-handling task re-enables it when everything has been taken care of.  I think this is a common way of doing things.

So, to directly answer your question: you don’t have to tell FreeRTOS anything about which task goes with which interrupt.  You just set up a semaphore, and have one task that sleeps on it, and an ISR that tickles it.  (You could have multiple ticklers if you want, and maybe even multiple sleepers.)  There’s nothing special about the ISR-to-interrupt-handler communication that’s any different from any other task-to-task communication.  (Except, possibly, that certain FreeRTOS functions can’t be called from the ISR.  You can only call functions whose names end in “_fromISR”)

salgat wrote on Sunday, May 24, 2009:

This is for the AVR. So what you are saying is that I setup an ISR like I’d usually do without an OS, disable all interrupts, for the UART example do a quick read and copy to an array, and then have a high priority task that will handle the newly modified array after the ISR is completed, correct?

tpham3783 wrote on Wednesday, June 03, 2009:

you’re not alone,

setting up interrupts in free rtos is a little different than the AVR.

There’s a convention in avrs.  All Interrupt handlers start with name_vect (ref.http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html).

in free tos it is different.  However, i found a niffy library that helps in terms of doing anything on the ARM (lib_AT91SAM7S64.h) ***google it*****
Pretty much, alot of stand routines of setting up the mcu is reference in that API.