Pumpkin, Inc.

Pumpkin User Forums

OS_Skip() and second OSTimer() hidden relations

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

OS_Skip() and second OSTimer() hidden relations

Postby luben » Sat Dec 28, 2002 8:26 am

Hello,

Keil uses multiple timers maybe for several reasons (I'm not sure did they keep in mind all of the listed below). I don't mean that their approach is righ and SALVO approach wrong or incomplete. In fact in the technic everything is just one compromise - you could never reach the perfection. I mean - both approaches are correct and they bring some advantages and disadvantages. It's up to you to chose one or other of them. So... :

- it's somehow "more logical" if you have extremely long delays and short delays at one and the same time, to put them in different groups and to drive them with different timers. I mean - this is the first thing that comes in the mind - to group similar tasks and to proceed them in groups. First thing that comes in the mind is not always the best solution.... but sometimes works.

- in some cases the system just requires 2 timers - imagine that you receive from some hardware extremely precision time related pulses - for example every second you receive from RF time pulse. It's logical to use this pulses when measuring long times - they are extremely precision, global synchronized. In the same time short processes like buttons scanning, LED refreshing require 1-10ms delays, that come with the internal timer. Well, in current SALVO this 1s pulses I'll direct to some BINSEM, but the best approach is - they have to drive second timer. In the described case I just could not use OS_Delay(1_minute....) from the precision source (this is the most natural service for delays), because the timer is occupied to scan keys and to refresh LED and it's driven from unprecision source.
To make the example more dramatic - if the uP is with RC nonprecise oscillator and you receive 1s pulses from outside source.... how you'll manage both group of delays?

- some tricks could be made with multiple timers - like explained trick to fake OS_Skip(). If one of the timers is driven not from time-related hardware, but from the calling of OSSched, then you receive possibility to delay some task several calls of OSSched. You could count events, but not in the mean of counting semaphores. Counting semaphores are something like queue of binary events - they remember how many times the event occured. OS_Delay() with Timer driven from events has different meaning.
One other idea came in my mind.... If let's say OSTimer2() is called from some sensor of passing people, making OS_Delay(200_people, _Label, TIMER2) could yield the control to the task after 200 people passed trought the sensor.
I'll not mention again the OS_Skip() - when second timer is driven immediately before OSSched(). When one extremely high priority task could express compassion to all other task by simply doing OS_Delay(2_times, _LABEL, TIMER2) - it will sleep for 2 calling of OSSched and will not lose its highest priority.

- to reduce the code and resources - if having extremely slow tasks (let's say minutes and hours) and "normal" tasks - running within 0.01 - 1s in SALVO you should use or longer variables for all tasks or do some prescalling into the task. Note that this affects all tasks and whole system - if increasing the length of variable for delays, this is "global" change. Keil uses several timers, allowing to the user to define fast and slow groups for delays (as I told the timers could be driven from different sources). Because RTOS of Keil is build into compiler, maybe for them is not big deal to make 2, 3 and more timers, without big increasing of the code size of kernel. SALVO is extremely portable and universal and uses other approach - single timer. In fact both short and long delays could be executed without problems in current SALVO.

Maybe I could find more reasons too. But after writing the issue I got that maybe the main reason should be defined like:
- sometimes time related services should be driven from different sources. SO if you need 2 sources - you need 2 timers (like in the described example - 1s RF received pulses and from other side short delays, without precison). SOURCE -> GROUP

Regards
Luben

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

Re: OS_Skip() and second OSTimer() hidden relations

Postby aek » Sat Dec 28, 2002 12:53 pm

Hi Luben.

I'm not familiar with Keil's multi-timer approach.

Can you explain why it is advantageous to have multiple timers?

Thanks,

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

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

Re: OS_Skip() and second OSTimer() hidden relations

Postby luben » Sat Dec 28, 2002 12:58 pm

Hello,

Some time ago I wrote issue about OS_Skip(_how_many_calls_of_OSShed, _Label) - new service that allows high priority tasks to "express" compassion to low priority tasks - something like Thanksgivings.... OS_Skip() have to delay the task several calls of OSSched() - as you see it's not exactly time related service, but is connected with the intertasks relations. It simply allows high priority task to decrease for determined amount of time it's priority and to guarantee that it will sure get back the control within some time. Decreasing the priority is risky, because "hungry" low priority tasks could not allow to the high priority task, that lowered the priority to earn soon it's status.... "proletariat", poor tasks are not very friendly and for sure they wish "revange".

Other issue was for making several different OSTimer() services.... I mean - several timers inside SALVO (like for example is made Keil multitasking build into their compiler).

In fact both issues are connected - they solve one and the same problem.

Imagine that you have OSTimer1() and OSTimer() services and when calling OS_WaitXYZ() or OS_Delay() you point somehow from where to take the time - like:

OS_WaitBinSem(BINSEM_vvvv, time_200ms, TIMER1, _Label) ;
nothing is changed from the previous SALVO good known behaviour.

Now the new moment:

if OSTimer2() is called immediately before calling OSSched() it could be used to make equal to OS_Skip() functionality:

OS_Delay(_how_many_times, TIMER2, _Label);

will work in the following way:
The task (maybe with highest priority) becomes delayed for "how_many_times" calling of OSched() - that's just OS_Skip() function!

One solution to allow 2 timers without breaking the current rules, is to decrease the range (for one byte delays) from 0..255 to 0..127 and if MSB is 1 to use TIMER2 and if bit 7 = 0 -> TIMER1.
Then the service will look like:

OS_Delay(how_many_times+TIMER2, _Label) ; // equal to OS_Skip()

and other services will be not changed at all:
OS_WaitXYZ(event, time+TIMER1,_Label); // the good known view of the service.

Just an idea....

Regards
Luben

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

Re: OS_Skip() and second OSTimer() hidden relations

Postby luben » Sun Dec 29, 2002 8:09 am

Hello,

In fact even current SALVO supports undescribed feature of services - OS_CountEvent() - the task could "sleep" for determined counts of appearing of some event.

It's not counting semaphore, it has different meaning - to wake the task only after N times the event appeared
OS_CountEvent(N_times, Label).

And guess what - it's the ordinary OS_Delay with calling the OSTimer() when some event appears.

If you ask me you could make "friendly" name of this feature
#define OS_CountEvent()... OS_Delay....
or just to write the same macro for OS_CountEvent()

Looking from this angle you should not ask "why I need more timers?", but your desire should be - how many timer I could use (how many different events I could count). When asking for events, the desire is to be able to count unlimited number of different events.... And one is sure - like one BINSEM is not enough, one Timer is not enough too....

I really think that OS_CountEvent (the friendly name of OS_Delay) should be somehow implemented in the new versions... and if more timers exists the name really will cover the content.


Regards
Luben

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

Re: OS_Skip() and second OSTimer() hidden relations

Postby luben » Sun Dec 29, 2002 8:19 am

Hello,

Something more.... OS_Delay() is just one particial case of OS_CountEvent().

Maybe the full version of OS_CountEvent() should include timeouts....

OS_CountEvent(N_times, TIMEOUT, Label);
If the event don't appear into some period - do other thing

So.... there could be 2 solutions:
- to add more timers and to define OS_CounEvent like OS_Delay

- to write new service OS_CountEvent() with timeouts. Then OSTimer HAVE TO STAY - because it will remain the only one system clock. OSTimer will be especially used for timeouts and system delays. OS_CountEvent() could be used with the same success like OS_Delay, but could be used for counting events with timeout feature..

And if OS_CountEvent() will be new service it needs one more servie too:

OSEvent(N) - that's equivalent of OSTimer().
If in the system exists N new types timers, equal to the current SALVO type timers, you should somehow signal them (like OSTimer() service). This should be done with OSEvent(N).

For example OSEvent(2) will signal the second timer (or we should name it from now event counter - I like it "EVENT COUNTER")....

And of course
#define OSNUMBER_OFEVENT_COUNTER 2 // define how many event counters to add in SALVO

The result is - the old and nostalgic OSTimer will remain untouched. OSTimer() service will survive. Timeouts.. everything will stay untouched. Instead of defining multiple timers we keep only one. But the new service OS_CountEvent() is added and in fact it allows to th euser to use as more as he wants faked timers.

OS_CountEvent(1_hour, N_of_event, OSNOTIMEOUT, LABEL);

..with

OS_Event(N_of_event); //signalled every 1 minute

will yield service equal to second timer, that covers hours intervals. But the new OS_CountEvent() service has wider meaning and could be used for more purposes, like

OS_CountEvent(1000, 2, OSNO_TIMEOUT, Label); with
OSEvent() signalled from counter of people, that enters into market

this could be used to wake a task after 1000 people passed the door and to activate some "BONUS giving program"....

Oh my.... we should rename the topic to OS_CountEvent() new service!

Regards
Luben

[This message has been edited by luben (edited December 29, 2002).]

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

Re: OS_Skip() and second OSTimer() hidden relations

Postby aek » Sun Dec 29, 2002 8:26 am

Hi Luben.

I'll have to digest this and analyze if / where it fits into Salvo ...

Note that for Pro users, one can always accomodate large and small delays by setting OSBYTES_OF_DELAYS to 2 or 4 (bytes). There would be a small overhead in OSTimer() (to handle 16- or 32-bit decrements instead of just 8-bit ones), and it would cost more RAM per task, but overall it would be a pretty small penalty -- might be more efficient (instructions and RAM) than running multiple timers.

Regards,

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

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

Re: OS_Skip() and second OSTimer() hidden relations

Postby luben » Sun Dec 29, 2002 8:44 am

Hello,

In fact I agree with you - ONLY ONE TIMER is OK, no sense to add more timers....

But OS_CountEvent service if exists, it could cover all caprises of the users, because it could be used:
- like new timers. User could define many timers. driven from different sources... I agree that OSTimer() now receives different meaning
- like count events service - it's absolutely new type of service. In fact the user could cancel the using of OSTimer and could do the same job with OS_CountEvent (if he will not use timeouts)...

.. and of course the damn OSTimer() survived... they say that cats have 7 lifes... OSTimer() for sure has more....

Regards
Luben

[This message has been edited by luben (edited December 29, 2002).]

[This message has been edited by luben (edited December 30, 2002).]

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


Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 0 guests

cron