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.