Pumpkin, Inc.

Pumpkin User Forums

New time oriented function

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

Re: New time oriented function

Postby luben » Thu Sep 27, 2001 7:49 am

Hello,

I agree that OS_Delay() is not function that the user could use often after use of OS_Delay(). But I can give you immediately example for such need:
-- a task that controls LED lighting wakes up every 5s and have to light the LED for 100ms. In addition from time to time it have to measure the temperature from DALLAS DS1821 chip that needs delay of 1s to ensure that temperature is measured.
If the user wants to make wakeing every 5s with OSInterval() and to use for other delays OS_Delay(), then OS_Interval will stop working. Think about similar cases. I mean - at this momemnt SALVO don't have such limitations - "DON'T USE SOME FUNCTION BETWEEN OTHER FUNCTIONS". I mean - this is the first exception from that class.

And what about this case:
The tasked delayed to take control (low priority) for the time of bigger then interval+1. When will be the next event? I mean - OS_Interval should wake up after desired time moment.
T=58 (late, massive holdoff by other, higher-priority tasks):

quote:

30+25=55, and so the task (now running) is late. It will delay itself for 30+25+25-58=22 ticks. 58+22=80, which is the desired amount to get to the next interval. It's important to note that the task is now running at T=58, though we wanted it to run at T=55. So if a task is late, it will still run, and it will attempt to resynchronize itself for the next desired interval.


How you made calculating 25+25. I mean, how you found that you have to add 2 intervals?

