Quality RTOS & Embedded Software

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


Function Callback Timers

Posted by Brandon Yates on October 18, 2010
Hello all,

I am running freeRTOS on a cortex m-3. I need a way to implement time-out handling. I figure the easiest way to go about this is create a timer task that checks timer values every 1 second and calls an associated function when they expire. I would also need a small function library for creating, deleting, and modifying timers.
Seeing as this is likely a common problem, and figured I would check to see if there are any open source libraries available to do this sort of thing with freeRTOS. Does any one have any suggestions on how to go about implementing this, or potential problems I may run into?


RE: Function Callback Timers

Posted by MEdwards on October 18, 2010
Can you explain a little more about what you mean by time out handling? I think most of the communication API functions allow a block time to be stated, and return fail if the block time times out before the communication event happened successfully. You could check the return value from the API function and handle the time out there, or do I miss the point?

It sounds like your timers are just execute once timers. If you want periodic timers then look at adding something to the tick hook.

RE: Function Callback Timers

Posted by Brandon Yates on October 18, 2010
I have thought about using a comm API function call with a timeout, but that would result in blocking a thread that I would rather not block.

Here's an example of how I would be using these. I have one thread that turns on a gps receiver. When the gps device is turned on, I would like to start a 1 minute timer. If a gps fix is acquired, I would kill the timer. If the timer expires before a gps fix is acquired, I would like to turn off the gps receiver.

I could block for 1 minute in the thread on a semaphore generated by a gps fix being acquired, and then take action depending on the return value. But this would result in that thread being blocked for a minute when I need it too continue execution.

I am also very memory constrained and need to minimize the number of tasks I use

RE: Function Callback Timers

Posted by Richard Damon on October 19, 2010
Byates, a question comes up, in what thread should the timeout function get called? A running thread can not suddenly be yanked to do this operation, so fundamentally you need a new thread to handle this timeout. This thread could wait on a queue which you send signals on (based on the value sent). The first signal marks that the GPS is started. When the task get that it sets a flag and waits again for 1 minute. If a lock is obtained, you send it a second signal and the task clears the flag. If the task times out, and the flag says you last started, you know that it is time to shut down the receiver.

One thing to help with the memory would be to see if you can use co-routines instead of tasks, which could save memory for task stacks.

RE: Function Callback Timers

Posted by Richard on October 19, 2010
Quoting from several posts:

“When the gps device is turned on, I would like to start a 1 minute timer”

The timing constraints are very course then, which makes it easier.

“in what thread should the timeout function get called? A running thread can not suddenly be yanked to do this operation, so fundamentally you need a new thread to handle this timeout”

I think it depends on the structure of the other tasks I suppose, also, what the task that is using the GPS is doing while no signal is available. If it has no work to do until there is no signal then the problem would not exist, so I assume it has other functionality it must maintain while waiting for the signal.

Presumably it will be checking the signal status before trying to use the GPS data anyway? In which case some status variables could be set from an interrupt to say when the signal was locked (assuming the GPS generates interrupts) if it would take to long to query the GPS device directly. The interrupt could also clear the timer. The task that used the GPS data would then just have to check the status variables. In this case the tick hook could be used for the timer functionality. When the GPS receiver was switched on the timer count down value would be set. The tick hook would decrement the count down value, and set one of the status variables accordingly (timeout condition), or call a function, if the decrement caused the count down value to change from 1 to 0. In all other cases no further action would be taken. Obviously the decrement would only occur if the count down values was greater than 0.

I do have a timer module that allows timers to be created and deleted on the fly, but it is very, very, very (get the idea) old. I might not even be able to find it now. My problem with it is finding an efficient way to process timers. FreeRTOS never walks through a linked list from within an interrupt or while interrupts are disabled, so a linked list of timers that are processed in the tick is against the design philosophy (responsiveness and determinism being the issues). Statically declared/coded timer functionality as described in the paragraph above is less of a problem as simple switch statements, etc. can be used.


[ 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.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo, Nuvoton Cortex-M23 demo & STM32H745 dual core (AMP) demo.

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