Pumpkin, Inc.

Pumpkin User Forums

Final idea for OS_WaitKey()

Have an idea on how to make Salvo better? Post it here!

Final idea for OS_WaitKey()

Postby luben » Mon Dec 25, 2000 6:16 am

Hello,

After thinking some time about the new possible feature - OS_WaitKey(), I have some new ideas. I found that if something worth in such function - it's the possibility to watch simultaneously several flags. This feature doesn't exist now in Salvo, so adding OS_WaitKey() will increase the power of Salvo. Well, I agree that this is only idea and you could make it much better or modify it somehow to the existing operators.

In fact this is something like more complicated OSWaitBinSem(), watching of several flags in one moment. It has some uniqual characteristics, that are very useful in real programs.

So, my last idea about OS_WaitKey() is:

OS_WaitKey(OSTypeID eID, OSTypeInt8u mask, OSKey behaviour,
OSTypeDelay timeout, label);

And supplementary:
- OSCreateKey(name, value); // creates Key<name>

- OSResetKey(name, mask); // resets some bits to 0 in Key<name>, according to the mask

- OSSetKey(name, mask); // set some bit to 1 in KEY<name> according to the mask

- OSReadKey(name); // read the value of the Key<name>

Now the idea is clear and absolutely in the current style of Salvo:
- when a task is waiting on OS_WaitKey() it waits for (depend on bit behaviour):
a) all bits in mask that are 1 to have corresponding bit in Key with 1 (so called - "key fits the lock") Example - if the mask is 0b11000001 this needs the key to have 0b11xxxxx1 value (x - don't care)
b) if even one bit in the Key becomes 1 and the corresponding bit in the mask is 1 (it's like to run simultaneously several OS_WaitBinSem() functions - if one of this bit becomes 1 the event occures)
c) exactly - waits until mask == Key
d) could be made some other logical function ......

After the event occures (in OS_WaitKey() ) it clears the Key.

The OSResetKey() is needed if you want to reset one flag (if the one "subevent" is not currently existing or expired).

And OSReadKey() is needed in some cases if you want to watch the flags "on the fly", without waiting.

*** By the way, it's good idea if you add to your OS_WaitBinSem() the naturally needed function - OSReadBinSem() - to return the value of the BinSemaphore... in case that you don't want to wait at all, but you need to check the status of the semaphore. Just think about this - you don't have any possibility to watch the value of the any semaphore except the OS_WaitBinSem(), it's just incomplete function (on my oppinion). The same is for the messages - will be good if you can watch the message, without waiting to it - OSReadMsg(). Reading the message will not destroy it. In all langiages are similar construction, for example when you read the keyboard - you can wait key press or you can watch just the status.


You have to agree that such implementation of idea of OS_WaitKey() is absolutely Salvo's style and could be done in the same manner like OS_WaitBinSem(). Even OS_WaitBinSem() is a particular case of this new construction - OS_WaitKey() and they could be called from the same source code.

I gave up from the idea to watch real events (like pin status, flags, etc.). I agree that this will slow down the kernel and in fact it could be very easy made by simple adding of several commands.

Such structure like OS_WaitKey() is hard to be made with the now-moment operators. You have to agree that to make a waiting task for 8 different flags simultaneously in now moment is taugh, right? In fact this 8 bits could merge many other bits inside of them (they could be calculated like AND or OR of much longer logical expressions).

About the lenght of the mask and the key - I think that 8 bits is enough, well, if you allow the user to set/reset different bits and to be able to read the key.

This idea is coming from my own experience when I had to maintaine complicated logical operations over many flags and to take decisions. But you, like creators of Salvo will have the last word and if you don't feel that this is useful - you can deny it (I'll not be angry at all :-)

Regards and Merry Christmas to all that made Salvo (and for others too)
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: Final idea for OS_WaitKey()

Postby luben » Mon Dec 25, 2000 8:27 am

Hello,

Where fits in? You mean - to give some example where such construction could be used right?

The first is one alarm system algorythm:

