Surely I must be missing something obvious, but the documentation for the macros traceTASK_SWITCHED_IN and traceTASK_SWITCHED_OUT 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 TCB_t), is also private to tasks.c.
Short of copying the TCB_t structure to some place visible to my code, what do people do to make use of these macros?
Thanks!
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 traceTASK_SWITCHED_OUT/IN() pass no information about the tasks being switched in and out.
Tip 1: if traceTASK_SWITCHED_OUT/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?
Just to 2nd everything Hein says here - the most important points being:
pxCurrentTCB is accessible to the traceTASK_SWITCHED_OUT/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.