RTX - Task list

I think it must be possible since uVision does it?

You're vastly underestimating how much more information uVision has about a running program than the CPU running it does. No, just because uVision can do it by no means implies that the code itself can do it. For starters, it's quite extremely unlikely that the names of tasks even exist anywhere in the code memory.

I do not think I'm vastly underestimating anything.

I do not need the string names of the tasks - (almost) everything else I would argue must come from the RTOS.(or at a minimum known by the RTOS - stack size, current stack pointer, tasks state... I'm pretty sure this would just be the context save of any RTOS)

More precisely all I need is a list of all tasks (IDs would be fine)
Of course the CPU knows this as that is the point of an OS.

So can anyone help me with this challenge? Is there any way with the current API to get a list of all 'registered' tasks?
If the API does not provide such a way can anyone think of a cleaver scheduler hack?

Maybe overriding the task create functions? Has anyone ever done this?

Try prying in the sources of RTX, namely in the parts where tasks are created. I am sure you'll find you answer (container) there.

Thanks Tamir. I checked it out and it looks like the OS keeps 2 linked lists (read and delayed tasks in rt_list.c)
I don't see any API to access these lists so I don't think I will use these directly.

Anyway, without a documented feature I think I will find another solution to my problem.

Thanks.

M

I do not need the string names of the tasks - (almost) everything else I would argue must come from the RTOS.(or at a minimum known by the RTOS - stack size, current stack pointer, tasks state... I'm pretty sure this would just be the context save of any RTOS)

So now you're tryign to change the question, to make it fit your earlier claims about the answer. That's not a list of tasks you're now asking about --- that's a compilation of task state data. Yes, that's a totally different kettle of fish.

More precisely all I need is a list of all tasks (IDs would be fine)

And now you're changing it back to the original question.

The only "list of tasks" the OS can give you at run time is a sequence of numbers from 0 to something, because that's all they really are to the code: numbers.

And yet, despite your protests, it appears that's precisely not what you actually want.

I'm not sure I understand your attitude Hans - I'm not attacking you I'm simply looking for advice/help.

If you feel the need to be rude and condescending, please don't bother responding to any of my posts.

I also don't need any of the other context data I was simply pointing out that the data uVision knows about the various tasks (other than the string name) is most probably known by the RTOS.

My question is and has always been simple. I need a list of all "registered" tasks. I never said anything about strings or task names or anything so I do not see why a list of task ids is any less of a list.

The reason is equally simple I want to associate my own custom data with each task but I want this association to be transparent to the all the tasks.

For example I'm thinking of simply using a collection with the task id as the key. When a running tasks calls one of my functions I will check my collection for the task id (os_tsk_self) and if it is not in the collection I will create a new 'object'.

I'm also using a fairly similar concept for a watchdog for each task.

Anyway, I never understood the point of people getting chippy on an internet forum. I don't know you and you don't know me.

My question is and has always been simple. I need a list of all "registered" tasks.

That question is evidently not simple. You're actually making it near-impossibly hard by being excessively vague about what it is you actually mean by a "list of tasks". So far, you've essentially only told people what you did not mean by it.

At run time, task IDs are numbers --- no more, no less. Each task has a different one, and they're bound to be used as array indices already, i.e. they'll be starting at either 0 or 1, and grow sequentially. And that's all you need to know to use them. Yes, that's including the use case you outlined.

Or to turn this around: how come you need such a list made by the software at run time, given that it's your own code that set it up at build time? I.e. you registered all those tasks with the RTOS. How come you need RTOS to tell you which those were?

Do you realize how you come off?

That question is evidently not simple.

Yes it is. Everyone else understood just fine. The answer may not be simple but the question is.

You're actually making it near-impossibly hard by being excessively vague about what it is you actually mean by a "list of tasks".

Nothing vague about a list of task IDs.

I.e. you registered all those tasks with the RTOS. How come you need RTOS to tell you which those were?

No I don't. Maybe you work on small projects with one developer or one company but this claim is not correct in my case.

Please read my entire posts properly next time:
If you feel the need to be rude and condescending, please don't bother responding to any of my posts.

how come you need such a list made by the software at run time, given that it's your own code that set it up at build time

Not necessarily. The OP might be confronted with a situation in which RTX is spawned by a library. And besides, tasks can be created on the fly, at run time - and terminate or not depending on their own logic.