Hi,

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.

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.

Regards.

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

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

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.