Hello Richard,

Is there a way to dump all task control block info?
It's pretty easy to find pxCurrentTCB - but what about for all of the tasks that are running in the system?

Thanks!
John W.

Have you seen function vTaskList in tasks.c?

If you look through the ready lists, pxDelayedTaskList, pxOverflowDelayedTaskList, xTasksWaitingTermination and xSuspendedTaskList then you have every task in the system. The problem is how to do this without having interrupts suspended for the process.

I have a uart task that sends this information on the rs232 when I enter ? in terminal.

Yes, I have seen that.

I'm asking for the task control blocks of each task - what you're doing would bring my system to a crawl. I can barely run vTaskList() with a periodic update without making my system almost
halt.

My question is:

Can you dump tcb (task control block) info. for each task in the system? (without the exhaustive
list search?)

Regards,
John

There is no single point of reference that will give you all the TCB's in a system. A TCB will always be referenced from exactly one of the 'state' lists (blocked list, suspended list, etc), so the only way of finding all of them is to go through all the queues as per vTaskList(). You then have a problem if the scheduler is still running while you do it as the list contents is very dynamic.

You could allocate an array of pointers to TCB's, then each time you call xTaskCreate, place a reference to the created TCB in the next array index. This would give you a simple static way of accessing each that could still be accessed with the scheduler running. You would have to be careful when deleting a task however to ensure the array position pointing to that tasks TCB was marked as empty (set to null?).

Actually, this mechanism could be implemented at the application level if you wanted, rather than in the kernel code. You would just need to keep tabs of all the task handles returned by the handle parameter of the call to xTaskCreate().

Regards.

OK Richard,

I'll try your suggestions.

Thanks,
John W.