Quality RTOS & Embedded Software

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


Porting Problem: System stack vs Task stacks

Posted by pippopappo0 on February 20, 2014

Hello, I'm working on a porting and my embrional work seems ok: several tasks are scheduled and I'm able also re-schedule (through TaskYIELD). At moment I don't use queues or ISRs.

In the current implementation I have only one Irq (the Tick ones) so that the context is saved into Task stacks.

Is it acceptable to use for all the other ISRs (CAN, SPI,...) the same handling?

I have a schema like this: irq source --> ISR handler (for all irqs) --> call to specific handler

The ISR handler entry point is unique for the system: when a irq exception is arised the main handler is called. After the context store into the stack, the irq handler (the one relative to the exception) is called.

Is it important/mandatory differentiate the handling for common irqs and tasks?

Please help me.

Regards, Pippo

Porting Problem: System stack vs Task stacks

Posted by richard_damon on February 20, 2014

You don't give the processor type in your question, which is very important in discussing how to write an ISR, as that is VERY processor specific.

In some ports of FreeRTOS, ISRs use the task stack, this is simple, but requires you to have extra space in every tasks stack for the most stack space that ISRs might use.

In other ports, some common code is invoked on entry to an ISR, and it can switch over to have the ISRs use their own stack. (Some processors even do this automatically). This method (if not directly supported by the hardware) is somewhat more complicated, but saves space.

It is important to write your ISR in accordance to the documentation for the port you are using, which will be different than how you write normal task code (which for the most part will be port independent).

Porting Problem: System stack vs Task stacks

Posted by rtel on February 20, 2014

Just to add to Richard Damon's answer - generally newer ports have separate interrupt stacks because they are on more powerful devices and support interrupt nesting. Interrupt nesting requiring more stack, which you don't want to have to allocate to each task, unless RAM consumption is not an issue.


Porting Problem: System stack vs Task stacks

Posted by pippopappo0 on February 20, 2014

I got!!

I will come back soon...

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

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

Latest News

Version 10.1.0 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.


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


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