Quality RTOS & Embedded Software

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



Posted by Frank Andersen on July 24, 2008

I am trying to use the new trace macros, looking at the trace, it looks to me like task 0 is switched in for every milli second, I guess that task 0 is the IDLE task but why is switch in every milli second? Is it because I use IDLE_SHOULD_YIELD?

Best regards,

Frank Andersen

PS. If anyone has some more examples for the the trace, please post it.


Posted by Richard on July 24, 2008
Sorry for very quick response, I'm just on my way to an appointment....

The idle task is unlikely to be task 0 as it is created when the scheduler is started so there should be more tasks created before it. If you are using V5.0.2 of FreeRTOS.org please make sure that portREMOVE_STATIC_QUALIFIER is not defined anywhere as this could cause problems with task numbers (this will be fixed in the next release). You will see that portREMOVE_STATIC_QUALIFIER is referenced from the top of task.c, so if in doubt you could just remove its usage directly in there.

Here is an example that I used just yesterday to demonstrate task execution patterns:

#define traceTASK_SWITCHED_IN()\
{ \
PORTACLR = 0x0F; \
PORTASET = 0x01 << pxCurrentTCB->uxTCBNumber; \

The first line clears all the digital outputs on port A. The second line sets the digital output in accordance with the number of the task that runs. Putting a logic analyzer or scope on the outputs gives you a clear picture of the task execution and timing.

Hope this helps.



Posted by Frank Andersen on July 24, 2008
Hi Richard,

I used

#define traceTASK_SWICTHED_IN() DebugPort(( int ) pxCurrentTCB->pxTaskTag )

and then I set the pxTaskTag in every Task except the idle task, thats why I think it is the idle task.

DebugPort just outputs to a 8 bit port, I will try using the task number instead.

Best regards,

Frank Andersen


Posted by Frank Andersen on July 25, 2008
Well, it is the IDLE task that is switch in for every mS, and it is because my tick also runs at 1 mS.

Would it be wise to set the tick rate slower?

Best regards,

Frank Andersen


Posted by Dave on July 25, 2008
Having a high tick rate allows greater resolution in timing but also comes with an overhead as you are seeing. The demos come with a high tick rate to test the code and most applications should use a lower rate. 100Hz is common.

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

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

Latest News

Version 10.1.0 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