Hello,
If you violate RTX's rule that you are not to mix the interval and delay timers (thus a task that needs to wake-up at a certain interval is blocked), RTX will try to fix the periodic task's schedule but waking it up sooner that expected. It might take anything between 1 and 10 cycles until the original period is restored. It is possible to call "os_itv_set" again to fix it immediately, though.
Hi, I think, it might not be a good idea to volatile RTX's rule(s). When I need os_dly_wait and os_itv_wait in the same task, I create a new task where I call os_dly_wait instead of calling it directly. This task sets an event or sends a message, when the time has expired.
I think you mean, "violate RTX's rule(s)" ?
Of course, if anything thells you, "do not do this" and you go ahead and do it, then you are obviously asking for trouble!
www.antronics.co.uk/.../dilbert_dont_touch.gif
Stunned Steve,
Do you have difficulties in understanding fundamental English language constructs? When I state that I will be careful, I meant: "I discovered this behavior, it is not what I want, thus - I will be careful not to fall into this trap". I genuinely hope got it this time around.
This thread (at least so far) is a vivid demonstration of how some people react when they encounter something that they are not accustomed to and seems initially "wrong". First they cringe, and finally, after rolling in the mud for a while, they refer to kitchen metaphors before yelling: "go read the manual and do what it says". I would have thought most people here had a little more sense of creativity and, perhaps I should say - a sense of responsibility toward the people that use the products they make! It is unfortunate that not everyone that disagreed with me used a sensible line of argumentation as Robert did.
Robert: Surely you agree that this potential behavior is not desirable to have when controling, say, a stepper motor in a mission critical system? I'll be very careful in the mean time!
I was just commenting on the part about me surely agreeing that the behavior not being desirable. The behavior of the os_itv functions is correct as is. There is nothing to change. They work as advertised. THEY do not control any stepper motors, mission critical or not.
Sorry this is causing you so much trouble, that was never my intent. What was your intent when you started this thread? Maybe we can just focus on that.
Robert,
Contrary to what others here think, this "problem" does not trouble me at all! A colleague discovered it, and since it is not documented, we decided to address technical support. My intent was to hear what other think - nothing more. No harm done, no damage, no motors involved, everybody is happy - even RTX. Thanks for your reply.
But it is documented: it is documented that you must not do this!
Where?
It is documented that: "You cannot intermix with a single task the wait method os_itv_wait () and os_dly_wait ()."
But where is the documentation that tells what happens if the thread is busy for one or more full periods before calling os_itv_wait()?
Contrary to what others here think, this "problem" does not trouble me at all!
Interesting you should say that, given that earlier you said you "cannot accept" existing behaviour. If that's not troubling you, what would?
Hans-Bernhard,
Despite me not being willing to accept this, the project's budget forces me to...
That's not the issue actually under discussion here. Robert McNamara undertook it to post lots of details about the exact working of os_itv_wait() into this thread, including the answer to your question here. But while that may have had some relevance to the actual issue under discussion, but it's not "it".
So Andy's answer to Tamir's criticism still stands: it's documented just as it should be Don't do that, then!
No, I don't really agree with you.
Tamir made his post discussing the continuous zero delays from os_itv_wait() after the thread had been busy for a long time. In this case, because he violated the mentioned information that the two wait methods shouldn't be mixed.
But it really doesn't matter exactly what you do. Any (!) operation that makes the thread spend more than a full period before calling os_itv_wait() will result in one or more instant returns. And even if it has been discussed in this thread, it doesn't seem to be documented in the manual page for the function.
So I really do think that that is a big issue, and on topic for this thread. The behaviour will be there even if you don't mix os_itv_wait() and os_os_dly_wait(). It may happen if the thread calls os_evt_wait_and(), os_evt_wait_or(), os_mbx_wait(), os_mut_wait(), os_sem_wait(), or if a higher prioritized thread for some reason over-consumes time, or an ISR gets activated too many times within a time interval.
The fact is that Robert McNamara shouldn't have had to undertake the job of posting the details of os_itv_wait() here, since the documentation should have described if the function tracks number of pending timeouts or just the latest timeout.
Tamir brought up a specific situation only trigged by violating the documentation, but the same situation exists for a large number of cases that does not violate the documentation. That is most definitely relevant.
And Andys note is too narrow. There should not be a "don't mix with os_dly_wait()" in the manual. There should either be a "don't do anything that makes the thread not call os_itv_wait() before the interavl is up" or the manual should consider it ok, but describe the repetitive behaviour.
I just discovered that I can lock up my program with an infinite loop.
This is not acceptable.
Someone might start changing my code later on and not realize the danger. Someone might die.
The compiler should detect that I don't want it infinite and terminate it prematurely.
It should be optional behaviour.
Tamir,
You (originally) wrote:
"I'll be very careful in the mean time!"
So when you then ask (about my response):
Do you have difficulties in understanding fundamental English language constructs?
It answers maybe more questions about yourself than you should really divulge.
unfortunately, this is generally impossible. you would have known why if you had studied computer science (or maybe you cheated your way to a degree using the services of this forum!).
then I guess the answer to my question is a resounding YES!
"then I guess the answer to my question is a resounding YES!"
You're doing it again!
Consider:
en.wiktionary.org/.../modesty
Ok enough with this. the point of this thread was to make people aware of a certain "feature" that is there to stay, so it seems. However, I will try to persuade Keil to change or at least document it, by hook or by crook! good night.
(Sorry for my limited English ability.)
People involved in this thread, are all experts; but I am not; I am not even an experienced engineer. I still want to say something here.
I have really learnt a lot and benefited from Tamir's posts and efforts about RTX issues; though I don't agree with some of Tamir's thoughts.
Many Thanks to You, Tamir.
View all questions in Keil forum