The alarm is trigger on when:
- tamper opened
- sensor active (system)
- door opened (system armed)

So, the tasks that switch on the alarm will look like

code:
void TASK_Alarm()
{
for(;;)
{

OS_WaitFlag(flag_ALARM, OSNO_TIMEOUT, mask_tamp_sens_door, Behaviour_single_bit, label);

SIREN = ON;

OS_WaitBinSem(stop_ALARM, time_5min, label);
SIREN = OFF;

...
}
}


it will wait until door sensor or sensor or tamper bits in the flag_ALARM becomes 1.

In other tasks you can control the setting and resetting of these bits.

OS_WaitFlag() is very sutable if you have to control single process that depends on many other logical events (every event could be transformed to flags and visa versa).

Or you can improove now the example in your manual when you start rocket:
Now you can watch 8 flags and if all of them are 1 you can start the rocket. Now you can add in this example:
- flag fuel OK
- external prohibit flag
- local prohibit flag
- flag start the rocket
- flag - auto check of the system OK
- and so on

Now you can see two examples - in the first of them you see that one event appears if one of the multiple flags becomes 1 (alarm system and input sensors)

In the second case you see how you can control a process that should be stopeed untill all conditions are OK - checks until all flags are OK

We should immagine some more informative names for behaviour cases - like IF_ALL, IF_SINGLE, IF_EXACTLY, IF_NOT_EXACTLY, IF_CHANGE, IF_NOT_CHANGE... etc.

the idea of "change" is - when you make SET/RESET flag bits and if there is a change in the value of the flag - doesn't matter to 1 or to 0 - event appears. I think that this si sill possible with current Salvo operations

Regards
Luben

[This message has been edited by aek (edited December 26, 2000).]

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: Final idea for OS_WaitKey()

Postby aek » Mon Dec 25, 2000 10:59 am

This looks pretty good -- but where does OSSignalKey() fit in, and what is the proposed syntax? I'm not sure if you forgot it ...

Also, I'd prefer to call it OSCreate/Signal/_WaitFlag(), as people will recognize it as an "event flag" service -- what do you think of that? You can always define some macros that use the word "key" instead of "flag".

And yes, we do need some event "readers" like OSReadBinSem().

I think this discussion has got us pretty close to implementing this new event type ... and we appreciate your input.

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Final idea for OS_WaitKey()

Postby luben » Mon Dec 25, 2000 11:25 am

Hi,

key word "flag" is OK. I think it better fits to the idea. It's just checking multiple flags simultaneously.

It's just improoved version of OS_WaitBinSem(), with much more options.

Regards
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: Final idea for OS_WaitKey()

Postby aek » Fri Jan 12, 2001 2:36 am

If we implemented the following:

code:
OSCreateKey(keyID, value);
OSResetKey(keyID, mask);
OSRtnKey(keyID);
OSSignalKey(keyID, mask);
OS_WaitKey(keyID, mask, operation, timeout, label);

with multiple tasks waiting the key in a priority queue like the rest of Salvo's event services, would this even be useful?

I.e. if

code:
OSCreateTask(TaskA, TASKA, 5);
OSCreateTask(TaskB, TASKB, 7);

void TaskA ( void ) {
for (;;) {
...
OS_WaitKey(KEY1, 0x70, ALL, label);
..
}
}

void TaskB ( void ) {
for (;;) {
...
OS_WaitKey(KEY1, 0x83, ANY, label);
..
}
}


TaskB() won't run even if KEY1 is 0x81, because it has a lower priority than TaskA.

It think that with the priority queue scheme, this sort of event isn't too useful, because you cannot "share" the key bits among multiple tasks simultaneously ... but can you propose a situation where it's useful?

It seems to me that the more conventional definition of event flags, where tasks and ISR can set and reset flag bits, and tasks can wait flag bits, and "all tasks waiting for a state are simultaneously activated when the flag is changed to this state." [Thomas Wagner, CTask], is more useful.

So I'm wondering if it's worth having the key events described above, and also the event flags that Wagner describes, or just event flags. Event flags are obviously more powerful, but not as easy to implement in Salvo.

