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] [March 2011 Threads] Interrupt Priority Handling with FreeRTOSPosted by Ivan on March 22, 2011 Hi,
I have been doing code walks through the FreeRTOS on a Renesas RX62N Starters Kit. Everything works great and I am currently up to the point where I am trying to understanding Interrupt Handlers with respect to the RTOS. I am new to RTOS in general and I would like to clarify on the following matter:
When an Interrupt arrives for the MCU, the hardware mechanism will accept the interrupt if the priority set for the interrupt is higher than that of the current interrupt priority level set in the Interrupt Priority Register. That being said, I am wondering how does the mechanism to inform the kernel that an interrupt has arrived works in FreeRTOS?
Is there something like a "portYIELD_FromISR()" kind of mechanism?
Many thanks in advance. Cheers :)
RE: Interrupt Priority Handling with FreeRTOSPosted by Richard on March 23, 2011 “That being said, I am wondering how does the mechanism to inform the kernel that an interrupt has arrived works in FreeRTOS? ” The kernel does not effect how interrupts are processed in the RX port. The MCU just accepts the interrupt as per normal, processes it (maybe nests with other interrupts), then returns to the task level when all interrupt processing is complete. If no yield is required in the interrupt then the interrupt will return to whichever task was running prior to the interrupt being entered. If a yield is required in the interrupt then portYIELD_FROM_ISR() just sets a software interrupt into the pending state, then when the interrupt completes the software interrupt will execute. The software interrupt may change the task that is in the Running state, and therefore return to a task that is not the same as the task that was originally interrupted - therefore a context switch has been performed. The software interrupt is the lowest priority interrupt, so will never mask other interrupts, as is guaranteed to complete last if it gets interrupted by any higher priority interrupts. Regards.
RE: Interrupt Priority Handling with FreeRTOSPosted by Ivan on March 24, 2011 Ah ... I see, that makes it so much clearer now. Thanks loads :)
Big fan of your work! Cheers!
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|