FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [January 2015 Threads] traceTASK_SWITCHED_IN/OUT require access to inaccessible variable?Posted by nburkitt on January 24, 2015 Surely I must be missing something obvious, but the documentation for the macros traceTASKSWITCHEDIN and traceTASKSWITCHEDOUT states "At this point pxCurrentTCB contains the handle of the task...", implying that whatever your function wants to know is just a pointer dereference away.
Except that pxCurrentTCB is private to tasks.c. Okay, I can declare it extern in my code, except that its type, struct tskTaskControlBlock (aka TCBt), is also private to tasks.c.
Short of copying the TCBt structure to some place visible to my code, what do people do to make use of these macros?
Thanks!
FreeRTOS V8.1.2
Xilinx Spartan 6
MicroBlaze 8.50a
Xilinx EDK 14.5
traceTASK_SWITCHED_IN/OUT require access to inaccessible variable?Posted by heinbali01 on January 24, 2015 Hi Nick,
No need to say that these structure are being kept private for very good reasons :-)
One of the reasons is: the interfacing with the user (API's) should be perfectly well defined.
If all these data would become public, there would be less freedom to change the kernel code for compatibility reasons.
But I do agree that traceTASKSWITCHEDOUT/IN() pass no information about the tasks being switched in and out.
Tip 1: if traceTASKSWITCHEDOUT/IN are defined as a macro (and not a function), you could refer to whatever is visible at the point were the macro is called, also pxCurrentTCB and "struct tskTaskControlBlock".
Tip 2: Do as little as possible in the trace macro's: you never know which task is calling the macro, what rights it has and how much stack is available.
Tip 3: do not complain if your macro introduces bugs of if you encounter incompatibilities after an upgrade of FreeRTOS :-)
But the best way is maybe: make a proposal of the information (parameters) you would like to see in the macro call?
Regards.
traceTASK_SWITCHED_IN/OUT require access to inaccessible variable?Posted by rtel on January 24, 2015 Just to 2nd everything Hein says here - the most important points being:
pxCurrentTCB is accessible to the traceTASKSWITCHEDOUT/IN macros
because the two are both in the same source file.
If you access the members inside the structure you also accept the
risk that you may have some maintenance to do when you upgrade to a
later FreeRTOS version.
pxCurrentTCB is equal to the tasks handle though, so in the macro you
can use pxCurrentTCB to know which task is being switched in and out
without accessing any of the structures members - which I think is the
purpose in this case.
Regards.
traceTASK_SWITCHED_IN/OUT require access to inaccessible variable?Posted by nburkitt on January 24, 2015 Thanks, guys. I used the method you both mention, but was thinking of it merely as a workaround. Never code on an empty stomach. :-/
Thanks again.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|