Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Safe to call taskYield() in PIC32 ISR?

Posted by Nils Schulte on July 7, 2011
Hello,

Im am confused about the usage of "taskYield()" / "portYIeld()" / "portEND_SWITCHING_ISR" within an Interrupt when using a PIC32 port. Thanks in advance for all the support here!

The "PIC32 FreeRTOS reference manual" states (page 99, v6.0) that one may never use "taskYIELD()" within an ISR, but should use portEND_SWITCHING_ISR. However both functions are defined to the same function portYIELD!

/**
* task. h
*
* Macro for forcing a context switch.
*
* \page taskYIELD taskYIELD
* \ingroup SchedulerControl
*/
#define taskYIELD()portYIELD()

#define portEND_SWITCHING_ISR( xSwitchRequired )if( xSwitchRequired )\
{\
portYIELD();\
}


Also I am having trouble with these function when using within an CAN interrupt handler. My ISR sends messages to a queue and an RX task shall receive them. But after a while the task wating on the queue will not wake up although there are elements in the queue. All works fine without usage of portEND_SWITCHING_ISR. Does somebody have an explanation for this?

void __attribute__((vector(46), interrupt(ipl4), nomips16)) CAN1InterruptHandler(void)
{

char temp=0; //This shall be the CAN data to be received
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;
xQueueSendFromISR(xQueueIDCanRx, &temp, &xHigherPriorityTaskWoken);
/* If sending or receiving necessitates a context switch, then switch now.*/
if( xHigherPriorityTaskWoken )
{
portEND_SWITCHING_ISR(xHigherPriorityTaskWoken);
}
}


Best regards,
Nils

RE: Safe to call taskYield() in PIC32 ISR?

Posted by Richard on July 7, 2011
As a rule, when using FreeRTOS, you should never call a FreeRTOS API function that does not end in "ISR" in an ISR.

It just so happens, that in the case of the PIC32 port, portEND_SWITCHING_ISR() is mapped to portYIELD(). portEND_SWITCHING_ISR() is provided so you can stick to the rule stated above to avoid confusion.

Although in this specific case, on this specific port, it does not matter - on most (nearly all) ports, portYIELD() must not be called directly, so I would advise using the portEND_SWITCHING_ISR() macro provided.

With regards to your CAN ISR - please read the "Interrupt Service Routines" section on the documentation page for that port: http://www.freertos.org/port_PIC32_MIPS_MK4.html , your handler does not appear to be written as per the instructions, or the examples provided.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner