Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

What happens if a isr is too long.

Posted by Louis Everett on May 4, 2012
Hello, I am using FreeRTOS on a PIC32. I have an ISR that "I think" works fine. It has an interrupt priority above the maximum set for the RTOS and disables interrupts on entry, enables on exit. I therefore believe it can be written in C with no wrapper.

In the documentation I read that the ISR should be kept as short as possible. I understand and I am doing that.

However, what if I didn't? What will happen if the ISR gets too long. Suppose it takes longer than the RTOS tick. Since interrupts are disabled, the tick cannot stop it can it? Will the scheduler simply wait until the ISR finishes or will there be some nasty consequence?

I understand this is a stupid question because one would never have an ISR that long but I'm just trying to understand how the RTOS functions.

Thanks.

RE: What happens if a isr is too long.

Posted by Nathan Wiebe on May 4, 2012
Even a short ISR has the possibility of being in-process when other ISRs become signalled. What happens in a nested interrupt controller is that lower priority (or same priority) interrupts set a hardware flag in the processor that remains set until the you service that particular interrupt. If the tick timer fires, it will just run that ISR when yours is done. The same is true of an ISR that is within the acceptable range to make kernel calls - the tick ISR has to wait. If, on the other hand, your higher priority interrupt fires while the MCU is in the tick ISR, it will jump into yours and come back to the tick ISR later. If your ISR is too slow, then it will just mean other interrupts have bad latency (time from event to ISR action). Your worst case latency on a given ISR is the sum of the worst case run times of the longest ISR in each priority level you are using. In the case of the tick, you would have to have a really slow ISR to overlap two ticks events, thus potentially dropping a tick and throwing out the OS's delays.

RE: What happens if a isr is too long.

Posted by Richard Damon on May 4, 2012
An ISR taking too long won't "break" the RTOS in the sense of it crashing or something like that. It may well "break" your program in that it no longer meets your real time requirements. Interrupts taking so long that you might miss a timer tick interrupt will cause your program's sense of time to be disturbed, more time has really passed than the program knows about.

Interrupts, by their nature are limited in their flexability to schedule their control routines, They may have a nesting, but they can't "defer" and then resume like a task. Tasks on the other hand are very flexible in execution control.

When NOT using an OS, the ISR needs to do everything needed to service the device, as it has no other way to get something to execute. When using an OS that isn't an RTOS, it might be able to hand off "low priority" operations to a task, but the hallmark of a RTOS is that you can setup a "real time" task to get high priority work done on time.
With an RTOS, you typically do very little in the ISR, normally not more than (maybe) grabbing the data and clearing the interrupt, and any more complicated work is left for a task. Think of it as the ISR handles things that need to be done in microseconds, while the task handles stuff that is more on the order of milliseconds, or so. There isn't THAT much of a cost in time to transition to the task to process, as if that task is the highest priority available, it should run as soon as the ISR exits.

For this to work this way, the Interrupt should NOT be "above the max set for FreeRTOS", as such an interrupt WILL need to interact with FreeRTOS. The only real reason I can think of to have an interrupt above the FreeRTOS max level is something that handles activity that REALLY needs microsecond level response or you get failure, so the interrupt can't be temporarily masked for some FreeRTOS operations in critical sections. FreeRTOS has been designed with the goal of these periods being as short as possible (and of a knowable limited length). Having this type of routine around normally requires very definite care and planning.


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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists