traceTASK_SWITCHED_IN() ?
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.
traceTASK_SWITCHED_IN() ?
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.
traceTASK_SWITCHED_IN() ?
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
traceTASK_SWITCHED_IN() ?
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
traceTASK_SWITCHED_IN() ?
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.