FreeRTOS中的抢占

Question

I am starting to use FreeRTOS and I would like a interrupt to preempt whatever task was about to run and run the task I need to run critically.

Is there a way to do this in FreeRTOS? (Is this achieved through task priority?)

Answer 1

NO! Both the above answers are DANGEROUS.

Do NOT use taskENTER_CRITICAL() or taskEXIT_CRITICAL() inside an ISR - it is unusual to need a critical section in an ISR but if you do then use taskENTER_CRITICAL_FROM_ISR()/taskEXIT_CRITICAL_FROM_ISR() . (possible the AVR32 port is an exception to that rule?)

Do NOT use xTaskResumeFromISR() to synchronise a task with an interrupt. The link already posted to the documentation for that function even says this.

If my understanding of your question is correct you want the ability to have an interrupt unblock a task, and then if that task is the highest priority task in that is able to run, have the interrupt return directly to the unblocked task. If my understanding is right then there is an example of how to do that in an efficient way on the following page: http://www.freertos.org/RTOS_Task_Notification_As_Counting_Semaphore.html

Answer 2

You can use xTaskResumeFromISR to do this.

There is a number of conditions to be met for the yielded task not to be interrupted by other tasks (like it's priority must be high enough) and a number of other conditions to be met to ensure that no interrupt can go un-serviced (like the yielded task must guarantee to be done before the next interrupt)

Answer 3

1. enable preemption:

This is very simple to do.

All the configuration options of FreeRTOS are under "FreeRTOSConfig.h"

#define configUSE_PREEMPTION                    1

You can set this to 1 to use the preemptive RTOS scheduler, or 0 to use the cooperative RTOS scheduler.

Check this link for more info

2. Use critical section inside ISR

void taskENTER_CRITICAL( void );
//action

void taskEXIT_CRITICAL( void );

RTOS wont do anythis extra inside this critical part

ref: here

Answer 4

The short answer would be: Yes, this is achieved through task priority.

The FreeRTOS kernel will consider swapping in any task in ready-state after an ISR has completed so it would preempt the current running task if a higher priority task is now ready.

It should be mentioned that this is really only true if the handler is called through FreeRTOS. On a Cortex-A processor there is a common IRQ entry-point in the IRQ or FIQ exception handler which is most likely handled by FreeRTOS or otherwise by an IRQ dispatcher which is easily wrapped by FreeRTOS, usually by a function in the port-layer called vApplicationIRQHandler().

On a Cortex-M this is not necessarily the case as the vector is usually manipulated by the vendor's MCU API. On a Cortex-M I'd safe-guard against this using portYIELD_FROM_ISR() in the ISR which should be implemented to provide the kernel with an opportunity to perform a context switch.