FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [May 2009 Threads] Interrpts in FreeRTOSPosted by Austin Salgat on 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?
RE: Interrpts in FreeRTOSPosted by sotd on 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.
RE: Interrpts in FreeRTOSPosted by Austin Salgat on 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?
RE: Interrpts in FreeRTOSPosted by dave m on 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")
RE: Interrpts in FreeRTOSPosted by Austin Salgat on 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?
RE: Interrpts in FreeRTOSPosted by Toan Pham on June 3, 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|