So, obviously we'd all like event flags, but that isn't coming in v2.2. But do we want keys as Luben has described? Are they useful enough to justify the fact that simultaneously waiting multiple tasks on a key is pointless?

In other words, if we ever do add conventional event flags, we'll have to treat keys as "the light version of flags."

[This message has been edited by aek (edited January 12, 2001).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Final idea for OS_WaitKey()

Postby luben » Fri Jan 12, 2001 9:23 am

Hello,

I agree with you that keys are somehow outside the Salvo's style in the current definition. And in the example you gave they will only create problems and hidden "dead locks".

From other side you have to agree that will be great to watch several flags in one moment simultaneously. Just imagine that your OS_WaitBinSem() can control not one flag, but 2 or 3 flags - this could save you a lot of headaches from creating complicated constructions. Of course it's possible just to add more events and to make more complicated task that will signal them. And you can add a new flag, that will be signalled only if 2 other flags are signalled simultaneously.

I agree that with the current commands of Salvo is possible to control multiple flags simultaneously on the price of creating new events and more complicated signaling of them.

Maybe the idea of the OSWaitKey() needs some time to "ripe" - It's obviously that in the current moment there is something "unclear" and outside from Salvo's style. But we have to keep the target - "Something like OS_WaitBinSem() that can watch several flags or events simultaneously.

By the way, the interpreting of your example for OS_WaitKey()is not very correct. You said that if one task is waiting for "some" bits of key and other for "any" bits - the task with "some" bits will never run. That's true if they have different priorities ("any" has higher priority) and OSSignalKey() is issued not from ISR).
The same interpretation could be made for OS_WaitBinSem() - if two tasks are waiting for the same BinSem and one has higher priority and OSSignalBinSem is made from the task level there is no way one of the task to receive the control (deadlock if there is no timeout). Like:

code:
OSCreateTask(Task1,ID1,Prioprity_HIGH);
OSCreateTask(Task2,ID2,Prioprity_LOW);
OSCreateBinSem(Some_FLAG,0);

void Task1(void)
{
for (;;)
{
OS_WaitBinSem(Some_FLAG);
..... do something
}
}


void Task2(void)
{
for (;;)
{
..... do something other
OS_WaitBinSem(Some_FLAG);
..... do something other
}
}



It is impossible for Task2 to receive the control until Task1 has higher priority. Therefore, from one example it's impossibe to say that one construction has sense or no sense, at least from the last example OS_WaitBinSem() sounds silly. I mean, until the style of writing C programs is not tunned to the Salvo style some construction of Salvo could look silly. And using OS_WaitKey() will give some new "style" characteristics for Salvo.

The same is with the OS_waitKey() construction. It has some special characteristics and if I don't take care of them, if I don't keep some "Key" style when writing my C program - it has no sense. Maybe I have to write some examples that will show some fatures of OS_WaitKey(), that are difficult to be made with current function of Salvo. The most important moment is to understand the "spirit" of such construction like OS_WaitKey() - to wait simultaneously for multiple events - you have to agree that this is impossible at now moment with Salvo, without adding additional flags and complicated construction for signaling these events.

So, what I should do is to give you some examples that will clearly show the best sides of the OS_WaitKey(), something that is hard to be made with current event support in Salvo. It's my fault that I didn't write such examples from the beginning.

What can I say right now is that the action options of OS_WaitKey() change dramatically the style of construction. For example if option "any" is used - such construction don't fit for multiple tasks waiting the same key - it's useful when one task waits for multiple events, signaled from many other tasks (one recipient and many transmitters). In your example you just "went out" of the OS_WaitKey "style".

Options like "exactly" and "all bits of the mask" are useful when multiple recepients receive flags from multiple transmitters.

And the biggets power of the OS_waitKey is that you can accumulate into the key information - one task sets one bit, after some time other task - other bit. And in one moment one thirth task recognized its event
and runs. It's possible that after Task1 set one bit in the KEY it "changes its mind" and reset it again, before the target recognize event.

But all this functionality could be obtained only if the user keeps the Salvo style, if he understands the "spirit" of different constructions and uses them in right way. Using OS_WaitKey() and it option keys in wrong way will affect of creating "dead locks" or sensless behaviour (like in example you gave).

So, what I have to do is to write some examples that illustrate the style and the "spirit" of OS_WaitKey(). It's just like "SWITCH" construction in C. It could be made with many "IF", but it's more convenient and clear to use SWITCH instead of many IF (this is style of programming). Or you can make loops not with "FOR" but with GOTO and IF, but this is out of the style of C.

Regards
Luben

[This message has been edited by aek (edited January 12, 2001).]

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: Final idea for OS_WaitKey()

Postby luben » Fri Jan 12, 2001 9:37 am

Hello,

Maybe we should think more about OS_WaitKey options keys "all", "single","mask", etc. Because they change the way of reacting and what is more important - the style of OS_WaitKey(). In fact OS_WaitKey when waits for exactly bit combination is just different style construction from when waiting for "any" bits. I think that under OS_WaitKEy are several different constructions that are switched from option keys.

And we have to define clearly the boudary of using the OS_WaitKey() with different option keys. Your examples just showed how silly looks OS_WaitKey() if it is used outside this boudary (because we never spoke about it). It's just like to devide on zero - the whole mathematic looks silly and sensless.

Regards
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: Final idea for OS_WaitKey()

Postby aek » Fri Jan 12, 2001 9:48 am

I'm currently proposing three types of OS_WaitKey() operations -- OSKEY_EQUAL (XOR), OSKEY_ALL (AND), OSKEY_ANY (OR).

[This message has been edited by aek (edited January 12, 2001).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Final idea for OS_WaitKey()

Postby aek » Fri Jan 12, 2001 9:56 am

Re:

quote:
By the way, the interpreting of your example for OS_WaitKey()is not very correct. You said that if one task is waiting for "some" bits of key and other for "any" bits - the task with "some" bits will never run. That's true if they have different priorities ("any" has higher priority) and OSSignalKey() is issued not from ISR).
The same interpretation could be made for OS_WaitBinSem() - if two tasks are waiting for the same BinSem and one has higher priority and OSSignalBinSem is made from the task level there is no way one of the task to receive the control (deadlock if there is no timeout). Like:

I'm not sure I understand your criticism -- the point I'm making is that when looking at the code, one would think that Task2 would run as soon as KEY1 becomes any one of these values: 0x01, 0x02, 0x03, 0x80, 0x81, 0x82, 0x83. But even if KEY1 is one of those values, Task2 is blocked from running because Task 1 (whose condition of any one of the bits x111xxxx has not been met) has a higher priority.

Also, note that Task1 is waiting on key bits x111xxxx, and Task2 is waiting on key bits 1xxxxx11, which are mutually exclusive. Perhaps you overlooked that.

Re:

quote:
Maybe the idea of the OSWaitKey() needs some time to "ripe" - It's obviously that in the current moment there is something "unclear" and outside from Salvo's style. But we have to keep the target - "Something like OS_WaitBinSem() that can watch several flags or events simultaneously.

The implementation I suggested below can do exactly this, but only with a single task waiting a single key event at a time. You can certainly write your Salvo code with OS_WaitKey() to look like multiple tasks are waiting on the same key with different conditions, but the fact is that only the highest-priority one will run when its condition is met.

My concern is whether this restriction is acceptable and OS_WaitKey() is useful.

[This message has been edited by aek (edited January 12, 2001).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Final idea for OS_WaitKey()

Postby aek » Fri Jan 12, 2001 10:00 am

Perhaps I can put it another way: With my proposed key architecture, one could do the following:

code:
void Task3 ( void ) {
for (;;) {
...
OS_WaitKey(KEY2, 0xF0, ANY, label);
...
OS_WaitKey(KEY3, 0x02, ALL, label);
...
OS_WaitKey(KEY3, 0x82, ALL, label);
...
}
}

[This message has been edited by aek (edited January 12, 2001).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Next

Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 1 guest