The FreeRTOS kernel is now an MIT licensed AWS open source project, and these pages are being updated accordingly.

Quality RTOS & Embedded Software About   Contact   Support   FAQ   Download Menu      Quick Start Supported MCUs PDF Books Trace Tools Ecosystem Quick Start Guide Support Forum ⇓ Download Source ⇓ FreeRTOS+ Ecosystem  FreeRTOS+TCP:  Thread safe TCP/IP stack  SafeRTOS:  TUV certified RTOS  OpenRTOS:  Commercial Licensed RTOS  Fail Safe File System:  Ensures data integrity  FreeRTOS BSPs:  3rd party driver packages  Trace & Visualisation:  Tracealyzer for FreeRTOS  CLI:  Command line interface  WolfSSL SSL / TLS:  Networking security protocols  RTOS Training:  Delivered online or on-site  IO:  read(), write(), ioctl() interface FreeRTOS+ Lab Projects  FreeRTOS+POSIX:  POSIX threading API  FreeRTOS+FAT:  Thread aware file system Hint: Use the tree menu to navigate groups of related pages   Software Timers [More about software timers...] Configuring an application to use software timers To make the FreeRTOS software timer API available in an application, simply: Add the FreeRTOS/Source/timers.c source file to your project, and Define the constants detailed in the table below in the applications FreeRTOSConfig.h header file. Constant Description configUSE_TIMERS Set to 1 to include timer functionality. The timer service task will be automatically created as the RTOS scheduler starts when configUSE_TIMERS is set to 1. configTIMER_TASK_PRIORITY Sets the priority of the timer service task. Like all tasks, the timer service task can run at any priority between 0 and ( configMAX_PRIORITIES - 1 ). This value needs to be chosen carefully to meet the requirements of the application. For example, if the timer service task is made the highest priority task in the system, then commands sent to the timer service task (when a timer API function is called) and expired timers will both get processed immediately. Conversely, if the timer service task is given a low priority, then commands sent to the timer service task and expired timers will not be processed until the timer service task is the highest priority task that is able to run. It is worth noting here however, that timer expiry times are calculated relative to when a command is sent, and not relative to when a command is processed. configTIMER_QUEUE_LENGTH This sets the maximum number of unprocessed commands that the timer command queue can hold at any one time. Reasons the timer command queue might fill up include: Making multiple timer API function calls before the RTOS scheduler has been started, and therefore before the timer service task has been created. Making multiple (interrupt safe) timer API function calls from an interrupt service routine (ISR). Making multiple timer API function calls from a task that has a priority above that of the timer service task. configTIMER_TASK_STACK_DEPTH Sets the size of the stack (in words, not bytes) allocated to the timer service task. Timer callback functions execute in the context of the timer service task. The stack requirement of the timer service task therefore depends on the stack requirements of the timer callback functions. [ 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. Careers FreeRTOS and other embedded software careers at AWS. FreeRTOS Partners