Pumpkin User Forums
  Feature Requests
  Call for Suggestions -- Improved Event Flags

Post New Topic  Post A Reply
profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone! next newest topic | next oldest topic
Author Topic:   Call for Suggestions -- Improved Event Flags
posted October 15, 2002 16:12     Click Here to See the Profile for aek     Edit/Delete Message   Reply w/Quote
Hi Luben.

I think the kernel will actually shrink, and will run faster.

The user will have to do a bit more work to configure the eFlags ... but we'll provided canned routines to do the functionality (any|all|exact bits) that is currently there, so in many cases user's won't have to write their own functions.



posted October 15, 2002 02:12     Click Here to See the Profile for luben     Edit/Delete Message   Reply w/Quote

I think that this is the perfect solution for the event flags - to have a function that tracks the event flags. I don't know how to say it, but this is just what I wished from the event flags from their beginning. One of the reason not to use very often event flags in current SALVO was the limited set of possible logical operation over them. With the user defined function you make event flags extremely powerful and in the same time flexible. Excellent...

This will make possible for example to track pins of the uP, variables, counters,.... everything.

Well, from other side you should keep in mind that this will increase the kernel and maybe it will slow down the performance.

Best regards


posted October 09, 2002 17:27     Click Here to See the Profile for jtemples     Edit/Delete Message   Reply w/Quote
I use event flags almost exclusively for my inter-task communications. My usage paradigm is always signal a single bit, wait on multiple bits. Each of the waited-on bits has an individual meaning; I haven't had any need to assign meaning to combinations of bits. I don't know if that's a common usage scenario for other folks.

In other words, I'm happy with the API as it is now.


posted October 09, 2002 17:12     Click Here to See the Profile for aek     Edit/Delete Message   Reply w/Quote
Hi All.

First, read this: http://www.pumpkininc.com/ubb/Forum7/HTML/000107.html.

Now, the question: What kind of interface would you as users like in terms of signaling the eFlag?

Right now, you can set or clear bits in the eFlag using a mask and an option. You cannot, for example, toggle bits, nor can you do more than a single operation at a time. This is not efficient.

I think it would be much more useful if you could perform multiple operations on an eFlag at once, within a single call to OSSignalEFlag(). E.g. you could clear bits 7-4, toggle bit 3, set bit 2 and clear bits 1-0 based on some other condition. Wouldn't that be neat?

To me, the ideal way to do this is to super-generalize it, in that a call to OSSignalEFlag() would look something like:

OSSignalEFlag(ecbP, MyEFlagSignalingFn());

char MyEFlagSignalingFn(ecbP)

operates on the specified eFlag as you wish. OSSignalEFlag() would call your function, then see if the resultant eFlag should wake an eligible waiting task ...

On the OS_WaitEflag() side, you would also define a function -- this one would look like

OStypeErr MyEFlagWaitingFn(ecbP)

which would simply return TRUE or FALSE based on whether the eFlag is the value you expect it to be for the task to successfully wait the eFlag.

You can have as many of your own different eFlag signaling and waiting functions as you like ... The current eFlag API would be replaced with this ...

So, what do you think?


[This message has been edited by aek (edited October 09, 2002).]


All times are ET

next newest topic | next oldest topic

Administrative Options: Close Topic | Archive/Move | Delete Topic
Post New Topic  Post A Reply
Hop to:

Contact Us | Pumpkin Home Page

2000-2008 Pumpkin, Inc. All Rights Reserved. Pumpkin and the Pumpkin logo, Salvo and the Salvo logo, The RTOS that runs in tiny places, CubeSat Kit and the CubeSat Kit logo are all trademarks of Pumpkin, Inc. All other trademarks are the properties of their respective owners.

Ultimate Bulletin Board 5.46a