When will be the next wake up? You should not calculate the next wake up from current moment (because it's already delayed) but from the "ideal" moment, that already expired. That consumes RAM (every additional information needs RAM). The more RAM means different structure of data compared to OS_Delay, different functions, etc.

But for sure some limitation over OS_Interval are acceptible and I agree that your approach will implement OS_Interval with less memory and less changes into current SALVO.

Regards
Luben

[This message has been edited by luben (edited September 27, 2001).]

[This message has been edited by luben (edited September 27, 2001).]

[This message has been edited by luben (edited September 27, 2001).]

[This message has been edited by luben (edited September 27, 2001).]

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

Re: New time oriented function

Postby aek » Thu Sep 27, 2001 8:03 am

quote:
a task that controls LED lighting wakes up every 5s and have to light the LED for 100ms.

Ah, that makes sense -- we should be able to support that. Perhaps what's necessary is a OSReadSyncInterval() to save the sync info, something like this:

code:
while (1) {
...
OS_Interval(5s);
sync = OSRdSyncInterval();
OS_Delay(100ms);
OSSyncInterval(sync);
}

I have to think about that some more ...

quote:
The tasked delayed to take control (low priority) for the time of bigger then interval+1. When will be the next event? I mean - OS_Interval should wake up after desired time moment. When will be the next wake up? You should not calculate the next wake up from current moment (because it's already delayed) but from the "ideal" moment, that already expired. That consumes RAM (every additional information needs RAM). The more RAM means different structure of data compared to OS_Delay, different functions, etc.

I don't follow -- can you give a more explicit example.

BTW, none of the OS_Interval code I've proposed needs any extra RAM. Why? Because the delay field in the tcb is used only while the task is delayed. Therefore a placeholder can "live" in there after it times out -- that's where the timestamp goes. It is then read by OS_Interval(), and a new value is placed in there prior to enqueueing the task into the delay queue. See delay.c -- OSDelay().

Regards,

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

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

Re: New time oriented function

Postby luben » Thu Sep 27, 2001 8:10 am

Hello,

from what you wrote I see that you'll not make OS_Interval to accumulate events. I mean, if the function delyed more then 2 intervals it will not wake up the task twice, right? For sure this simplifies the code, maybe we have to think is it possible some case when such skipping of events is not desirable. At least I can't imagine such thing right now and I give up. Maybe such big fluctuations of the time talk for bad structure of the program and are indicative for big mistakes.

Regards
Luben

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

Re: New time oriented function

Postby luben » Thu Sep 27, 2001 8:19 am

Excuse me, I made some editing of the message and you replyed to not finished message. I meaned - "for time bigger then 2 intervals+1". In this case you should somehow remember the ideal time stamps.

About more RAM. From what I learned about informatics every information that could be represented with YES/No or value needs memory or one more variable (in our case RAM). So, if you have to know additional information for the example - "how many intervals you skipped" - then you need more RAM.
I meant - every attempt to know something more is RAM consuming. In your case - to know the number of skipped intervals, or the "ideal" intervals needs more RAM or additional variables.

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

Re: New time oriented function

Postby luben » Thu Sep 27, 2001 8:31 am

quote:

BTW, none of the OS_Interval code I've proposed needs any extra RAM. Why? Because the delay field in the tcb is used only while the task is delayed. Therefore a placeholder can "live" in there after it times out -- that's where the timestamp goes. It is then read by OS_Interval(), and a new value is placed in there prior to enqueueing the task into the delay queue. See delay.c -- OSDelay().


Yes, this is correct only in the case if the OS_Delay or similar function received the control in the desired interval.

Or maybe I misunderstand where you made the changes. Now I see that all this problems could be avoid if OSTimer cares for OS_Interval. I mean, even if the task is not waked up for "2 intervals+1" it will continue calculating the right moment to wake up. In this case I agree that OS_Interval will work like hardware timer. But for sure this will need one more variable (and RAM) - to know the interval value. Because it's a part of the ECB of OS_Delay it's really possible to make this without any new variables.... I see.....

Anyway, there is something that I can't get right now, but will think today and will post you message. I don't talk about the code - I'm sure that you'll make it perfect, but about some "bad" cases and exeptions, where your approach can failure.

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

Re: New time oriented function

Postby aek » Thu Sep 27, 2001 8:33 am

Don't get hung up on skipped intervals.

Let's look at the case of OS_Interval(12). This means that the task will be delayed for 12 system ticks, and will then run again. When exactly after T+12 is not known -- it will be held up by higher-priority tasks, of course. But it would have to be held up for 12 system ticks (! -- an eternity) for the timing to be off on the next interval at T+24.

So yes, the ideal time stamp is no longer known "for time bigger then 2 intervals+1". But if that happens, your timer is broken anyway ...

As for informatics -- that statement assumes the necessary persistence of the information. But a Salvo tasks's delay field is only needed from when OS_Delay() is called to when the task times out and is made eligible again. The rest of the time, the delay field can hold other information. By structuring OS_Interval() so that it always add an offset to an original timestamp (without error), we are able to maintain synchronization to the original timestamp without storing its absolute value -- rather, we srore the relative increments, and if we could go back in time, we'd find that absolute "sync system tick."

It would take too much RAM to know "how many intervals you've skipped." Instead, we have to characterize the system based on the existing timer behavior. As I mentioned before, practically speaking, if you're missing intervals where interval is, say, >=2, then there's a bigger underlying problem in your application that prevents the interval service from working. I thought about having a "while loop" reconstruct how many intervals were missed when such a situation is detected, but then it becomes non-deterministic, and it's actually an ambiguous case (you'll have to see the code). So instead, I settled on the spec that "When using OS_Interval(), the system can recover from at most one interval of error at any time."

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

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

Re: New time oriented function

Postby aek » Thu Sep 27, 2001 8:44 am

I'm still not quite following your proposal, so instead, I'll point out how I plan to implement OSInterval() and how & why it works, and invite your comments.

First of, let's address the issue of "missed intervals." Note that in Salvo, if you ever fail to call OSTimer() during a system tick, your timing will be permanently off -- there's really nothing you can do about that. So a good rule is "OSTimer() must be called every system tick, without exceptions. Failure to do so will result in timing errors."

With a reliable mechanism for calling OSTimer(), we now turn our attention to the problem of an "intervaled" task which is unable to run because its priority is very low compared to other eligible tasks. (Of course the same situation exists for delayed tasks.) My attitiude towards this problem is fairly simple -- since Salvo tasks are priority based, if a delayed or intervaled task is unable to run when it wants to, that's just too bad -- the system is still running as it's supposed to, with higher-priority tasks getting access to the processor. So given the limited resources of the processor running Salvo, I think it's entirely reasonable to say that a delayed or intervaled task may incur additional delays if there are other, higher-priority tasks blocking its execution.

Now, let's look at it from a practical standpoint. The way I will implement intervaled tasks is I will record a timestamp for the task whenever it times out. E.g. when it is removed from the delay queue via OSTimer(), it holds onto a timestamp of the current value of the system ticks (say, 56). When

code:
OS_Interval(interval, label)

is called in this task, it will be translated (essentially) to
code:
OS_Delay(interval-(OSGetTicks()-56), label)

So for an intervaled task to fail to repeat itself at the proper interval (assuming good calls to OSTimer()), it would have to be blocked for an entire system tick or more, immediately after it was made eligible. Frankly, this is an unlikely proposition. After all, most Salvo tasks in a properly-written application are either delayed or waiting, and therefore eligible tasks run quickly after they become eligible. Note that even if it were delayed more than 1 system tick, it would "recover" on the next tick because of the timestamp that was recorded when it timed out (assuming interval >= 2 system ticks).

As before, it's important to code in an event-driven manner, where code is "active" only when certain events happen, and not by polling, etc. OS_Interval() allows this approach, because the requisite operations are done only when i) OSTimer() is called, and ii) OS_Interval() is called.

Because Salvo's time-based functions are driven via what is really just a simple software timer, its timing performance is constrained by not only the calls to OSTimer() but also the number of eligible tasks (and their priorities) at any given instant. In the "real world" I haven't seen any cases where the +/- 1 system tick system accuracy isn't maintained.

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

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

Re: New time oriented function

Postby aek » Thu Sep 27, 2001 8:46 am

I forgot to mention that all of this OS_Interval() stuff is done without any additional RAM.

Also, in the rare case when the interval has already "passed" by the time OS_Interval() is called again (this would happen with very small intervals), the result will be a new synchronization with the intended interval.

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

[This message has been edited by aek (edited September 27, 2001).]

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

Re: New time oriented function

Postby luben » Thu Sep 27, 2001 10:55 am

Hello,

I like your approach and I agree that it's very simple and effective. In addition it could be implemented into SALVO easy and will not destroy the "SALVO" style.

But what will be if you use OS_Delay (one or more times) between OS_Interval() calls? Will this destroy the pace rythm? OS_Interval() should look like hardware timer - to produce events on fixed intervals. I can't explain exactly but I feel that OS_Delay has a little bit different sense - to produce delay after one start point. OS_Interval() should produce events every defined interval.

If you ask me, we should first declare what we want exactly, I mean, what sense we put on OS_Interval(). In my opinion it should be "periodically to signal events on fixed time intervals". And it should not to depend on any other commands between the OS_Intervals. It's like to limit OS_WaitBinSem - to disable any use of OS_Delay between two sequencive OS_WaitBinSem.

So, your OS_Interval should be not base on SALVO OS_Delay functions - it have to use different (or at least additional) RAM resources. The other approach is just to say users have not to use OS_Delay between calls of OS_Interval.

Or just I misunderstood your idea?

Regards
Luben

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

Re: New time oriented function

Postby aek » Fri Sep 28, 2001 12:44 am

I've decided on a slightly different terminology -- I think it will help in understanding. The functions are:

code:
OS_DelayTS()
OSSyncTS()
OSGetTS()
OSSetTS()

where TS stands for "timestamp".

With this terminology, it should be more obvious to the user that these are related to OS_Delay(), but use a timestamp, and therefore when mixing OS_Delay() and OS_DelayTS(), one needs to preserve the timestamp.

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

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

PreviousNext

Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 5 guests

cron