traceTASK_SWITCHED_IN() ?

Kernel
1

frankandersen wrote on Thursday, July 24, 2008:

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.

2

rtel wrote on Thursday, 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.

Regards.

3

frankandersen wrote on Thursday, 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

4

frankandersen wrote on Friday, 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

5

davedoors wrote on Friday, 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.