posted October 15, 2002 16:12            

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            

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.

posted October 09, 2002 17:12            

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:

code:

---

OSSignalEFlag(ecbP, MyEFlagSignalingFn());

---

code:

---

char MyEFlagSignalingFn(ecbP)

---

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

code:

---

OStypeErr MyEFlagWaitingFn(ecbP)

---

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?

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