Quality RTOS & Embedded Software

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


Handling events that are faster than Tick.

Posted by Leethal on September 29, 2012
If I have an event that happens every 100 uSec how do I hadle this. Do I have an interrupt that works seperate from the RTOS that will suspend the RTOS for a period or is there a better way???

RE: Handling events that are faster than Tick.

Posted by MEdwards on September 29, 2012
Yes, for something that fast you are better using traditional interrupts.

RE: Handling events that are faster than Tick.

Posted by Richard Damon on September 29, 2012
In general, this sort of event will be generating an interrupt. In fact, I find that MOST events start off as an interrupt (we want to avoid the case where the program needs to periodically scan around the hardware looking for a flag that has been set).

Once that interrupt occurs, you have two primary choices of how to proceed. The first is to all the work to handle that interrupt inside the interrupt routine. The second is to do the minimum amount of work to get the information about the interrupt, and pass that data to a task, which will finish up the work required to handle the event.

The first case, doing it all in the interrupt, can be appropriate if the work needed to be done is quick, or is very urgent. The big problem with doing this, is that code running in an interrupt will normally be blocking some other interrupts from occurring.

The second case, sending the data to a task, gets around this problem, as the interrupt routine blocks the interrupts for only a short period of time. If the task that it sends the information to is the highest priority task available, then the flow of execution between the two is very close to the same, with primarily a quick trip though the scheduler added.

There are also possible cases in between, where the interrupt does maybe a bit more work, and can perhaps finish processing a lot of cases, and then switches to the task only sometimes (for example, buffering up data and releasing an assembled message buffer).

Which method is best depends a lot on the details of the system. If you can process the event in just a few uSecs, then doing it in the interrupt makes sense. If it is going to take 70uSecs, then switching to a task probably makes sense. (If it takes 99.9 uSec, and switching to a task is too expensive, you need more processor). The middle ground of things like 10 uSec, put you into the case of needing to know what sort of latency your other interrupts can tolerate, and if any other critical interrupts can nest over this one.

[ 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.


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