Quality RTOS & Embedded Software

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


How should fromISR be used?

Posted by Ozzy Smith on November 27, 2012
After getting my IRQ_Handler working with Timer Interrupt and the OS running correctly, I need to add checks for the other system Interrupt sources, like buttons, I/O, DMA, etc.

Can I call another Handler routine that will do these functions from the IRQ handler using C function calls, or must I use "fromISR" calls to do this.


I get a an interrupt for a button press, and that event requires an action of some type. Do I perform that action within the context of the IRQ or do I wait to return from the IRQ to begin that action? Do I send a message to that task to signal to it that an action needs to take place?

What is the best method?


RE: How should fromISR be used?

Posted by Richard on November 27, 2012
Hi Ozmit,

I am working on a similar design including DMA and buttons etc. I prefer to post messages from the ISR using FromISR and then handle that in task space. The interrupt handlers are virtually empty.

You really want to spend minimal time in interrupt space as the longer you spend the larger the potential latency in processing other interrupts.

The only time you would normally perform processing in ISR context is when you have very low latency processing requirements. Something like a button press is relatively slow and can easily be done in task space - it won't matter if it takes 100usec to get processed or 5msec - the user won't see it. Something like reloading a PCM output register while streaming audio may have a much tighter latency requirement, in which case do the absolute minimum and get out.

If you want to immediately process the results of an interrupt (if your RTOS tick rate is slow compared to your interrupt rate then you don't want to wait for the next RTOS tick otherwise you stand to add an additional whole RTOS tick delay in interrupt latency), you can post the message to the front of the Q (xQueueSendToFrontFromISR) and use the portEND_SWITCHING_ISR (TRUE) macro (or whatever your port uses).

Doing it this way has many advantages (such as message serialization and avoiding data corruption) and it also has the advantage of being able to simulate messages to your tasks without actually having the hardware in place.

Hope that helps

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

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

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

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

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

Cadence Tensilica Cortes

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