Wishing for task functions taking a single parameter

[DHenry]

Nevermind, I think.

Without registers or a stack being part of a tasks context, I don't think there's a way for a task using shared code to refer to its parameter again.

If I can tolerate the overhead, I suppose I could have task derive its CCB address by calculating its task index (relative to others) from its TCB address (a la, OStID) each time the task is resumed.

--Dan Henry

[aek]

Hi Dan.

quote:

---

Without registers or a stack being part of a tasks context, I don't think there's a way for a task using shared code to refer to its parameter again.

---

For the general case, this is entirely true.

However, for the specific case where you know that the parameter(s) passed to the task are done so in registers, you may be able to pull this off. I haven't tried it, though.

Just thinking off the top of my head, this ought to work trivially the first time the task runs (since the entry point is a "conventional" one). Exactly what happens when the task is resumed at a later time is not so clear, nor is it clear as to what one would pass at the call-by-function in OSSched().

Perhaps a more robust alternative would be to provide an extra field in a task's tcb -- a void pointer which is passed to OSCreateTask(), as other OS's do. This "tcb extension" would be very useful, as you can imagine ... but consumes a pointer per tcb, regardless of whether it's used or not ...

quote:

---

If I can tolerate the overhead, I suppose I could have task derive its CCB address by calculating its task index (relative to others) from its TCB address (a la, OStID) each time the task is resumed.

---

Take a look at the source code in demod1 in the PIC distribution. There, OStID() is used on-the-fly to figure out which task "we're in".

BTW, OStID() is a pretty inefficient function. If you have suggestions as to how to improve the "detect which task I am" function, pls let me know.

Regards, and Happy Holidays.

------------------

[DHenry]

It would be nice if a task function could take one parameter, the value of which would be specified in OSCreateTask's parameter list. Other OS's (ThreadX and Nucleus Plus are the more recent ones I've used that allow this) usually allow a void pointer for the most flexibility.

As an example of its usefulness, I have a Salvo51 (beta) project that has 6 communication channels, each of which has an RPC client task and an RPC server task associated with the channel. These 6 client tasks and 6 server tasks are identical and my intent is to "share" the client and server task function code. Doing this requires that all the individual channel specifics (e.g., buffer pointers, BINSEM pointers, etc.) be contained in 6 Channel Control Blocks (CCB's). It would be nice if I could pass the CCB address to the task at initialization time.

My workaround with Salvo beta (I hope, since I haven't tried it yet) is to use the OSDONT_START_TASK option for these 12 tasks, and somehow start them up in a fixed sequence so they can programmatically derive which (the next) CCB to use thereafter. I could be "missing a trick" of some more obvious way to do this, however.

--Dan Henry

[DHenry]

Hi Andrew.

FYI, I'll proceed with the tID tcb extension approach, since that appears to be the most likely to make it into a subsequent source release as a configuration option (if at all, as opposed to the void pointer, which would be less likely). It will accomplish what I need and I won't be straying too far off course. I'll even use the names you've provided! :-)

Regards,

--Dan Henry

[DHenry]

Hi Andrew.

Thanks for your thoughts.

quote:

---

Perhaps a more robust alternative would be to provide an extra field in a task's tcb -- a void pointer which is passed to OSCreateTask(), as other OS's do. This "tcb extension" would be very useful, as you can imagine ... but consumes a pointer per tcb, regardless of whether it's used or not ...

---

I had thought about the "tcb extension" method and this is one of two alternatives I'll choose from. The other alternative for my specific case, since there are two tasks associated with each CCB, is to store these task's tcb pointers in their CCB and then do something like OStID(), but sort of in reverse. That is, when the task runs, rather than searching through 20-some tcb's, it would search through 6 CCB's to find its matching tcb pointer. I'm almost certain I'll opt for the "tcb extension" (that's the beauty of having source code!), since as you might guess, this project isn't an internal RAM only type of project, so I can afford the extra tcb size.

quote:

---

BTW, OStID() is a pretty inefficient function. If you have suggestions as to how to improve the "detect which task I am" function, pls let me know.

---

What I did very recently for ThreadX, was to add a taskID member to the kernel's TCB structure and modify the dispatcher to store the dispatched-to task's taskID from its TCB into a global. This was extremely efficient, since it is performed when all the required data is ready at hand.

Regards,

--Dan Henry

[aek]

Hi Dan.

quote:

---

What I did very recently for ThreadX, was to add a taskID member to the kernel's TCB structure and modify the dispatcher to store the dispatched-to task's taskID from its TCB into a global. This was extremely efficient, since it is performed when all the required data is ready at hand.

---

Not a problem when you have lots of external RAM to play with. Not really a viable option on something as RAM-limited as a PIC, of course.

I think I can add a couple of "tcb extension" configuration options to the Salvo source code fairly easily, and then source code users could take advantage of them. Of course for a tID stored in the tcb, OSSched() would change (very slightly), we could easily incorporate a global OScTID, and OStID() would just be a macro tcbP->tID.

quote:

---

The other alternative for my specific case, since there are two tasks associated with each CCB, is to store these task's tcb pointers in their CCB and then do something like OStID(), but sort of in reverse.

---

One big advantage you have is that the number of CCBs in your application is fixed -- therefore your "reverse lookup function" can be a simple switch() or be table/array-based. Salvo's OStID() has to be more flexible, since the number of tasks varies. I suspect that for your application a tcb extension will be smaller, both ROM and RAM-wise.

BTW, if you beat me to it in terms of implementing the tID tcb extension, note that there are no OSLOC_XYZ issues to worry about. Just add the tID to the tcb struct, etc. I mention this because I suspect there are OSLOC_XYZ issues revolving around the void pointer tcb extension -- I haven't worked them out yet.

quote:

---

Thanks for your thoughts.

---

Always a pleasure.

------------------

[tbims23822]

www.drop-shopping.com is a premium website for cheap air jordans shoes and other more really nike air jordan shoes.We have varity of cheap air jordan shoes available for wholesale.Cheap China wholesale shoes including cheap Nike shoes and cheap jordan shoes,nike sneakers,nike sneakers discount,air jordan sneakers,air force sneakers.We supply nike sneakers,jordan sneakers,air jordan sneakers,air force sneakers wholesale.You can buy very cheap jordans shoes including cheap women shoes,cheap nike shoes,cheap running shoes from us.